WalkingPH: un'applicazione CRM mobile polivalente con la ...

UNIVERSITÀ DEGLI STUDI DI PADOVA

FACOLTÀ DI SCIENZE MM.FF.NN.

WalkingPH: un'applicazione

CRM mobile polivalente con

la gestione delle vendite

integrata

Candidato: Relatore:

Spolaor Riccardo Prof. Vardanega Tullio

Matricola: 560852

a.a. 2010 / 2011

Alla mia famiglia

I

Sommario

Il seguente documento tratta le attività svolte e gli argomenti riguardanti l'at-tività di stage che ha avuto luogo presso l'azienda Sintesi SAS, �nalizzato allarealizzazione dell'applicazione WalkingPH.Nel primo capitolo è descritta l'azienda nel suo complesso, in particolar modo ilcampo in cui opera, la sua storia e il prodotto di punta aziendale ovvero PlanetHotel.Il secondo capitolo contiene la descrizione del progetto di stage e la sua in-tegrazione all'interno della strategia aziendale, �no a de�nire gli obiettivi e ivincoli ai quali il progetto è sottoposto.Nel terzo capitolo è trattata l'attività di stage vera e propria, comprendente lefasi di analisi del dominio, studio di fattibilità, progettazione e sviluppo dell'ap-plicazione WalkingPH.In�ne nel quarto capitolo sono espresse alcune valutazioni riguardanti l'anda-mento e la conclusione dell'attivita di stage.

Convenzioni tipogra�che

I termini speci�ci del dominio o tecnici ed acronimi sono segnalati alla loro primaoccorrenza attraverso la sottolineatura, tali termini sono riportati nel Glossarioassieme ad una breve descrizione.I vocaboli in lingua inglese sono segnalati mediante l'uso del corsivo.I riferimenti a nomi di moduli sofware, classi o campi dato sono racchiusi tra�virgolette�.

III

Indice

1 Dominio applicativo 1

1.1 Dati sull'azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Storia dell'azienda . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Politica aziendale . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Planet Hotel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4.1 Struttura del prodotto . . . . . . . . . . . . . . . . . . . . 41.4.2 Ciclo di vita . . . . . . . . . . . . . . . . . . . . . . . . . . 71.4.3 Tecnologie impiegate . . . . . . . . . . . . . . . . . . . . . 7

1.5 Il futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Il Progetto 9

2.1 La strategia aziendale . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Il progetto di stage all'interno della strategia aziendale . . . . . . 9

2.2.1 Evoluzione del progetto . . . . . . . . . . . . . . . . . . . 102.3 Obiettivo del progetto . . . . . . . . . . . . . . . . . . . . . . . . 112.4 Vincoli applicativi . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4.1 Vincoli software e strutturali . . . . . . . . . . . . . . . . 122.4.2 Vincoli hardware . . . . . . . . . . . . . . . . . . . . . . . 12

3 Stage 13

3.1 Piani�cazione delle attività . . . . . . . . . . . . . . . . . . . . . 133.1.1 Obiettivi dello stage . . . . . . . . . . . . . . . . . . . . . 133.1.2 Approccio al progetto . . . . . . . . . . . . . . . . . . . . 143.1.3 Piano di lavoro . . . . . . . . . . . . . . . . . . . . . . . . 153.1.4 Revisioni e controllo qualità . . . . . . . . . . . . . . . . . 18

3.2 Analisi e studio del dominio . . . . . . . . . . . . . . . . . . . . . 203.2.1 Un'applicazione polivalente . . . . . . . . . . . . . . . . . 20

3.3 Scelta degli strumenti di sviluppo . . . . . . . . . . . . . . . . . . 233.3.1 Tecnologia per la sincronizzazione . . . . . . . . . . . . . 233.3.2 Soluzione scelta per la sincronizzazione . . . . . . . . . . . 293.3.3 L'IDE utilizzato: Windev Mobile 16 . . . . . . . . . . . . 30

3.4 Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.4.1 Progettazione del database . . . . . . . . . . . . . . . . . 323.4.2 Divisione in moduli software . . . . . . . . . . . . . . . . 353.4.3 Analisi dei requisiti . . . . . . . . . . . . . . . . . . . . . . 38

V

INDICE

3.4.4 Struttura e diagrammi delle classi . . . . . . . . . . . . . 443.5 Sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.5.1 Operazioni preliminari . . . . . . . . . . . . . . . . . . . . 483.5.2 Le iterazioni del metodo RAD . . . . . . . . . . . . . . . 483.5.3 L'interfaccia gra�ca . . . . . . . . . . . . . . . . . . . . . 493.5.4 Lo sviluppo del modulo per la gestione ordine . . . . . . 503.5.5 Funzionalità di salvataggio di emergenza . . . . . . . . . . 533.5.6 Di�coltà riscontrate . . . . . . . . . . . . . . . . . . . . . 53

4 Valutazione retrospettiva 55

4.1 Soddisfacimento dei requisiti . . . . . . . . . . . . . . . . . . . . 554.1.1 Avanzamento nei requisiti . . . . . . . . . . . . . . . . . . 56

4.2 Divario conoscitivo . . . . . . . . . . . . . . . . . . . . . . . . . . 584.3 Conoscenze ed esperienze acquisite . . . . . . . . . . . . . . . . . 594.4 Considerazioni personali . . . . . . . . . . . . . . . . . . . . . . . 60

A Windev 61

A.1 Le caratteristiche . . . . . . . . . . . . . . . . . . . . . . . . . . . 61A.1.1 Il DBMS proprietario e l'accesso a database esterni . . . . 62A.1.2 Il WLanguage . . . . . . . . . . . . . . . . . . . . . . . . . 62A.1.3 Gli strumenti integrati . . . . . . . . . . . . . . . . . . . . 63

B Glossario 64

VI

Capitolo 1Dominio applicativo

In questo capitolo sono fornite informazioni in merito all'azienda nella quale si èsvolto lo stage, sia per quanto riguarda la storia dell'azienda, sia una descrizionedel prodotto aziendale di punta.

1.1 Dati sull'azienda

Nome dell'azienda: Sintesi S.A.S.Servizi: Consulenze Software, Sistemi E.D.P.Titolare: Bovo UgoIndirizzo: Via Salemi 5, 30174 Mestre - VETelefono: +39 0415020613Fax: +39 041942207Turor aziendale: Bovo Ugo

1.2 Storia dell'azienda

L'azienda Sintesi è stata fondata nel 1982. L'attività principale di Sintesi con-siste nello sviluppo di applicazioni software per la gestione aziendale.Inizialmente l'azienda si occupava di software gestionali nell'ambito dell'ammin-istrazione, del settore commerciale, della gestione del magazzino, del controllodi gestione e di produzione. La prima esperienza aziendale nell'ambito turisticofu la gestione dell'Economato per Arrigo Cipriani, al Harry's Bar di Venezia,commissionato da Olivetti; ciò ha portato Sintesi ad esperienze interessanti eformative con aziende industriali e commerciali, anche di dimensioni importantie addirittura internazionali (quali la Olivetti, la Yale Security Product, la Best-Egypt).Successivamente, dal 1984 ad ora, l'azienda si è orientata verso le applicazioninell'ambito turistico: hotel, campeggi, villaggi turistici, centri prenotazioni, ris-toranti e distretti territoriali. Proprio grazie agli anni di lavoro in interventi nel-l'ambito dell'organizzazione e dell'architettura commerciale delle strutture ricettivee turistiche, alla produzione di software l'azienda ha a�ancato un'interessante

1

CAPITOLO 1. DOMINIO APPLICATIVO

attività di consulenza in ambiti di marketing operativo e di controllo gestione.Degno di nota è il fatto che nel 1984, Sintesi è stata la prima azienda in Italia acreare un prodotto software che presentasse il Tableau a colori, realizzato nel-l'ambito del progetto condotto con SEAC-Confcommercio e COALCE di Cervia.Da allora, il ruolo di Sintesi consisteva nell'essere la produttrice di software nel-l'ambito turistico per Olivetti e SEAC-Confcommercio, ma anche un partnertecnologico di Yale per quanto riguarda i sistemi informativi.Non è un caso quindi che Sintesi sia una delle poche aziende in Europa adaver ottenuto l'omologazione di un Registro Navale Internazionale (RINA) peri prodotti software di tipo Building Automation on-line, di cui uno è stato in-stallato a bordo di due navi passeggeri.Altre esperienze aziendali degne di nota sono la realizzazione di un sistemainformativo per la Confesercenti Toscana, studio di fattibilità per un proget-to riguardante il distretto turistico per le Terme di Santa Cesarea e ComunitàMontana del Gargano, la progettazione e realizzazione della business unit perstrutture alberghiere per la Yale Security Product, avente come area di com-petenza Italia, India e Nord Africa, oltre a molte altre consulenze nel settoreturistico-ricettivo.Nel 1996 è iniziato lo sviluppo del progetto �Planet Hotel�, quarta generazionedel software gestionale per le strutture turistico-ricettive sviluppato dall'azien-da. Le precedenti versioni di Planet Hotel (che avevano assunto il marchio�Excelsior�), erano state distribuite da Olivetti con proprio marchio.A �anco delle applicazioni gestionali, destinate al settore alberghiero, dal 2011sono in fase di sviluppo una linea di applicazioni del tipo social che potrebberovedere la pubblicazione di una prima applicazione social business entro l'annocorrente.

1.3 Politica aziendale

L'azienda cerca di coniugare al meglio l'esperienza acquisita nel ambito dei pro-getti portati a termine in precedenza, dai quali deriva un impostazione pro-fessionale per la risoluzione dei problemi inerenti le varie problematiche piùricorrenti nello sviluppo di software gestionali, con un'attitudine alla ricerca eallo sviluppo, sperimentando le novità proposte dal panorama software mondi-ale, al �ne di applicarle nell'ambito del settore turistico.Inoltre Sintesi è molto recettiva per quanto riguarda le necessità dei clienti, ilquale molto spesso viene coinvolto attivamente nel suggerimento di funzioni,moduli integrativi o programmi software che possano rendere il loro lavoro piùe�ciente.Caratteristica dell'azienda è la particolare attenzione alle nuove tecnologie e ainuovi mezzi di comunicazione; dagli emergenti social network, ai sempre piùdi�usi dispositivi smartphone con sistemi operativi Android, symbian, windowsphone 7, a dispositivi portatili touchscreen come le tablet, potendone prevedereun possibile utilizzo nel settore alberghiero.Un chiaro esempio dell'interesse a queste nuove tecnologie è stato un progettodi stage denominato �ArtYou�, il quale consiste in un social network legato almondo degli eventi e dell'arte, del quale è stata sviluppata l'applicazione per dis-positivi con sistema operativo Android, mentre è tuttora in corso il deploymentper Symbian e iOS.

2

1.4. PLANET HOTEL

1.4 Planet Hotel

Planet Hotel è il software gestionale per strutture turistico-ricettive di puntadi Sintesi, questo prodotto è articolato in una collana di moduli integrati traloro, allo scopo di essere �essibile, esso infatti può essere impiegato in realtàturistiche diverse tra loro: per questo tra gli utilizzatori del gestionale risultanostrutture alberghiere di piccola dimensione (Locanda Al Gallo di Oderzo, conappena 12 camere), strutture del tipo �business� hotel di dimensioni importan-ti (Hotel New Europe di Napoli), �no a catene di alberghi e villaggi turistici(MobyGest di Rimini).Dunque Planet Hotel è orientato a una clientela molto variegata sia per quantoriguarda la tipologia di struttura alberghiera, sia per quanto riguarda le dimen-sioni di quest'ultima; tutto ciò rende di fatto il prodotto un gestionale �essibile ecompleto. Proprio per questo Planet Hotel fornisce all'utente due approcci pos-sibili durante l'utilizzo del gestionale: un approccio sempli�cato, per renderefacile e veloce la registrazione o la consultazione dei dati, ed uno più ampio earticolato; naturalmente l'utente è in grado di scegliere in qualunque momentol'interfaccia più adatta alle sue esigenze.Planet hotel è in continua evoluzione grazie all'integrazione del software ges-tionale con nuovi moduli orientati a supportare ogni aspetto del settore al-berghiero; tra i moduli integrativi disponibili per il software, i più innovativisono il prodotto di importanti attività di ricerca nell'ambito tecnologico, anchesviluppate in stretta collaborazione con istituti universitari.

Figura 1.1: Copertina depiant di Planet Hotel

3


1.4.1 Struttura del prodotto

Entrando più nel dettaglio, Planet Hotel è composto da ben 8 moduli softwareche contengono al loro interno le funzionalità relative ad un settore speci�codelle strutture alberghiere. Questi moduli e le loro funzionalità sono descrittebrevemente nelle successive sezioni.

Front Desk

Consiste nell'insieme di applicazioni che costituiscono il nucleo vero e proprio diPlanet Hotel, aggregando al suo interno le funzioni di base necessarie durantele operazioni di ricevimento, tali funzioni sono sviluppate in modo completo,fornendo all'operatore diversi tipi di approccio complementari alla prenotazione(eseguita con gli strumenti messi a disposizione del booking center), attraversoricerche e visualizzazione dei dettagli della prenotazione, ma anche consentendol'operatività visuale grazie ad un'interfaccia di tipo Tableau nella quale vengonovisualizzate schematicamente le camere presenti nell'hotel e il loro stato.Sempre da questo modulo è possibile e�ettuare le operazioni di check-out, de�nirele tari�e e i pacchetti, nonché possibili modi�che al conto del cliente. Il moduloin questione presenta anche una funzione di controllo automatico di cassa e dicontabilità, oltre a fornire una possibile integrazione con il sistema di buildingautomation, ma anche con sistemi telefonici e pay-TV.

Figura 1.2: Form di prenotazione presente nel modulo Front Desk

4

1.4. PLANET HOTEL

Back O�ce

Le funzionalità integrate nel modulo Back O�ce comprendono la rendicon-tazione contabile, ovvero i dati provenienti dalle casse, le informazioni sui ricavie sui sospesi, ma anche il controllo degli addebiti, siano essi manuali o auto-matici. Tale modulo comprende al suo interno delle funzioni per la redazione direport speci�ci che consentono all'utente di esaminare consuntivi di occupazionee consumi, oltre alle stime su situazioni predittive.É inoltre presente una funzione di mailing integrata con le anagra�che clienti,agenzie e ditte, contribuendo signi�cativamente al CRM.

Figura 1.3: Gra�co predittivo generato da una funzione del modulo Back O�ce

Amministrazione

Il modulo Amministrazione comprende tre diversi aspetti della gestione con-tabile di una struttura alberghiera:

• Contabilità generale: integra le operazioni contabili alberghiere, spaziandodalla contabilità generale e IVA, ad un modello sempli�cato di riclassi�-cazione di bilancio, agevolando l'operatore nella gestione completa delle at-tività di controllo e di rilevazione �scale, in osservanza delle norme vigentiin merito.

• Centri di costi e ricavo: permette la suddivisione dell'attività in repartidistinti in base al costo e al ricavo, cosi rendere possibile la ripartizione

5


dei movimenti contabili in modo automatico o attraverso percentuali pre-determinate, al �ne di generare appositi report in grado di fotografare laredditività di ogni reparto.

• Estratti conto: rende possibile la gestione delle scadenze di pagamen-to, grazie all'ausilio di una completa dinamica delle partite aperte, dellelettere di sollecito e dei saldi automatici delle partite.

Economato

Tale modulo consente la gestione di un magazzino centrale di una strutturaturistica e dei depositi ad esso connessi, comprende anche alcuni funzioni auto-matiche che gestiscono l'aggiornamento della situazione durante operazioni dicarico e scarico di prodotti verso altri depositi o strutture come lo possono es-sere ristoranti, dispense, discoteche, piani camere e vani di manutenzione. Sonopresenti anche funzioni di interrogazione di giacenza, di rimanenza iniziale e in-formazioni dettagliate sulle operazioni di carico e scarico, oltre alla possibilità diaccedere a una panoramica dalla quali si possono ottenere valutazioni analiticheriguardanti ciascun magazzino o deposito speci�co.

Moneta elettronica

Un sistema informatico che consente al cliente il pagamento di beni e serviziall'interno della struttura alberghiera con una tessera magnetica collegata adun borsellino elettronico relativo al cliente; la gestione del sistema potrà esseredi tipo a credito (prepagata con somme a scalare) oppure a debito (addebito suun conto e saldo alla chiusura).

Booking center

Questo modulo software consente di avere un gestore di prenotazioni central-izzato, fondamentale nella gestione di catene di alberghi o gruppi di struttureturistiche. Il software fornisce in tempo reale la situazione di disponibilità di unostabile o dell'intera catena attraverso l'utilizzo di maschere dinamiche, questoconsentirà il reindirizzamento delle prenotazioni secondo la politica adottatadall'azienda alberghiera.

Prenotazione on-line

Gestisce tutte le necessità legate alla presentazione di listini, di o�erte e disponi-bilità, attraverso l'integrazione del della piattaforma software con un sito inter-net anche preesistente. Rende possibile la visualizzazione della disponibilità e ilcalcolo in tempo reale del prezzo di soggiorno attraverso listini tari�ari caricatiin precedenza; il cliente sarà in�ne messo in condizione di pagare on-line l'interoimporto della prenotazione oppure dell'anticipo.

Bar, Ristorante, Negozi

Questo modulo comprende le funzionalità necessarie alla gestione autonoma delservizio ai tavoli, dall'apertura di un conto all'inserimento delle comanda daparte di un operatore, all'emissione di un conto, ai riepiloghi di cassa; è pre-vista anche una funzione di stampa dei vari ordini secondo delle destinazioni

6

1.4. PLANET HOTEL

prede�nite, atte alla preparazione dell'ordine stesso. Sempre grazie all'inte-grazione con il sistema Planet Hotel è possibile l'addebito dei prodotti consumatidirettamente nel conto collegato al cliente.

Figura 1.4: Tableau a colori per la gestione dell'occupazione tavoli nel moduloRistorante

1.4.2 Ciclo di vita

Planet Hotel è stato nel corso degli anni corretto e ottimizzato attraverso ag-giornamenti rilasciati periodicamente da Sintesi. L'aspetto più importante peròconsiste nel rilascio di nuovi moduli che integrano il software di nuove funzion-alità talvolta concepite all'interno di Sintesi, altrimenti suggerite dagli stessiclienti in base alle loro necessità. Ciò ha permesso a Planet Hotel di essere unprodotto così longevo.

1.4.3 Tecnologie impiegate

Le tecnologie impiegate nella realizzazione di Planet Hotel quarta generazionepossono considerarsi datate, essendo degli strumenti software in commercio dapiù di dieci anni. Le prime tre versioni di Planet Hotel (che allora portava ilnome di �Excelsior�) erano state sviluppate con tre strumenti di sviluppo dif-ferenti in base alla destinazione �nale del software: in Business Basic per PCOlivetti M20, Basic per PC MS-DOS e XBase-Clipper con DBIII in ambienteSCO Unix.

7


L'ambiente software che è stato utilizzato per lo sviluppo della quarta gener-azione di Planet Hotel è Power++, un RAD acquisito da Sybase, che risultaessere tra i prodotti archiviati e non più supportati della medesima softwarehouse. Per quanto riguarda la gestione della base di dati, Planet Hotel è statocreato con SQL Anywhere 5.0, sempre appartenente a Sybase, poi successiva-mente aggiornato �no alla versione 8.0, nella quale è possibile la generazione didatabase mobile di tipo UltraLite, e la possibile sincronizzazione con il databaseconsolidato (dal quale è stato generato il codice Ultralite) attraverso la tecnolo-gia MobiLink (quest'aspetto è stato spiegato meglio nel capitolo riguardante lostage, in particolare nella sezione dedicata allo studio di fattibilità) .

Figura 1.5: Logo di Sybase

1.5 Il futuro

Recentemente Sintesi ha deciso di investire nello sviuppo della quinta gener-azione di Planet Hotel, utilizzando strumenti tecnologici più all'avanguardia, al�ne di migliorarne l'aspetto gra�co, la portabilità e soprattutto le prestazioni.Onde evolvere Planet Hotel in architetture integranti i mondi Desktop, Web eMobile, dal 2009 tutti i moduli di nuova realizzazione della linea di Planet Ho-tel sono sviluppati con IDE moderni: è stato utilizzato Microsoft Visual Studio2008 e 2010, successivamente abbandonato in favore dei tre powerful IDE dellalinea Windev, appartenenti alla software house francese PCSoft. Questi am-bienti integrati di sviluppo, particolar modo per Windev Mobile, sono ampia-mente descritti nellla sezione riguardante gli strumenti utilizzati nel progettodi stage e nell'appendice A. La strategia scelta per la migrazione della versionePlanet Hotel Windows/C++ verso la nuova generazione avverrà realizzandomoduli aggiuntivi (che utilizzano lo stesso database), al �ne di acquisire l'otti-male conoscenza dei nuovi strumenti di sviluppo messi a disposizione dagli IDEWindev; a novembre 2011 inizierà lo sviluppo sostitutivo dei �vecchi� moduliC++.

8

Capitolo 2Il Progetto

2.1 La strategia aziendale

L'azienda nella quale è stata svolta l'attività di stage utilizza una particolare or-ganizzazione del lavoro. Ad ogni programmatore è a�dato un singolo progettoe ne seguirà tutte le sue fasi, dallo studio di fattibilità, all'analisi del dominio,dalla progettazione allo sviluppo vero e proprio; grazie questo il programmatoreha una visione globale del progetto e ne conosce perfettamente ogni dettaglio.Attualmente si possono individuare due progetti attivi che avanzano simultane-amente oltre al progetto di cui è oggetto questa relazione: un progetto consistenella creazione di un booking on-line, mentre il secondo è materia di uno stageche consiste nel deployment dell'applicazione per Symbian e Iphone del prece-dentemente citato social network �ArtYou�.A mio avviso questa strategia aziendale è più che altro dettata dalla presenzain azienda di un numero ridotto di personale.

2.2 Il progetto di stage all'interno della strategia

aziendale

Il CRM

All'interno di un azienda che produce software per stabilimenti turistici, assumeun'importanza fondamentale l'aspetto della relazione con il cliente da parte diun operatore alberghiero, e ciò deve essere coaudiuvato attraverso l'utilizzo delleapplicazioni gestionali quali Planet Hotel.Esiste un vero e proprio concetto che indica tutto questo, ed è appunto il CRM:grazie e questo approccio l'applicazione gestionale viene orientata a soddisfarel'idea di �delizzazione con il cliente, quale strategia per fornire un servizio almassimo dell'e�cienza, con il �ne di attrarre nuovi clienti e mantenere saldi irapporti con clienti abituali e importanti (attraverso l'analisi dei dati riguardan-ti le preferenze del cliente durante le precedenti permanenze e mantenendoloinformato sulle iniziative che potrebbero suscitare il suo interesse).

9

CAPITOLO 2. IL PROGETTO

Il modulo wellness

Il progetto di stage è nato come parte di un progetto più grande diviso in tremoduli per la gestione del CRM di un centro Wellness presente all'interno diuna struttura alberghiera. Il primo modulo consiste nella creazione di un soft-ware che consenta a un medico, appartenente allo sta� alberghiero, di gestirein maniera e�ciente e automatizzata il controllo medico obbligatorio, primadi poter somministrare ad un cliente le cure e i prodotti del centro benessere;possono essere individuate dunque due parti essenziali nel primo modulo, unaparte in cui il medico crea un questionario sotto forma di template per ognitipologia di visita medica, personalizzando le domande da sottoporre al clientee indicando le eventuali risposte di default, la seconda parte invece consiste nellacompilazione del questionario durante la visita medica del cliente da parte delmedico; naturalmente tutti i dati inseriti saranno salvati nella realtiva tabelladel database di Planet Hotel.Il secondo modulo tratta la gestione di un'agenda che organizza gli appuntamentiper la somministrazione di cure nel centro benessere, si tratta di un calendariomultidimensionale che consente la prenotazione, la modi�ca e al disdetta diun trattamento da parte di un operatore, attraverso l'utilizzo di un interfacciagra�ca interattiva che visualizzi la disponibilità delle risorse e del personale adisposizione, all'interno del centro benessere, in funzione del tempo.Si tratta dunque di un applicazione organizza in tempo reale l'attività del per-sonale e l'impiego delle risorse, rendendo possibile la consultazione e la stampadi un programma giornaliero da parte dell'addetto ai trattamenti e alle cure.Il terzo e ultimo modulo è l'idea di partenza del progetto di stage ovveroun'applicazione di gestione di CRM per palmari PocketPC (con sistema op-erativo Windows Mobile 5 o 6) o smartphone (con sistema operativo Android)che consenta all'operatore la consultazione e modi�ca del proprio programmadi attività giornaliero e la registrazione e addebito dei trattamenti e prodottisomministrati al cliente. L'applicazione mobile prevede la sicronizzazione deldatabase mobile con il database consolidato qualora fosse disponibile la con-nessione con la rete wireless, consentendo anche l'esecuzione in modalità o�-

line dell'applicazione scrivendo le modi�che sul database mobile in attesa dellasincronizzazione successiva.

2.2.1 Evoluzione del progetto

Durante la fase di de�nizione del progetto con il tutor aziendale ci siamo resiconto che i meccanismi di funzionamento di un'applicazione per la gestione delCRM di un centro wellness potevano benissimo essere generalizzati e adattatia qualsiasi punto vendita presente della realtà alberghiera, infatti è possibileindividuare molti elementi in comune tra i vari esercizi di commerciali o dierogazione di servizi: nell'erogazione di un servizio, una stanza contenente stru-mentazioni potrebbe essere vista come una risorsa, allo stesso modo il banconedi un bar, la cassa di un mini-market e il tavolo di un ristorante potranno essereconsiderati come risorse alle quali collegare l'ordine di beni e servizi richiesti daun cliente.Analogamente i beni e servizi possono essere distinti in categorie (come lepietanze servite in un ristorante vendono raggruppate in �portate�) e individuatiin maniera generica come articoli, caratterizzati da un prezzo unitario.

10

2.3. OBIETTIVO DEL PROGETTO

Allo stesso modo l'utente dell'applicazione può essere benissimo un cameriereche prende le ordinazioni ai tavoli di un ristorante, un massaggiatore che erogatrattamenti benessere utilizzando e addebitando prodotti quali oli, creme o can-dele profumate, oppure una cassiera di un minimarket all'interno delle strutturaalberghiera o addirittura un responsabile addetto alle gite guidate organizzatedall'Hotel stesso.Queste considerazioni hanno portato all'allargamento del dominio del progettonon più solo al modulo di Planet Hotel relativo al wellness, ma anche al modulocontenente la gestione di un bar, di uno ristorante o di un punto vendita gener-ico, rendendo così l'oggetto del progetto di stage un applicazione orientata alCRM estremamente versatile, anche in previsione di destinazioni future.

2.3 Obiettivo del progetto

L'obiettivo del progetto di stage è dunque la realizzazione di un'applicazionemobile per la gestione del CRM di un punto vendita generico all'interno di unarealtà turistica.L'applicazione risultante deve avere queste caratteristiche:

• Il software deve poter mettere in condizione l'operatore di poter e�ettuareordinazioni di beni e servizi richiesti da un cliente, e di poterne addebitareil costo nel relativo conto, qualora il cliente di tipo �residente� o aventeuna prenotazione attiva.

• Un aspetto fondamentale consiste nel fatto che l'applicazione sia solida esicura, soprattutto in caso di malfunzionamento del dispositivo sul qualeviene eseguita.

• Deve essere possibile il cambio del punto vendita e di operatore durantel'esecuzione, attraverso il salvataggio del contesto precedente e il carica-mento da database di quello nuovo.

• L'applicazione deve essere scritta e pensata in funzione dell'utilizzo che nefarà l'utente �nale, quindi il software deve essere di semplice utilizzo maal tempo stesso completo.

• Il programma deve poter sfruttare i tempi di inutilizzo, per poter eseguirele necessarie operazioni di sincronizzazione tra il database consolidato equello mobile, le quali in genere risultano lunghe e possono portare aindesiderati rallentamenti di sistema.

• L'applicazione mobile deve poter essere eseguita su dispositivi mobile qualiPocketPC e smartphone Android.

,

2.4 Vincoli applicativi

Durante la fase di prima analisi del progetto sono stati identi�cati vincoli im-posti dalle tecnologie coinvolte nello sviluppo dell'applicazione mobile i quali sipossono dividere in due categorie, software e hardware.

11

CAPITOLO 2. IL PROGETTO

2.4.1 Vincoli software e strutturali

Essendo il progetto un'applicazione mobile che e�ettua una sincronizzazione conalcune tabelle del database di Planet Hotel, tra i vincoli imposti vi è proprioquello di dover sincronizzare il database mobile con un database consolidato ditipo SQL Anywhere versione 8, d'altro canto però in caso di un possibile riscrit-tura di Planet Hotel, le modi�che da apportare all'applicazione per renderlacompatibile con la nuova versione, deve richiedere il minor dispendio di tempoe risorse; ciò signi�ca che la sincronizzazione dovrà avvenire anche con databaseconsolidati di tipo HFSQL (descritti nel paragrafo relativo a gli IDE della lineaWindev).Un ulteriore vincolo richiesto è la possibilità di far eseguire l'applicazione sudiversi dispositivi mobile, ciò comporta restrizioni riguardo alle tecnologie sup-portate; per fare un esempio, il sistema operativo Android non ammette tuttorala possibilità di utilizzare database di tipo diverso da SQLite.

2.4.2 Vincoli hardware

Altri vincoli di non poco conto, riscontrati durante lo sviluppo e il test, derivanodalla necessità di eseguire il deployment dell'applicazione anche per dispositivicon Windows Mobile 5 e 6, tali dispositivi sono in genere PocketPC ed hannoperò una limitata potenza di calcolo e ancor più lento accesso alla memoriasecondaria, tanto che l'esecuzione di query su tabelle di un database mobile,risulta richiedere un tempo non indi�erente, qualora i record da elaborare sianonumerosi.

Codice Descrizione Tipo

V01_St Il database mobile deve avere una strutturacombatibile con quella del database di PlanetHotel

Strutturale

V02_Sf Possibilità di sincronizzazione con i databasedi tipo Sybase SQL Anywhere 8

Software

V03_Sf Possibilità di sincronizzazione con databaseHyperFile SQL

Software

V04_Sf Nella versione per Android il database mobiledeve essere obbligatoriamente SQLite

Software

V05_Sf L'applicazione deve poter essere eseguita susistemi operativi Windows Mobile

Software

V06_Hd L'applicazione deve poter essere usabile anchenell'esecuzione su dispositivi PocketPC

Hardware

Tabella 2.1: Tabella riassuntiva dei vincoli hardware e software

12

Capitolo 3Stage

3.1 Piani�cazione delle attività

Al �ne di identi�care le attività da svolgere durante lo stage e dare loro uncontesto temporale, su indicazione del tutor universitario, è stato stilato undocumento nel quele venivano speci�cati gli obiettivi dello stage e un pianodi lavoro su�cientemente dettagliato, tale da fornire sia allo studente che altitolare una visione globale delle attività di stage.Nelle sezioni successive sono riportati i contenuti di quel documento.

3.1.1 Obiettivi dello stage

Gli obiettivi dello stage sono articolati in modo da ottenere la più alta prob-abilità di ottenere al termine dello stage un'applicazione solida e che rispetti iparametri di qualità richiesti dall'azienda.

Obiettivi primari

Gli obiettivi primari sono stati divisi in due categorie, dove gli obiettivi del-la seconda categoria potranno essere sviluppati convenientemente solo qualorasiano stati conseguiti tutti quelli presenti nella prima categoria.Qui di seguito vengono riportati gli obiettivi in maniera schematica e rispettandola divisione in categorie di appartenenza precedentemente accennata.

1. Studio di fattibilità

• Indagine e scelta della tecnologia per lo sviluppo dell'applicazionemobile.

• Indagine e scelta della tecnologia adatta alla sincronizzazione trail database mobile e il database consolidato, secondo esigenze discalabilità e compatibilità.

• Sviluppo di un prototipo di applicazione mobile, per eseguire testsulla sincronizzazione tra Database mobile e consolidato, utilizzandole tecnologie scelte.

13

CAPITOLO 3. STAGE

2. Progettazione e Sviluppo

• Progettazione e creazione del database mobile, attraverso la de�nizionedelle tabelle e funzioni necessarie alla sincronizzazione.

• Realizzazione del diagramma delle classi per il funzionamento del-l'applicazione.

• Progettazione e realizzazione delle form gra�che funzionali all'appli-cazione.

Obiettivi secondari

Gli obiettivi secondari dello stage consistono in un modulo relativo all'interfac-cia dell'applicazione mobile con dispositivi di stampa attraverso le stampantipresenti in rete.

• Progettazione e realizzazione di un modulo applicativo dedicato alla creazionedi report stampabili.

• Progettazione e sviluppo di funzioni di interfacciamento con stampanti direte per la stampa di report.

Obiettivi opzionali

Gli obiettivi opzionali del progetto consistono nella realizzazione di un mod-ulo integrativo all'applicazione per la gestione e controllo delle attività di unoperatore all'interno della struttura alberghiera.

• Progettazione e realizzazione di un'interfaccia utente per gestione e l'or-ganizzazione delle attività.

• Realizzazione di un'interfaccia gra�ca per la consultazione dell'agendarelativa all'operatore.

3.1.2 Approccio al progetto

Un fattore non trascurabile nella stesura del piano di progetto è stato il tenereconto delle risorse in termini di personale che sarebbero state impiegate nellosvolgimento delle attività di progetto.Come precedentemente spiegato nel capitolo riguardante il progetto, in partico-lare nella strategia aziendale, con ogni probabilità mi sarei trovato a svolgere dasolo la grande maggioranza delle attività preliminari di progetto, con la �ebilesperanza di essere a�ancato da una persona aggiuntiva durante la fase di svilup-po; ciò nonostante avrei potuto sempre contare nel supporto del tutor aziendalequalora avessi avuto bisogno di chiarimenti sui meccanismi di funzionamento esulla struttura del PMS aziendale.Tenendo conto di questi fattori, in accordo col tutor aziendale, ho preferito unapproccio simile a quello de�nito in ingegneria del software come modello in-crementale (ISO 12207); questa scelta è stata dettata soprattutto dal fatto diessere il solo dedicato a questo progetto, il che mi permetteva di avere una vi-sione globale del progetto, a patto di dover dedicare molto tempo all'analisi deldominio e allo studio di fattibilità.Nella fase di progettazione mi sarei dedicato alla divisione dell'applicazione in

14

3.1. PIANIFICAZIONE DELLE ATTIVITÀ

moduli secondo una sequenza conveniente, in modo da procedere nello sviluppoiterando il ciclo presente nel modello incrementale (progettazione nel dettaglioe realizzazione) �ntanto il risultato non fosse stato quello gradito, e procederecon il modulo successivo.

Figura 3.1: Ciclo di sviluppo incrementale secondo lo standard ISO 12207

3.1.3 Piano di lavoro

Tenuto conto di tutte le premesse, al �ne di ottenere un completo conseguimentodel maggior numero di obiettivi descritti in precedenza, ho stilato con il tutoraziendale un dettagliato piano di lavoro, secondo il quale il progetto di stagedoveva essere diviso in cinque fasi distinte, aventi una durata stimata in giornatelavorative di 8 ore ciascuna.

Analisi di dominio

• Nozioni sull'organizzazione interna di una struttura ricettiva, in partico-lare nei reparti di ricevimento, segreteria e operativo nel settore turisticoe alberghiero.

• Studio dei �ussi dati e dei meccanismi di gestione clienti e operazioni,secondo l'aspetto del CRM.

Durata: 5 giorni lavorativi.

Studio della struttura di un software gestionale

• Studio delle applicazioni già esistenti nel PMS delle aziende nel settorealberghiero.

15

CAPITOLO 3. STAGE

• Analisi della struttura dei database utilizzati dalle applicazioni in uso alleaziende del settore.


Studio di fattibilità

• Indagine sugli strumenti di sviluppo di applicazioni per PDA.

• Analisi delle tecnologie per la sincronizzazione tra database mobile e databaseconsolidato.

• Studio degli strumenti per la produzione di report e stampa su periferichedi rete.

• Stesura documentazione relativa allo studio di fattibilità


Progettazione

• Divisione dell'applicazione in moduli software (database, gra�ca, connes-sioni e interfacce).

• Formalizzazione delle tabelle e relazioni nel database mobile

• De�nizione delle form gra�che di consultazione e inserimento dati.

• Stesura documentazione relativa alla progettazione, integrata con dia-grammi UML e use-case.


Sviluppo

• Attività di sviluppo dell'applicazione mobile

• Integrazione con il PMS aziendale

• Creazione ed esecuzione di test funzionali.


Prove di carico

• Prova conclusiva di carico, con l'esecuzione simultanea dell'applicazionesu più dispositivi.


16


Figura 3.2: Diagramma di Gantt riguardante il piano di lavoro

17

CAPITOLO 3. STAGE

3.1.4 Revisioni e controllo qualità

Nel periodo di prima concezione del progetto di stage il titolare ed io abbiamodeciso in comune accordo quelle che dovevano essere le linee guida per il controllodella qualità delle attività svolte durante lo stage.Data la diversa natura delle attività svolte a seconda della fase di progetto allequali appartenevano, sono stati decisi due diversi approcci nel controllo dellaqualità del lavoro svolto: revisioni di analisi e revisioni di sviluppo.Qui di seguito ho riportato le linee guida convenute, distinte in base alla fase incui il progetto si trovava.

Revisioni di analisi

Il comportamento da me adottato durante le fasi preliminari allo sviluppo èstato il seguente:

• In un breve bre�ng quotidiano sottoponevo all'attenzione del tutor azien-dale le informazioni da me raccolte e analizzate.

• Qualora sorgessero eventuali dubbi durante un'attività di analisi, sulletecnologie o su un meccanismo di Planet Hotel, avrei dovuto chiederechiarimenti al tutor aziendale, onde evitare fraintendimenti.

• Al termine di ogni singola attività descritta nel piano di lavoro sarebbestato fatto un punto della situazione, in modo da decidere come procederecon le attività successive.

Revisioni di sviluppo

Una volta completate le attività di analisi e di progettazione, è stata a�rontatala fase di sviluppo del software, e il comportamento convenuto per il controllodella qualità è stato così de�nito:

• Disegnata una form con i relativi oggetti gra�ci, avrei dovuto sottoporlaal tutor aziendale per veri�carne la chiarezza, in previsione dell'utilizzo diun utente �nale.

• Qualora una funzione richiedesse un tempo di calcolo eccessivamente pro-lungato e intaccare l'usabilità del sistema, avrei dovuto individuare lesoluzioni che a mio avviso fossero le più adatte, e sottoporre e discutere ilproblema con il tutor aziendale al �ne di individuare la soluzione migliore.

• Al termine dello sviluppo delle funzionalità presenti in una form e dopoaver eseguito tutti i test funzionali del caso, avrei dovuto presentare taleform, in esecuzione sul dispositivo mobile di test, all'attenzione del tutordi modo che ne potesse constatare il corretto funzionamento e l'e�ettivausabilità.

Questi controlli frequenti, soprattutto nella fase di sviluppo sono risultati fonda-mentali, poiché permettevano la retti�ca del funzionamento dell'applicazione intempi relativamente brevi, qualora il risultato non fosse stato quello desideratocome �nale dal tutor aziendale.

18


Rapporto settimanale

Per quanto riguarda la rilevazione da parte del tutor universitario del lavoroda me svolto durante lo stage aziendale, è stato concordato che ogni settimana,per le otto settimane corrispondenti della durata totale, avrei dovuto inviare aldocente un rapporto dettagliato riguardante le attività svolte, correlato di unoschema che quanti�casse lo stato nel raggiungimento degli obiettivi di stage informa percentuale.Questo report settimanale veniva inoltre sottoposto anche al tutor aziendale, inmodo tale da renderlo informato sullo stato globale sull'andamento del progettodi stage.

19

CAPITOLO 3. STAGE

3.2 Analisi e studio del dominio

Nelle settimane iniziali dell'attività di stage ho svolto un importante studioriguardante le operazioni eseguite dal personale di una struttura adibita al well-ness, e più in generale ai meccanismi riguardanti la vendita di beni e serviziall'interno di una struttura alberghiera.Grazie a un caso fortuito ho avuto l'occasione di e�ettuare un sopralluogo all'Ho-tel Mioni-Pezzato di Abano Montegrotto (PD), al di fuori dell'orario di lavoro, edi poter cosi raccogliere informazioni sulle tipologie di servizi erogati e rendermiconto delle situazioni reali che possono intervenire durante la somministrazionedi prodotti e cure all'interno di una struttura di quel tipo, benché non fosseroutilizzati dispositivi di tipo mobile.Successivamente ho iniziato lo studio del PMS aziendale (ovvero Planet Hotel),in modo da veder applicata l'esecuzione delle operazioni precedentemente stu-diate in un supporto di tipo software, tra cui l'inserimento di una prenotazioneoppure l'addebito sul conto di un cliente derivato dall'acquisto di un prodotto.In questo modo potevo comprendere il meccanismo di inserimento delle infor-mazioni sotto forma di record all'interno delle varie tabelle del database di Plan-et Hotel; ho studiato anche la struttura del database, composta dalle relazionitra le chiavi e le chiavi esterne che intercorrevano tra le tabelle, visualizzabiliattraverso l'ausilio degli strumenti di gestione gra�ci messi a disposizione dalDBMS SQL Anywhere 8 di Sybase.

3.2.1 Un'applicazione polivalente

Proseguendo nello studio dell'ambito wellness e delle applicazioni riguardantil'ambito alberghiero, tra cui applicazioni precedentemente studiate per la ges-tione di un ristorante, concepito internamente a Sintesi ma non ancora realizza-to, il tutor aziendale ed io ci siamo resi conto che il fatto di suddividere le curee i prodotti per tipologia, poteva essere fatto anche per un punto vendita chepotesse essere un negozio o un reparto ristorativo all'interno di una strutturaalberghiera.Le stesse similitudini intercorrevano persino nei meccanismi grazie ai quali gliaddetti del punto vendita ricevevano le ordinazioni.I clienti, di qualsiasi genere questi potessero essere (aziende, soggetti singoli,residenti, personale), possono essere individuati attraverso un numero interoidenti�cativo univoco, quindi le form gra�che e le funzioni di ricerca e selezionedel cliente all'interno dell'anagra�ca potevano essere eseguite indipendentementedal punto vendita nel quale il cliente richieda l'acquisto di un bene o l'erogazionedi un servizio.Ci siamo in�ne resi conto che il punto vendita che richiedeva il meccanismodi gestione più complesso è la struttura ristorativa, mentre tutti gli altri puntivendita richiedevano una gestione più semplice, tale da risultare una derivatasempli�cata della gestione di tipo ristorativo.Nei seguenti paragra� sono riportati alcuni esempi delle similitudini tra le strut-ture dati contenenti le ordinazioni per tre tipi di punti vendita apparentementeincompatibili.

20

3.2. ANALISI E STUDIO DEL DOMINIO

Punto vendita 1: ristorante

Comincio l'analisi di funzionamento riportando l'esempio del punto vendita ris-torativo. Dallo schema si possono notare gli elementi base che compongono unordine: l'ordine stesso, le �comande�, i dettagli d'ordine e le uscite, posizionatein funzione del tempo di vita di un ordine, il quale viene creato all'inizio delpasto e che viene chiuso nel momento un cui il cliente lascia il ristorante.Al ristorante un cliente può e�ettuare una o più ordinazioni (chiamate �coman-de� e distribuite nell'arco di tempo della durata del pasto), nelle quali vengonoordinate svariate portate e bevande (gli articoli presenti nel listino e chiamati�dettagli ordine� ) secondo una speci�ca sequenza di uscita (antipasti, primi,secondi), tali ordinazioni sono però raggruppate in un ordine.La complessità nella gestione delle uscite risulta chiara dallo schema temporaleriportato in seguito, infatti un dettaglio d'ordine può essere associato a un'uscitaindipendentemente dalla comanda a cui appartiene.

Figura 3.3: Diagramma temporale delle ordinazioni in un ristorante

Punto vendita 2: wellness center

Il secondo esempio di punto vendita è il centro benessere, qui il problema rela-tivo alle uscite degli articoli nel ristorante non si pone più, perciò avremo unasequenza di ordinazioni coerente con lo scorrere del tempo.Lo schema di seguito riportato tratta le richieste di un cliente ad un opera-tore, prima richiedendo tre prestazioni o prodotti (identi�cate dai tre dettagliordine, che possono essere un massaggio lombare(1), con miele(2) e candeleprofumate (3)), successivamente decide di richiedere altre tre prestazioni primadella chiusura del conto.Anche qui come per il ristorante, possiamo identi�care gli elementi base di unordine:

21

CAPITOLO 3. STAGE

• L'ordine, che viene creato al momento dell'arrivo del cliente e chiusoall'uscita dal centro.

• Le comande, che identi�cano le prestazioni.

• I dettagli ordine, che consistono nella prestazione e nei prodotti usati.

• Le uscite, che ora coincidono con l'erogazione delle prestazioni.

Figura 3.4: Diagramma temporale delle prestazioni erogate in un wellness center

Punto vendita 3: minimarket

L'ultima tipologia presa in considerazione è quella del minimarket. A mio avvisola più semplice in termini di meccaniche operative, il punto vendita minimarketriduce gli elementi dell'ordine, necessari in un ristorante, a coincidere tra loro.Come schematizzato dall'illustrazione possiamo vedere che l'ordine è compostoda una sola comanda e nasce nel momento in cui un cliente si presenta allacassa e viene chiuso nel momento del pagamento o dell'addebito degli articoliacquistati, i quali coincidono coi dettagli ordine.In questo caso quella che prima era chiamata uscita, coincide con la spesa delcliente, ed è unica.

22

3.3. SCELTA DEGLI STRUMENTI DI SVILUPPO

Figura 3.5: Diagramma temporale della spesa in un minimarket

3.3 Scelta degli strumenti di sviluppo

In questo paragrafo sono trattate le tecnologie prese in considerazione per losviluppo del progetto di stage, tenendo conto dei vincoli imposti dal dominio(vedi sezione �Vincoli� ).

3.3.1 Tecnologia per la sincronizzazione

Quella che secondo le previsioni e che poi si è rivelata la fase di studio di fattibil-ità più complessa è proprio quella riguardante la sincronizzazione tra databaselo consolidato e mobile. Tra tutte le tecnologie prese in esame nessuna ha po-tuto soddisfare tutti i vincoli imposti dal dominio. Per l'identi�cazione delletecnologie di sincronizzazione esaminate ho scelto la sigla �synchro� seguita daun numero sequenziale.Qui sotto è riportato il risultato dello studio di fattibilità riguardante le tec-nologie di sincronizzazione.

Synchro 1: Mobilink e Ultralite

La prima tecnologia di sincronizzazione presa in esame è quella fornita da SybaseSQL Anywhere 8 per la sincronizzazione dei database dei dispositivi mobile, at-traverso l'utilizzo simultaneo del database Ultralite e della tecnologia Mobilink.Ultralite è una tipologia di database estremamente leggero ma poco �essibile,infatti le query che possono esservi eseguite devono essere de�nite a priori (laversione 8 di SQL Anywhere non permette l'esecuzione di query con codice SQLcreato dinamicamente, ma solo attraverso query parametriche prede�nite).Mobilink è la tecnologia utilizzata per la gestione della sincronizzazione tradatabase prodotti da Sybase, per mezzo del modello client-server.Nell'immagine possiamo vedere in maniera schematica il funzionamento dellasincronizzazione attraverso la tecnologia Mobilink.

23

CAPITOLO 3. STAGE

Figura 3.6: Schema di sincronizzazione della tecnologia Mobilink

Utilizzando il programma Sybase Monitor Center è possibile creare e ma-nipolare la struttura di un database SQL Anywhere 8, ma cosa più importante,è possibile utilizzare un editor per la creazione dei �le necessari all'accesso aun database di tipo Ultralite, generato partendo dalla struttura di un databasepreesistente. La procedura per la creazione di un database Ultralite con unclient Mobilink integrato e dell'interfaccia di accesso di Java è la seguente:

1. Accedere a un database SQL Anywhere 8 attraverso una connessioneODBC.

2. Creare un utente di tipo Ultralite e attivare la sottoscrizione al databaseconnesso.

3. Aggiungere alla sottoscrizione creata tutte le tabelle necessarie all'appli-cazione che userà Ultralite.

4. Aggiungere alla sottoscrizione tutte le query parametriche necessarie allaconsultazione del database mobile.

5. Con�gurare nella sottoscrizione i parametri per la sincronizzazione viaMobilink.

6. De�nire e aggiungere al database consolidato eventuali trigger o proceduredi sincronizzazione.

7. Eseguire il comando da shell per la creazione del database Ultralite relativoalla sottoscrizione.

8. Generazione dei �le delle classi e dell'interfaccia in Java SE per l'accessoal database Ultralite e alle funzionalità di Mobilink.

Una volta eseguita questa procedura otterremo 3 �le:

• Un �le .jar contenente la struttura del database Ultralite e le funzioniMobilink.

24


• Un �le .db nel quale è persente il database Ultralite.

• Un interfaccia Java che descrive le funzioni di accesso al database mobilee per la sincronizzazione.

immagine mobilink

Figura 3.7: Struttura di un database Ultralite accessibile da un applicazioneJava

Considerazioni:

Per veri�care le potenzialità di questa tecnologia è stato sviluppato, in collabo-razione con un programmatore di Sintesi, un prototipo di applicazione Java (eC++ e�ettuata dal mio collega), che accedesse a un database di due sole tabellee che ne e�ettuasse la sincronizzazione in maniera bidirezionale.L'esito di questo esperimento ci ha portato alle seguenti conclusioni:

• Pur se dedicato a dispositivi mobile, sono necessarie librerie presenti inJava SE (Standard Edition), e assenti in Java ME (Mobile Edition), anulla ha portato l'individuazione e l'inserimento manuale delle librerienecessarie, a causa di un errore a runtime.

• La stessa cosa vale per l'integrazione con un prototipo di applicazione perAndroid, come prevedibile a causa dell'assenza delle librerie di JDBC.

• L'accesso a Ultralite attraverso librerie C++ (per dispositivi PocketPC)è risultato estremamente complicato a causa della scarsa documentazionein merito e dalla sollevazione di un errore generico in fase di esecuzionedell'applicazione C++.

• L'esecuzione dell'applicazione Java su dispositivi PocketPC avrebbe resonecessaria l'installazione di JVM per Windows Mobile 5 anche di tipo

25

CAPITOLO 3. STAGE

opensource (Maysaifu), ma dalla natura instabile e non contenenti lelibrerie necessarie.

• Visti i punti precedenti la scarsa cura nella segnalazione dell'entità deglierrori riscontrati nell'utilizzo dell'accesso a un database Ultralite, hannoreso la fase di test un esperienza piuttosto frustrante.

• Il dover ride�nire o creare nuove query, comporta la rigenerazione e lariscrittura dei tre �le attraverso i quali avviene l'accesso al database mo-bile, rendendo necessaria una lunga attività di test sulle modi�che appor-tate.

Ribadisco nuovamente che il DBMS utilizzato è SQL Anywhere 8, quello utiliz-zato dal ultima versione di Planet Hotel, probabilmente versioni più recenti ofuture del DBMS Sybase renderanno possibili le operazioni di integrazione danoi e�ettuate con insuccesso.

Synchro 2: collegamento remoto via ODBC

Non una vera e propria sincronizzazione quanto una connessione remota viaODBC al database di Planet Hotel. L'idea era quella di eseguire una lunga seriedi query di tipo select sulle tabelle del database consolidato (connesso remo-tamente via ODBC) al �ne di popolare il database mobile con le informazioniricevute, o in alternativa di costruire gli oggetti relativi a tali informazioni,per l'esecuzione dell'applicazione mobile. L'idea avrebbe potuto essere valida,poiché compatibile con qualsiasi DBMS con driver ODBC, purtroppo i vincolitecnologici �ssati la rendono irrealizzabile a causa dei seguenti problemi:

• Windows Mobile non fornisce nè un ODBC driver manager nè un ODBCadministrator, quindi nemmeno la possibilità di accesso a remoto viaODBC.

• Lo stesso vale per le applicazioni per Android, dove sono presenti libreriesolo per SQLite.

• La rete aziendale avrebbe di�cilmente supportato il trasferimento di molinon indi�erenti di dati, sia in termini di a�dabilità del segnale (per retiWi-�), sia in termini di velocità di trasferimento.

Synchro 3: OLEDB via ODBC Sybase, HFSQL classic e HFSQL

Mobile

Questa soluzione consiste in un applicazione �ponte� realizzata in Windev cheaccede al database di Planet Hotel attraverso l'utilizzo dello standard OLEDBvia connessione ODBC, tale standard avrebbe premesso la scrittura e la let-tura delle informazioni presenti nel database di tipo SQL Anywhere 8. Dovràesserci un modulo software in grado di e�ettuare una sincronizzazione tra leinformazioni ricevute dal database di Planet Hotel e un database di strutturaidentica ma creato usando HFSQL Classic. Tutto ciò a�nché possa essere uti-lizzato lo strumento di sincronizzazione tra un database HFSQL classic e undatabase HFSQL Mobile (che è utilizzato dall'applicazione mobile) presente inWindev e Windev mobile; la tecnica di sincronizzazione automatica utilizzata

26


prende il nome di Universal Replication.Nell'immagine sottostante è schematizzata la struttura dell'applicazione che fada �ponte� ai due database.

Figura 3.8: Struttura dell'applicazione �ponte�

La tecnica per la sincronizzazione chiamata Universal Replication è uno deiquattro metodi di sincronizzazione per database HFSQL che gli IDE Windevmettono a disposizione, ma è l'unica che coinvolge database HFSQL Mobile.Il meccanismo utilizzato per questo tipo di sincronizzazione consiste nella creazionee nell'invio di �le .rpa tra le entità master (database consolidato) e uno o piùsubscriber (database mobile). La procedura utilizzata per la con�gurazione delleentità precedente descritte è la seguente:

1. Attivare l'Universal Replication attraverso il comando speci�co.

2. Creare il �le identi�catore del Master replica.

3. Creare un �le Subscribe Replica per ogni dispositivo mobile dando comeparametro il riferimento al Master Replica

4. Avviare la sincronizzazione iniziale dei subscribers con le informazioni delMaster :

• Creare il �le Movable Replica (.rpa) dal Master

• Inviarlo al subscriber tramite condivisione �le o altro metodo.

• Richiamare il comando di sincronizzazione dal subscriber una voltaterminato il trasferimento del �le.

5. Procedura completata, ora è possibile l'invio e la ricezione di �le Movable

Replica in maniera unidirezionale e bidirezionale.

27

CAPITOLO 3. STAGE

Figura 3.9: Schema del funzionamento della tecnica Universal Replication diWindev

Considerazioni: Questa soluzione, per quanto complessa possa risultare, èda considerare la migliore tra quelle viste �nora. La soluzione è valida sia nel-l'eventualità in cui venga mantenuto il database attuale di Planet Hotel (al qualesi accede con OLEDB via ODBC), sia nell'eventualità di una quinta edizione delPMS aziendale realizzata in Windev, dato che la sincronizzazione tra databaseHFSQL è già prevista dalla Universal Replication, quindi l'applicazione �ponte�non sarebbe più richiesta al �ne della sincronizzazione e gli script di con�g-urazione delle entità Master e Subscriber diventerebbero riutilizzabili. Tra ifattori da prendere in considerazione riguardo a questa tecnica è il fatto cheutilizzando lo standard OLEDB via ODBC si perde ogni riferimento alle chi-avi primarie ed esterne delle tabelle, e di conseguenza anche le relazioni tra letabelle.

Synchro 4: accesso nativo a database Sybase e HFSQL Mobile

Questa tecnica è molto simile rispetto a quella vista in precedenza, eccezionefatta per l'accesso al database di Planet Hotel, il quale non avverrebbe piùattraverso l'uso combinato di OLEDB e ODBC, ma tramite il modulo di accessonativo a database Sybase. Ciò permetterebbe di mantenere le chiavi e le relazionitra le tabelle, oltre alle procedure e ai trigger. Purtroppo quest'ipotesi è statasubito scartata per due motivi essenzialmente economici:

• Il prezzo del modulo software di accesso nativo è molto alto, nonché lalicenza per il suo utilizzo è valida per un solo computer.

• Anche in caso di acquisto del modulo di accesso nativo, il tipo del databaseal quale si vuole accedere deve essere Adaptive Server Enterprise 10 (ASE10) o superiore, quindi sarebbe necessario un avanzamento di versione peril database di Planet Hotel (dunque gli l'acquisto della versione ASE 12di Sybase e del modulo di accesso nativo a Sybase di Windev)

28


3.3.2 Soluzione scelta per la sincronizzazione

Dopo aver preso in esame le varie possibilità per e�ettuare la sincronizzazione tradatabase consolidato e database mobile, possiamo riepilogare in forma tabularele relazioni tra soluzione considerata e soddisfacimento dei vincoli (�Si� se ilvincolo risulta soddisfatto, �No� se non soddisfatto).

Codice Vincolo Synchro 1 Synchro 2 Synchro 3 Synchro 4

V01St Si Si Si SiV02Sf Si No Si NoV03Sf No No Si SiV04Sf No No No NoV05sf No No Si SiV06Hd No No Si Si

Realizzabile Si No Si Si

Fattibilità Si No Si No

Tabella 3.1: Tabella di soddisfacimento dei vincoli da parte delle tecnologie viste

Risulta chiaro il fatto che sia per quanto riguarda il numero di vincoli rispet-tati e per la reale fattibilità, tra le soluzioni prese in considerazione la soluzione�Synchro 3� sia la migliore, poiché è realizzabile senza l'acquisto di ulterioresoftware.Dalla tabella emerge anche il fatto che nessuna tra le soluzioni individuate sod-disfa il vincolo V04sf, ovvero l'utilizzo di database SQLite su dispositivi An-droid, perché attualmente la sincronizzazione di database SQLite non è ancorastata implementata per né database di tipo Sybase né di tipo HFSQL. Pre-sentate queste considerazioni al tutor aziendale abbiamo appurato il fatto chel'aspetto negativo nella realizzazione della soluzione �Synchro 3� sta nel poterrichiedere �no a due mesi di lavoro e nell'impiego di più di una persona, datala complessità e la delicatezza nella formalizzazione e sviluppo delle funzioni disincronizzazione presenti nell'applicazione �ponte�.Ciò ha portato il tutor aziendale a prendere le seguenti conclusioni riguardantilo svolgimento delle attività e il ridimensionamento degli obiettivi dello stage:

• Accantonare temporaneamente la parte del progetto di stage relativa allasincronizzazione tra database di Planet Hotel e quello di WalkingPH, evalutare la possibilità che diventi materia per uno stage.

• Realizzare l'applicazione WalkingPH attraverso l'utilizzo del IDE WindevMobile 16 e e�ettuando il deployment su dispositivi con sistemi opera-tivi Windows Mobile 5 e 6, nella speranza che nelle versioni successivedi Windev possa essere disponibile l'utilizzo del Universal Replicationo di una tecnica simile anche per sincronizzare database di applicazioniAndroid.

29

CAPITOLO 3. STAGE

3.3.3 L'IDE utilizzato: Windev Mobile 16

L'IDE scelto per la realizzazione dell'applicazione WalkingPH è il sistema disviluppo integrato Windev Mobile 16 della linea di prodotti Windev della soft-

ware house francese PCSoft. In realtà la scelta di questo ambiente di sviluppoera già presa in considerazione dal tutor aziendale �n nei primi studi prelim-inari sul progetto, vista l'imminente inizio della realizzazione di Planet Hotelproprio con i prodotti della stessa linea (per informazioni aggiuntive riguardo aiprodotti Windev consultare l'appendice A). Come database mobile è stato scel-to, come prevedibile, HFSQL Mobile, data la concreta possibilità di poter esseresincronizzato con un database HFSQL classic, ovvero il database col quale verràrealizzata la nuova versione di Planet Hotel.L'IDEWindev Mobile 16 integra al suo interno strumenti di tipo CASE orientatia un metodo di sviluppo RAD. Purtroppo in Sintesi era ed è tuttora presenteuna sola licenza d'utilizzo per l'IDE �nora descritto, ciò signi�ca che anchedurante la fase di sviluppo, non sarei stato a�ancato dal personale dell'azienda.

Il metodo di sviluppo RAD

Figura 3.10: Confronto tra il metodo di sviluppo RAD ed il metodo tradizionale

La tecnica di sviluppo RAD prevede l'utilizzo di strumenti CASE per larealizzazione di prototipi di applicazione, i quali vengono integrati di nuovefunzionalità secondo un metodo iterativo, ripetuto �no a quando il risultatoottenuto coincida con quello desiderato. Questo metodo di sviluppo si puòapplicare non solo all'intera applicazione, ma anche ai componenti software e�no ai singoli oggetti gra�ci; tale metodo consente allo sviluppatore di teneresotto controllo lo stato di avanzamento nella realizzazione del software grazie auna visione globale di tutte le funzionalità in esso implementate. I principalisvantaggi del metodo RAD sono:

30


• La scarsa scalabilità del risultato �nale, dato che le migliorie sono realiz-zabili solo mediante ulteriori iterazioni della tecnica di sviluppo RAD.

• Il rischio di appesantire gradualmente l'applicazione durante le iterazionidi sviluppo, senza che lo sviluppatore ne abbia una percezione immediata,quindi intaccare irrimediabilmente l'usabilità dell'applicazione stessa.

Proprio per evitare quest'ultimo aspetto le prove e�ettuate avvenivano su dis-positivi mobile reali (PocketPC iPAQ) e non solo attraverso il simulatore messoa disposizione da Windev Mobile.

I problemi riscontrati

Purtroppo i prodotti della linea Windev non hanno solo caratteristiche positive.Come confermato dal forum u�ciale e non u�ciale, sono presenti molti bug,distribuiti in maniera abbastanza omogenea, alcuni di questi di lieve entità, al-tri clamorosi.Per fare un esempio di bug di entità rilevante, le funzioni collegate a un eventogenerato dall'interazione dell'utente con un componente gra�co talvolta, nonvengono eseguiti come l'utente si aspetterebbe, se non addirittura ignorati.Un altro aspetto molto carente dei prodotti Windev è costituito dalla docu-mentazione, inadeguata e a volte assente: funzioni molto importanti fornite dalIDE, che meriterebbero un approfondimento dettagliato e degli esempi di uti-lizzo, sono riassunte in poche righe, costringendo l'utente a sperimentarne luistesso le modalità di utilizzo.Tutto questo comporta un iniziale dispendio di tempo ed energie da partedell'utente per cercare una soluzione alternativa alle sue esigenze.

31

CAPITOLO 3. STAGE

3.4 Progettazione

Nonostante le modi�che apportate agli obiettivi di progetto in fase di studio difattibilità, la progettazione dell'applicazione WalkingPH è stata svolta coerente-mente con quanto preventivato nel piano di lavoro; ciò signi�ca che le attivitàrelative alla progettazione sono state da me svolte rispettando un programmadiviso in quattro punti, i quali sono esposti nei paragra� successivi.

3.4.1 Progettazione del database

Il database per l'applicazione mobile WalkingPH è stato progettato in mododa avere una struttura il più simile possibile a quella di Planet Hotel ma nonnecessariamente identica.Infatti nel database mobile ci sono due tipi di tabelle caratterizzate dall'uso chene fa l'applicazione mobile.

Tabelle �Consultate�

Le tabelle consultate contengono tutti i dati che l'applicazione necessita per lacostruzione di un contesto nel quale l'utente andrà ad operare.Queste tabelle non sono necessariamente di struttura identica a quella usatanel database di Planet Hotel, infatti essendo su�ciente una sincronizzazioneunidirezionale proveniente dal database consolidato, essa può avvenire tramitel'ausilio di viste speci�che riguardanti solo le informazioni necessarie all'appli-cazione, in maniera tale da non appesantire la trasmissioni di dati durante lasincronizzazione con informazioni super�ue.Dato il numero considerevole di tabelle di questa tipologia è stata e�ettuata unulteriore suddivisione logica di queste in due componenti, in base all'ambito diutilizzo:

• Anagra�ca clienti e prenotazioni alle quali appartengono tutte letabelle che registrano i dati anagra�ci dei clienti e suddividono questia seconda della tipologia di prenotazione e�ettuata.

• Le tabelle relative alla gestione dei listini dei punti vendita, le qualiorganizzano le informazioni sugli articoli presenti nei punti vendita e lecaratteristiche ad essi collegate.

Tabelle �Modi�cate�

Le tabelle che appartengono a questa categoria sono soggette a operazioni di in-serimento, modi�ca e cancellazione durante l'esecuzione dell'applicazione Walk-ingPH, proprio per questo mantengono la stessa struttura del database consol-idato.Una tabella degna di nota è quella denominata �System�, al cui interno è pre-sente un solo record contenente tutti i parametri di sistema dell'applicazione,comprese le informazioni relative allo stato dell'applicazione durante il prece-dente utilizzo, in modo da non richiedere l'utente di de�nire ad ogni avvio ilcontesto nel quale opera (potrà cambiarlo in qualsiasi momento successivamenteall'avvio, se non è il contesto da lui desiderato).

32

3.4. PROGETTAZIONE

Struttura delle tabelle per la gestione listini

Di particolare rilevanza e complessità è la struttura relativa alla gestione i listinile cui tabelle appartengono alla categoria �Consultate�.Infatti alla selezione del punto vendita desiderato l'applicazione deve poter cari-care l'intero listino ad esso collegato, comprensivo delle caratteristiche degliarticoli ivi contenute:

• il prezzo dell'articolo nel relativo punto vendita,

• la stampante dalla quale stampare la richiesta dell'articolo,

• il tipo di addebito al quale l'articolo appartiene,

• se l'articolo è presente nelle o�erte del giorno (tabella �Menu_del_ giorno�),

• la categoria di cui fa parte l'articolo (chiamata �Portata�) e il colore aquesta associato.

Come risulta chiaro a una prima visione, il nome dato alle tabelle è dovutoalla precedente destinazione di gestione ristorante, poi generalizzata in puntovendita generico.

33

CAPITOLO 3. STAGE

Figura 3.11: Tabelle relative ai agli articoli e ai listini dei punti vendita

34

3.4. PROGETTAZIONE

3.4.2 Divisione in moduli software

Figura 3.12: Diagramma delle relazioni tra i moduli software di WalkingPH

In questa fase della progettazione dell'applicazione, grazie alle conoscenzeacquisite durante lo studio delle altre applicazioni CRM nella fase di studio deldominio, mi è stato possibile suddividere l'applicazione in moduli aventi speci-�che funzionalità e il più possibile indipendenti l'uno dall'altro; i diagrammiusati per descrivere la struttura dei moduli software e formalizzarne le funzion-alità sono i diagrammi casi d'uso (use-case diagrams), appartenenti al linguag-gio di modellazione UML. I moduli software di cui è composta l'applicazioneWalkingPH sono:

1. Autenticazione: gestisce l'identi�cazione e l'accesso di un operatore.

2. Schermata Principale: visualizza e permette la modi�ca del contesto.

3. Utilities: modulo per la modi�ca dei parametri dell'applicazione e stru-menti per l'amministratore.

4. Risorse: visualizza lo stato delle risorse e l'accesso agli ordini ad essecollegate.

5. Gestione ordine: permette la gestione delle ordinazioni di un cliente, edè diviso in tre sotto-moduli

• Tab Comanda, per gestire l'inserimento degli articoli.

• Tab Conto, per la modi�ca e il riepilogo delle ordinazioni.

• Tab Cliente, permette la ricerca e selezione di un cliente dall'ana-gra�ca per collegarlo all'ordine corrente.

6. Agenda: modulo per il CRM delle strutture wellness.

35

CAPITOLO 3. STAGE

Di tutte questi moduli sono stati de�niti i casi d'uso attraverso gli appositi use-case diagrams integrati durante la stesura della documentazione relativa allafase di progettazione.

Il modulo per la gestione ordine

Questo modulo software è il importante e complesso tra i sei, infatti è il vero eproprio nucleo polivalente nella gestione delle vendite; il modulo della gestioneordini è a sua volta suddiviso in in tre tab distinte ma attive contemporanea-mente e aggiornate in tempo reale poiché condividono gli stessi dati. Nellesezioni successive la relazione procede con l'esposizione dei formalismi usati perla de�nizione dei casi d'uso e delle funzionalità proprie delle due tab di maggiorrilevanza tra le tre presenti nella gestione ordine: la tab �Comanda� e la tab

�Conto�.

Modulo 5.1 : la tab Comanda

Figura 3.13: Diagramma dei casi d'uso della tab �Comanda�

Precondizioni:

Lo stato dell'ordine deve essere de�nito come �aperto�.Descrizione del sotto-modulo:

Quando questa tab è attiva permette la selezione di un articolo presente a listino,la quantità desiderata e le informazioni aggiuntive. Nel caso di un punto venditadi tipo ristorativo, sono attivate e gestite le varianti dell'articolo e la possibilitàdi richiedere un articolo non presente a listino.Funzionalità di base:

• Inserimento di un nuovo dettaglio ordine nella comanda.

• Visualizzazione e selezione di un articolo dal listino.

• Determinazione della quantità.

36

3.4. PROGETTAZIONE

Funzionalità desiderabili:

• Gestione delle varianti.

• Ricerca di un articolo nel listino.

• Inserimento di un articolo fuori listino.

Modulo 5.2 : la tab Conto

Figura 3.14: Diagramma dei casi d'uso della tab �Conto�

Descrizione del sotto-modulo:

In questa tab sono inseriti e resi disponibili all'utente gli strumenti di riepilogoe di modi�ca o eliminazione di singoli dettagli d'ordine.

Funzionalità di base:

• Visualizzazione e modi�ca dell'intero ordine.

• Visualizzazione e modi�ca della comanda corrente.

• Inserimento di un messaggio in testa alla comanda corrente.

• Salvataggio della comanda corrente e delle modi�che all'ordine nel database.

Funzionalità desiderabili:

• Visualizzazione del riepilogo degli articoli raggruppati.

• Visualizzazione del riepilogo delle categorie di articoli dell'ordine.

37

CAPITOLO 3. STAGE

3.4.3 Analisi dei requisiti

In questo paragrafo sono elencati e classi�cati i requisiti relativi ai moduli soft-ware e alle loro funzionalità. Per quanto riguarda la classi�cazione dei requisitiè stato utilizzata la seguente codi�ca per identi�care il requisito.

• Il codice che identi�ca ogni requisito avrà come prima lettera la letteraR maiuscola, per non confondere il requisito con il codice dei vincoli cheiniziano con la lettera V.

• La seconda lettera del codice del requisito indica la precedenza

� P per primario,

� S per secondario,

� O per opzionale.

• La terza lettera è minuscola corrisponde alla tipologia di requisito

� f per funzionale,

� p per prestazionale,

� q per qualitativo.

• L'ultima parte del codice identi�cativo del requisito consiste in un numerodecimale con la classi�cazione decima Dewey (DDC) la quale utilizza seriedi numeri interi positivi, separati da un punto, che indicano il contesto diappartenenza del requisito secondo una classi�cazione gerarchica.Quindi viene formata una gerarchia nella quale, partendo da sinistra,:

1. Il primo numero indica il modulo software a cui appartiene il requisito(visti nella sezione precedente).

2. Il secondo numero indica il requisito all'interno del modulo, fattaeccezione per il modulo ordini, nel quale la cifra indica la tab diappartenenza del requisito.

3. Qualora fosse presente una terza cifra, signi�ca che il requisito in re-altà è un sotto-requisito, il quale deve essere soddisfatto a�chè il req-uisito associato (indicato dal secondo numero) possa essere anch'essosoddisfatto (secondo la scala gerarchica).

I requisiti riportati non sono stati de�niti tutti in fase di progettazione,infatti l'analisi è stata integrata di volta in volta con nuovi requisiti (perlopiùsecondari) secondo le richieste del tutor aziendale.Procedo ora con la descrizione dei requisiti, comprensivi di una breve descrizione,partendo dal primo modulo software.

38

3.4. PROGETTAZIONE

Autenticazione

Codice Nome Descrizione

RPf_1.1 Autenticazione op-eratore

Immissione di nome utente e password dell'opera-tore negli appositi campi gra�ci e veri�ca della lorocorrispondenza

RSf_1.2 Autenticazione am-ministratore

Veri�ca della corrispondenza della password dell'am-ministratore, per l'accesso agli strumenti del modulo�Utilities�

RPf_1.3 Identi�cazionetipologia operatore

Lettura delle informazioni sull'operatore da databasee determinazione della categoria di appartenenza

Tabella 3.2: tabella dei requisiti del modulo di autenticazione

Schermata principale


RPf_2.1 Selezione contesto Funzionalità di modi�ca del contesto nel qualel'operatore utilizza il dispositivo mobile

RPf_2.1.1 Selezione puntovendita

Selezione per mezzo di combobox del punto vendi-ta e della cassa ad esso collegata, tra quelli presen-ti nel database mobile. Questo determinerà il listi-no da caricare in memoria qualora la selezione fosseconfermata

RPf_2.1.2 Selezione sala Selezione attraverso combobox dello stabile e dellasala a cui si fa riferimento per il caricamento dellerisorse

RSq_2.1.3 Selezione in memo-ria

Preselezione del punto vendita, della cassa, della salae dello stabile in base allo stato dell'applicazione oalle selezioni salvate in precedenza

RPf_2.2 Caricamentocontesto

Funzionalità di caricamento in memoria del listinodel punto vendita e delle risorse della sala

RPf_2.3 Chisura sessione Funzionalità di chiusura della sessione, de-allocazione del listino del punto vendita, e ritornoalla schermata di autenticazione

RPq_2.4 Visualizzazione del-lo stato

Visualizzazione attraverso una forma tabulare delleinformazioni relative allo stato e al contestodell'applicazione

RPf_2.5 Accesso a Risorse Nel caso in cui l'operatore che ha e�ettuato l'acces-so fosse un cameriere o un commesso, sarà possi-bile accedere al modulo riguardante la gestione dellerisorse

continua nella pagina successiva

39

CAPITOLO 3. STAGE

Tabella 3.3 � continua dalla pagina precendente


RSf_2.6 Accesso ad Agenda Nel caso in cui l'operatore che ha e�ettuato l'accessofosse un massaggiatore di un centro benessere, saràpossibile accedere al modulo riguardante la gestionedell'agenda.

Tabella 3.3: Tabella dei requisiti del modulo relativo alla schermataprincipale

Utilities


RSf_3.1 Gestione dispositividi stampa

Funzionalità di gestione dei dispositivi per la stampadi report e un test per la veri�ca del funzionamentodi questi

RSf_3.2 Test di connessione E�ettua un test delle funzionalità di collegamentocon le risorse di rete.

RSf_3.3 Avviosincronizzazione

Avvio delle operazioni per la sincronizzazione unidi-rezionale dal database consolidato verso il databasemobile

RSq_3.4 Impostazionidell'applicazione

Form gra�ca per l'inserimento e la modi�ca deiparametri di funzionamento dell'applicazione. tracui l'identi�cativo del database subscriber, l'identi-�catore relativo al terminale e l'indirizzo IP relativoal terminale usato.

Tabella 3.4: Tabella dei requisiti del modulo Utilities

Risorse


RPq_4.1 Visualizzazione del-lo stato delle risorse

Visualizzazione gra�ca attraverso un looper dellerisorse presenti in una sala e del loro stato mediantela colorazione dell'area ad esse assegnata

RPf_4.2 Accesso a un ordineaperto collegato auna risorsa

Selezione della risorsa e gestione dell'accesso al-l'ordine aperto ad essa collegato, e la modi�cadi quest'ultimo attraverso le funzionalità messe adisposizione dal modulo software di gestione degliordini

RPf_4.3 Accesso adanagra�ca camere

Visualizzazione per mezzo di un looper delle cameredell'hotel con una prenotazione attiva


40

3.4. PROGETTAZIONE



RPf_4.3.1 Selezione dei resi-denti di una camera

Visualizzazione sotto forma di lista e selezione deiresidenti di una camera

RPf_4.4 Accesso ad ana-gra�ca passantiesterni

Visualizzazione e selezione per mezzo di un looper

dei passanti esterni aventi una prenotazione attiva

RSf_4.5 Accesso adanagra�capersonale

Visualizzazione e selezione per mezzo di un looper

delle prenotazioni eseguite per conto di membri delpersonale della struttura alberghiera

RPf_4.6 Eliminazione di unordine

Esecuzione delle operazioni necessarie all'elimi-nazione degli oggetti e dei record nel database mobilerelativi all'ordine da eliminare

RPf_4.7 Creazione di unnuovo ordine

Esecuzione delle operazioni di creazione di un nuo-vo ordine, comprendenti la costruzione dei relativioggetti e della registrazione degli appositi record

all'interno della tabella �Ordine� del database mobileROf_4.8 Divisione di un or-

dineStrumento per la divisione dell'ordine in sotto-ordiniper l'addebito su conti cliente separati

RSq_4.9 Salvataggio diemergenza dellostato degli ordini

Meccanismo di protezione dei dati per il salvataggiodello stato degli ordini, atto alla prevenzione dellaperdita di dati. Questo meccanismo viene attivatoin caso si veri�chino situazioni di emergenza (caricadella batteria insu�ciente

Tabella 3.5: Tabella dei requisiti del modulo Risorse

Gestione ordine


Requisiti della Tab Comanda

RPf_5.1.1 Selezione di un arti-colo

Navigazione dell'operatore attraverso due liste di-namiche, la prima riguardante le categorie di arti-coli, la seconda contenente gli articoli relativi allacategoria selezionata nella prima lista

RPf_5.1.2 Determinazionequantità

Selezione veloce o manuale della numero di unitàdell'articolo selezionato dovranno comparire neldettaglio d'ordine

RSf_5.1.3 Gestione delle vari-anti (Ristorante)

Funzionalità di gestione delle modi�che aggiuntiveo negative riguardanti gli ingredienti usati per lapreparazione di un articolo nel caso di un puntovendita ristorante

RPf_5.1.4 Immissione di notead un articolo

Possibilità di collegare all'articolo delle note che loriguardano


41

CAPITOLO 3. STAGE



RSf_5.1.5 Inserimento di unarticolo fuori listino

Funzionalità che permette all'operatore di inserireun articolo non presente a listino nella comanda,indicandone la descrizione, il prezzo e la quantitàdesiderata

RSq_5.1.6 Ricerca di un arti-colo

Ricerca di un articolo nel listino attraverso l'utiliz-zo di una stringa e visualizzazione e selezione deirisultati

Requisiti della Tab Conto

RSf_5.2.1 Collegare un mes-saggio a una co-manda

Funzionalità di inserimento di un messaggio in tes-ta alla comanda, utilizzato internamente al puntovendita, per comunicare situazioni particolari

RSf_5.2.2 Lista degli ultimidettagli ordine in-seriti

Visualizzazione dei dettagli d'ordine inseriti nellanuova comanda, ma non ancora scritti all'interno deldatabase mobile

RSf_5.2.3 Lista dei dettagliordine di un ordine

Visualizzazione dei dettagli d'ordine inseriti all'inter-no di un ordine, comprensivi dei dettagli della nuovacomanda, non ancora scritti all'interno del databasemobile

RPf_5.2.4 Modi�ca di un det-taglio ordine

Funzionalità di modi�ca della quantità, dell'ordinedi uscita o eliminazione di un dettaglio d'ordineselezionato dalla lista di riepilogo

RSq_5.2.5 Lista di raggruppa-mento degli articoli

Visualizzazione sotto forma di lista degli articoli pre-senti nell'ordine, comprensivi di quantità e di prezzo(la selezione non è abilitata)

RSq_5.2.6 Lista di raggruppa-mento degli cate-gorie

Visualizzazione sotto forma di lista delle categoriedegli articoli presenti nell'ordine, comprensive diquantità (la selezione non è abilitata)

Requisiti della Tab Cliente

RSq_5.3.1 Visualizzazionedelle informazionidel cliente

Popolamento di una struttura gra�ca tabulare con-tenente le informazioni organizzate relative a uncliente

RSf_5.3.2 Collegamento di uncliente all'ordinecorrente

Accesso alle funzionalità di ricerca di un cliente egestione del risultato da esse restituito

RSf_5.3.3 Ricerca e selezioneda residenti nellecamere

Ricerca di un residente attraverso l'uso di unastringa, secondo diverse modalità, visualizzazionedel risultato di ricerca (con tipo di arrangiamento ecamera di appartenenza) e selezione del nominativo

RSf_5.3.4 Ricerca e selezioneda prenotazionipassanti esterni

Ricerca di un passante esterno attraverso l'uso di unastringa, secondo diverse modalità, visualizzazione delrisultato di ricerca e selezione del nominativo

RSf_5.3.5 Ricerca e selezionedi un cliente daanagra�ca soggetti

Ricerca di un cliente attraverso l'uso di una stringa,secondo diverse modalità, visualizzazione dei clientitrovati e selezione del nominativo


42

3.4. PROGETTAZIONE



RSp_5.3.6 Ricerca in anagra�-ca soggetti veloce

La ricerca nell'anagra�ca soggetti deve essere svoltain tempi ragionevolemnte brevi, nonostante avvengasu tabelle contententi migliaia di nominativi

Requisiti Globali

RSf_5.4 Sospensione di unacomanda

Salvataggio temporaneo del riferimento di una co-manda in corso, per riprenderene l'inserimento delleordinazioni in un momento successivo

RPf_5.5 Salvataggio diuna comanda sudatabase mobile

Scrittura nel database dei dettagli ordine, attraversoquery di inserimento, di una nuova comanda

RPf_5.6 Salvataggio dellemodi�che sudatabase mobile

Gestione e registrazione su database delle modi�cheapportate ad ordinazioni già presenti nel databasemobile, attraverso l'utilizzo di query di modi�ca(Update)

Tabella 3.6: Tabella dei requisiti della gestione ordine

Agenda


ROq_6.1 Visualizzazionedegli appuntamentigiornalieri

Visualizzazione gra�ca degli appuntamenti sotto for-ma di calendario, con la rappresentazione degliappuntamenti in funziona della durata

ROf_6.2 Gestione appunta-menti

Funzionalità per la gestione degli appuntamentipresenti nel programma giornaliero

ROf_6.2.1 Modi�ca appunta-mento

Modi�ca di un appuntamento esistente all'interno delprogramma giornaliero

ROf_6.2.2 Creazione appunta-mento

Inserimento di un nuovo appuntamento all'internodel programma giornaliero

ROf_6.2.3 Eliminazioneappuntamento

Eliminazione di un appuntamento esistente dalprogramma e noti�ca

ROp_6.3 Ottimizzazione ap-puntamenti

Riorganizzazione degli appuntamenti in seguito amodi�che del programma giornaliero e noti�ca.

Tabella 3.7: Tabella dei requisiti del modulo Agenda

43

CAPITOLO 3. STAGE

3.4.4 Struttura e diagrammi delle classi

Essendo Windev Mobile 16 un ambiente di sviluppo che integra strumenti ditipo CASE, permette una netta divisione dell'applicazione secondo il pattern ar-chitetturale MVC; proprio per questo il diagramma delle classi riguarda solo lastruttura della parte Model, mentre sia la parte View che la parte Control ven-gono de�nite attraverso l'utilizzo degli speci�ci strumenti CASE forniti nell'IDEdi PCSoft.

Considerazioni e approccio iniziale

Durante la realizzazione di applicazioni di prototipo in fase di studio di fattibilitàho constatato quanto fosse dispendioso in termini di tempo l'esecuzione di querysul database mobile, soprattutto quando queste coinvolgevano tabelle contenentiun numero considerevole di record; tutto ciò provocava un tempo d'attesa taleda intaccare l'usabilità dell'applicazione.Data l'impossibilità di ottimizzare in misura rilevante le query, l'unica soluzionepossibile a questo problema non poteva essere che il caricamento nella memoriaprincipale del dispositivo, le informazioni contenute nel database sotto forma dioggetti, e le relazioni attraverso puntatori agli oggetti stessi.Per rendere questo possibile è stato necessario de�nire la struttura delle classiin maniera tale da essere del tutto simile alla struttura del database mobile,inoltre gli oggetti costruiti avrebbero dovuto contenete le stesse informazioni,usando due tecniche distinte e caratterizzate dalla natura delle informazioni:

• Nel caso delle tabelle �Consultate�(vedi sezione relativa alla progettazionedel database mobile), una volta caricati i relativi oggetti in memoria, nonci sarebbe stato bisogno di accedere nuovamente al database mobile.

• Nel caso invece delle tabelle �Modi�cabili� è stato necessario un carica-mento iniziale delle informazioni, dopo il quale è stato gestito una sorta diaggiornamento �parallelo� tra gli oggetti in RAM e le informazioni presentinelle tabelle del database mobile, posticipando l'esecuzione delle funzionidi aggiornamento del database ai momenti di inattività dell'applicazione(sempre per non in�uire sull'usabilità, essendo dispendiose in termini ditempo e risorse).

L'architettura delle classi

Come per il database, anche nell'architettura delle classi è possibile individuareelementi tali da raggruppare le classi dell'applicazione in componenti speci�cheal tipo di informazioni contenute e alle relazioni con le altre classi.Le componenti dell'architettura delle classi sono:

• La classe Hotel, che consiste nel �nucleo� dal quale si ha accesso a tuttele informazioni contenute nella parte Model e la cui costruzione è gestitanelle modalità de�nite dal pattern Singleton.

• Le classi dedicate all'organizzazione del Listino del punto vendita.

• La gerarchia delle classi per la distinzione delle tipologie di Clienti e lerelative informazioni anagra�che.

44

3.4. PROGETTAZIONE

• Le classi per la Gestione degli ordini

Nella sezione successiva tratta nel dettaglio la componente più importante traquelle precedentemente citate, ovvero la gestione degli ordini.

Le classi relative alla gestione degli ordini

Figura 3.15: Schema delle componenti informative di un ordine

Una struttura delle classi di grande importanza anche se di media complessitàè quella relativa alle classi necessarie alla gestione degli ordini.Anche in questo caso viene riportato per maggiore chiarezza uno schema a bloc-chi, riguardante l'organizzazione di un ordine e le sue informazioni identi�cativedel contesto in cui viene creato.Come si evince dallo schema ogni oggetto della classe �Ordine� per esistere deveobbligatoriamente appartenere a un contesto speci�co identi�cato attraverso irelativi puntatori ai seguenti oggetti:

• L'ordine se aperto deve essere collegato univocamente a una Risorsa.

• Deve poter essere riconducibile a un oggetto Cliente o a una sua sotto-classe.

• Il creatore dell'ordine deve poter essere noto con un puntatore a un oggettodi classe Operatore.

• L'ordine deve essere collegabile ad una Cassa, la quale è associata ad unoggetto di tipo �PuntoVendita�.

Inoltre l'ordine è composto da tre livelli di astrazione spiegati in precedenza:

1. L'oggetto Ordine descritto in precedenza.

2. Gli oggetti della classe Comanda contenuti nel vettore a loro dedicatorelativo nell'oggetto �Ordine�.

45

CAPITOLO 3. STAGE

3. I singoli oggetti della classe �DettaglioOrdine� opportunamente con-tenuti in un vettore della relativa classe �Comanda�.

Per rendere più facile l'accesso agli oggetti di livello superiore, ogni oggettodi livello inferiore possiede un riferimento all'oggetto che lo contiene (un oggettodi tipo �DettaglioOrdine� ha tra i suoi campi dati sia il puntatore all'oggetto�Comanda�, sia all'oggetto �Ordine� che contiene quest'ultima ).La complessità vera e propria sta nel mantenere aggiornate i dati di entrambele architetture, quella del database mobile con quella degli oggetti caricati inmemoria.

46

3.4. PROGETTAZIONE

Figura 3.16: Diagramma delle classi relative alla gestione delle ordinazioni

47

CAPITOLO 3. STAGE

3.5 Sviluppo

In questa sezione vengono trattate le attività da me svolte durante la fasedi sviluppo dell'applicazione WalkingPH, prestando attenzione a descrivere gliaspetti più importanti che hanno caratterizzato questa fase dello stage.

3.5.1 Operazioni preliminari

Nel proseguire del progetto verso le attività di sviluppo, come prima cosa sonostate generate le classi relative alla parte Model dell'applicazione, opportuna-mente formalizzate durante la progettazione attraverso gli strumenti UML messia disposizione da Windev Mobile.Successivamente ho provveduto nell'importazione dei dati provenienti da undatabase di Planet Hotel di prova, talvolta per mezzo dell'utilizzo dello stru-mento di conversione fornito dall'IDE, in altre occasioni attraverso delle queryprede�nite, richiamate da funzioni di popolamento appositamente scritte.

Il caricamento dei dati

Una volta popolate le più importanti tabelle del database mobile è stato nec-essario procedere nella de�nizione dei metodi interni alle classi de�niti builder,i quali invocati da un oggetto �padre�, provvedono alla creazione di tutti glioggetti ad esso collegati per mezzo dell'esecuzione di query di selezione; ciò hapermesso il caricamento in memoria principale dei dati presenti nel databasemobile per mezzo dell'invocazione a cascata di questa tipologia di metodi (in-vocati all'interno degli stessi costruttori).L'invocazione a cascata dei metodi builder comportava l'esecuzione massiccia diquery di selezione nel database mobile, occupando per circa un minuto le risorsedel dispositivo mobile; l'accesso e l'elaborazione dei dati sotto forma di oggettirisulta istantaneo, dopo il caricamento di questi in memoria principale.Questo metodo è stato un compromesso adottato in funzione dell'usabilità del-l'applicazione a fronte dell'occupazione della memoria RAM (circa il 60%) e delattesa iniziale (il caricamento dati avviene una volta e�ettuato l'accesso).Un aspetto da considerare consiste nel caricamento del listino del punto vendi-ta, per impedire l'occupazione totale della memoria principale e un tempo diattesa prolungato nella fase di caricamento, è stato deciso di caricare un sololistino per volta e che, nel caso di un cambiamento del punto vendita, il vecchiooggetto �listino� assieme agli oggetti ad esso collegati sarebbero stati distrutti,per liberare lo spazio destinato al caricamento del nuovo listino.

3.5.2 Le iterazioni del metodo RAD

Grazie alla tecnica di sviluppo RAD e con gli strumenti CASE messi a dis-posizione da Windev, la creazione delle form gra�che è risultata semplice eimmediata, ciò nonostante nell'approccio allo sviluppo di un nuovo modulo soft-ware, prima dell'inizio delle iterazioni del cosiddetto �ciclo dei prototipi�, è statonecessario compiere delle operazioni preliminari:

• Presenza e coerenza nel database mobile dei dati necessari al funziona-mento del nuovo modulo.

48

3.5. SVILUPPO

• Veri�ca del corretto funzionamento dei metodi usati per il caricamento deidati in memoria.

• Sperimentazione del funzionamento dei nuovi componenti gra�ci che dovran-no essere presenti nell'interfaccia gra�ca, soprattutto riguardo la gestionedegli eventi a questi collegati.

Una volta compiute queste veri�che sono stato in grado di proseguire nellosviluppo dei prototipi secondo quanto previsto dalla tecnica RAD, integrandonel modulo o nella form gra�ca una funzionalità aggiuntiva e veri�candone ilfunzionamento attraverso l'esecuzione iterativa delle seguenti operazioni.

1. De�nizione delle operazioni che la funzione deve eseguire e gli oggetti dacoinvolgere.

2. Scrittura del codice della funzione in WLanguage secondo quanto de�nito.

3. Inserimento della chiamata alla funzione nella posizione opportuna nelcodice della componente.

4. Compilare il progetto e correggere eventuali errori.

5. L'esecuzione della funzionalità aggiunta e veri�carne il funzionamento congli strumenti di debug.

Grazie alla creazione iterativa di prototipi il tutor aziendale poteva visionarein ogni momento dello sviluppo l'evoluzione del componente software, perciòdurante le revisioni di sviluppo si è potuto agire in modo interattivo e immediato.

3.5.3 L'interfaccia gra�ca

Figura 3.17: Form gra�che relative all'autenticazione, la schermata principale ela selezione del contesto

Lo stile usato nelle interfacce gra�che delle �nestre che compongono l'ap-plicazione mobile sono state studiate in modo da consentire all'utente un'inter-azione con l'applicazione semplice e immediata.

49

CAPITOLO 3. STAGE

L'utilizzo di e�etti gra�ci è pressoché assente, prediligendo l'usabilità all'esteti-ca; questa scelta è stata fatta in base all'esigenza di avere un'applicazione usabilee veloce, e che non sprecasse risorse in operazioni considerate inutili dal puntodi vista delle prestazioni.Durante il caricamento dei dati l'utente viene informato dello stato di avan-zamento attraverso la visualizzazione nella struttura delle classi in corso dicreazione e una barra di progresso percentuale; lo stesso vale per le situazioni incui i dati vengono salvati nel database attraverso query, durante le quali appareall'utente una �nestra di attesa con le informazioni sull'operazione in corso.Dalle immagini di esempio è possibile notare che la dimensione dei componentigra�ci interattivi, questi sono grandi e il testo al loro interno è ben leggibile;inoltre la disposizione e le funzioni collegate ai bottoni permettono una selezionerapida delle funzioni tipiche di un punto vendita, secondo i meccanismi studiatidurante l'analisi del dominio.Un altro aspetto non di poco conto da tenere in considerazione durante lacreazione delle interfacce gra�che è stato la comparsa della tastiera a scher-mo ogni qualvolta l'utente accedeva a un oggetto gra�co di tipo editbox, tastierala cui è tale da occupare la parte del settore inferiore dello schermo tattile; perquesto motivo tutte gli oggetti gra�ci per l'inserimento di testo sono stati po-sizionati nel settore superiore, in modo tale da dare modo all'utente di vedereciò che scrive.

3.5.4 Lo sviluppo del modulo per la gestione ordine

Figura 3.18: Le tre tab che compongono la gestione ordine: comanda, conto ecliente

Il più complesso modulo da realizzare è stato sicuramente il modulo softwarerelativo alla gestione ordine. Questo modulo ha comportato uno sforzo notevoledello sviluppo delle funzioni interne al modulo, in modo da mantenere in unostato coerente degli oggetti temporanei e condivisi dalle tre tab di cui è compostoil modulo, anche nel nel caso di un ritorno alla form Risorse (azione permessaall'utente in qualsiasi momento).Proprio per questo sono state create funzioni per sospendere e ripristinare lo

50

3.5. SVILUPPO

stato dell'ultima comanda inserita in un determinato ordine, inizialmente nonpreviste dalla progettazione; infatti era stato pensato che al momento di uscitadal modulo di gestione ordine, le comande non inviate al database dovesseroessere cancellate. Nelle seguenti sezioni sono a�rontate sinteticamente le due piùimportanti componenti software che formano il modulo per la gestione ordine.

Lo sviluppo della tab Comanda

Figura 3.19: Tre schermate di esempio per la tab Comanda: selezione articolo,inserimento manuale della quantità, inserimento di varianti

Lo scopo �nale della tab Comanda consiste nell'inserimento di un oggetto�DettaglioOrdine� completo e coerente all'interno della comanda corrente, aveteal suo interno il puntatore a un oggetto �ArticoloPV�, una quantità e uscita bende�nite (insieme ai riferimenti agli oggetti contenenti le informazioni relativeall'operatore e al contesto in cui l'applicazione opera).La raccolta di dati per la creazione di un dettaglio d'ordine deve avvenireattraverso un procedimento rigido descritto dallo schema sottostante

Figura 3.20: Schema delle operazioni per la creazione di un dettaglio d'ordine

Nella prima parte l'utente avrebbe selezionato un articolo dalla lista (risul-tato della selezione di una categoria oppure di una ricerca) e qualora lo avesse

51

CAPITOLO 3. STAGE

ritenuto opportuno, applicato le varianti desiderate (ad esempio nel ristorante,spaghetti allo scoglio con aggiunta di basilico, ma senza vongole), una voltadeterminato in modo univoco l'articolo sta all'utente determinarne:

• La quantità, di default impostata a una unita.

• L'inserimento facoltativo di eventuali note (selezionando tra le note pre-de�nite o inserendole manualmente).

• La sequenza di uscita (da selezionare manualmente perché senza valoreprede�nito).

Se durante la selezione di questi parametri l'utente selezionasse un articolo diver-so o una categoria dalle apposite liste, verrà chiamata una funzione che e�ettuail ritorno al valore prede�nito della quantità e delle note, la deselezione dell'usci-ta e la cancellazione delle varianti temporaneamente memorizzate; naturalmentequesta procedura viene eseguita anche dopo la creazione e l'inserimento nellacomanda dell'oggetto rappresentante il dettaglio d'ordine, in modo da impedireche i parametri precedenti in�uiscano della creazione di un nuovo dettaglio d'or-dine.Un altro aspetto degno di nota relativo a questa �nestra gra�ca consiste nel ridi-mensionamento orizzontale delle listbox, per la selezione delle categorie e degliarticoli, come si può notare dalle immagini l'espansione avviene per la lista incui viene selezionato un elemento.

Lo sviluppo della tab Conto

Figura 3.21: Tre schermate della tab conto: ultima comanda, ordine intero eriepilogo articoli di varianti

Quest'interfaccia gra�ca ha il compito di riepilogare all'operatore lo statodegli articoli inseriti, secondo 4 tipologie di visualizzazione, selezionabili con gliappositi bottoni:

• ULTIMI, visualizza i dettagli d'orine relativi alla comanda corrente.

• TUTTO, riporta tutti i dettagli presenti nell'ordine, divisi per comanda.

52

3.5. SVILUPPO

• COMP., riepiloga i dettagli d'ordine raggruppati per articolo non modi-�cati.

• RIEP., riepiloga le categorie degli articoli presenti nell'ordine.

Visualizzati come righe nella tabella, sono riportati i dettagli d'ordine e con-tengono, partendo da sinistra, informazioni relative alla quantità, il nome del-l'articolo, la sequenza di uscita e il prezzo unitario.Tra questi riepiloghi sotto forma di tabella solo nei primi due casi è attivatala selezione del dettaglio d'ordine, essendo possibile apportare modi�che dellaquantità e dell'ordine di uscita, o deciderne l'eliminazione (è consentita anchel'eliminazione delle note e delle varianti relative al singolo dettaglio).Durante la modi�ca dei dettagli d'ordine già presenti nel database mobile avvienela memorizzazione dei puntatori agli oggetti coinvolti nella modi�ca per mez-zo di una lista, a�nché possano essere modi�cati anche i rispettivi record neldatabase al momento del ritorno alla �nestra delle �Risorse� e accorpata all'even-tuale inserimento nella base dati della nuova comanda (operazione posticipataperché possibilmente dispendiosa in termini di tempo).

3.5.5 Funzionalità di salvataggio di emergenza

Un'altra importante funzionalità inizialmente non prevista in fase di proget-tazione, ma implementata in fase di sviluppo è stata la funzionalità di salvatag-gio di emergenza collegata al modulo software Risorse dell'applicazione Walk-ingPH.L'idea iniziale di questa funzionalità è sorta in seguito alla possibilità di sospen-sione e ripristino dello stato di una comanda; l'eventualità di avere una comandasospesa in concomitanza con una situazione imprevista o inevitabile, avrebbeportato a un'irrimediabile perdita di dati (ad esempio un errore di sistema ol'imminente spegnimento del dispositivo causato da una carica insu�ciente al-l'interno della batteria).Per evitare tutto ciò è stata creata una funzione che al momento dell'invocazioneprecede con una scansione degli ordini aperti e quando rileva una comandasospesa ne scrive i relativi dettagli d'ordine nel database mobile, marcandolicon apposito un �ag che li identi�ca come sospesi.Al momento del ripristino dello stato di esecuzione dell'applicazione i dettaglid'ordine sospesi verranno ripristinati e successivamente cancellati dal database.L'invocazione di tale funzione è a�data alla gestione delle eccezioni ed errori diWindev, e ad un thread, interno alla form Risorse, che periodicamente richiamauna funzione di sistema per la valutazione del livello di batteria del dispositivo.

3.5.6 Di�coltà riscontrate

Durante lo sviluppo non sono state riscontrate di�coltà insormontabili propriograzie al minuzioso lavoro svolto nelle fasi di studio di fattibilità e di proget-tazione.Il fatto di usare Windev Mobile con l'ottica di trovare possibili complicazioni(descritte nel paragrafo �problemi riscontrati�) mi ha fatto ragionare ponendoattenzione alle possibili soluzioni alternative, discutendole con il tutor aziendale.Un altro aspetto che mi ha creato qualche di�coltà sta nel fatto che l'approccio

53

CAPITOLO 3. STAGE

a un IDE, per me nuovo, come autodidatta e senza personale esperto in azien-da a cui sottoporre eventuali problemi, non è stato dei migliori, e l'inadeguatadocumentazione relativa all'ambiente di sviluppo fornita da PCSoft, non ha dicerto aiutato.Se al momento dell'inizio dello sviluppo avessi avuto le conoscenze sinora ac-quisite, avrei sicuramente potuto procedere in maniera più rapida ed e�cientenella realizzazione dell'applicazione.Ciò nonostante posso dirmi soddisfatto del risultato ottenuto nello svolgimentodi quest'ultima fase del progetto.

54

Capitolo 4Valutazione retrospettiva

In questo quarto e ultimo capitolo sono state riportate le valutazioni e le con-siderazioni, successive alla conclusione dell'attività di stage, in merito al com-pletamento degli obiettivi pre�ssati e dal punto di vista della crescita personalee professionale maturata da questa esperienza.

4.1 Soddisfacimento dei requisiti

Come già spiegato nella sezione riguardante lo studio di fattibilità, durante losvolgimento delle attività lavorative, c'è stato un ridimensionamento degli obi-ettivi del progetto di stage; alla luce della complessità e importanza dell'aspettodi sincronizzazione tra database attraverso un'applicazione �ponte�, la quale,secondo le valutazioni mie e del tutor aziendale, avrebbe richiesto uno sforzotale da poter essere considerato come unico obiettivo di progetto per un ulteri-ore stage.Il progetto di stage si è quindi trasformato nella realizzazione dell'applicazionemobile WalkingPH integrante la gestione delle vendite, e predisposta sia allasincronizzazione che alla successiva integrazione con un modulo CRM relativoalla gestione dell'agenda.Il processo di sviluppo è stato quindi dedicato al completamento della gestionedelle vendite integrata, prediligendo la qualità ed e�cienza del software realiz-zato più che ad un avanzamento forzato nello sviluppo di ulteriori moduli CRM.Questo approccio è risultato vincente dal punto di vista del soddisfacimento deirequisiti decretati come primari, poiché essendomi stato permesso di focaliz-zare la mia attenzione su quelli, ho potuto procedere nello sviluppo in manierametodica, tale da poter adempiere al raggiungimento dei requisiti secondari equalitativi in tempi contenuti.Qui di seguito è riportata una tabella contenente i requisiti dichiarati in fase diprogettazione e il loro stato di avanzamento percentuale.

55

CAPITOLO 4. VALUTAZIONE RETROSPETTIVA

4.1.1 Avanzamento nei requisiti

Codice Nome Avanzamento

Autenticazione

RPf_1.1 Autenticazione operatore 100%RSf_1.2 Autenticazione amministratore 100%RPf_1.3 Identi�cazione tipologia operatore 100%

Schermata principale

RPf_2.1 Selezione contesto 100%RPf_2.1.1 Selezione punto vendita 100%RPf_2.1.2 Selezione sala 100%RSq_2.1.3 Selezione in memoria 100%RPf_2.2 Caricamento contesto 100%RPf_2.3 Chisura sessione 100%RPq_2.4 Visualizzazione dello stato 100%RPf_2.5 Accesso a Risorse 100%RSf_2.6 Accesso ad Agenda 0%

Utilities

RSf_3.1 Gestione dispositivi di stampa 30%RSf_3.2 Test di connessione 20%RSf_3.3 Avvio sincronizzazione 0%RSq_3.4 Impostazioni dell'applicazione 100%

Risorse

RPq_4.1 Visualizzazione dello stato delle risorse 80%RPf_4.2 Accesso a un ordine aperto collegato a una risorsa 100%RPf_4.3 Accesso ad anagra�ca camere 100%RPf_4.3.1 Selezione dei residenti di una camera 100%RPf_4.4 Accesso ad anagra�ca passanti esterni 100%RSf_4.5 Accesso ad anagra�ca personale 100%RPf_4.6 Eliminazione di un ordine 100%RPf_4.7 Creazione di un nuovo ordine 100%ROf_4.8 Divisione di un ordine 20%RSq_4.9 Salvataggio di emergenza dello stato degli ordini 100%

Gestione ordine

Requisiti della Tab Comanda

RPf_5.1.1 Selezione di un articolo 100%RPf_5.1.2 Determinazione quantità 100%RSf_5.1.3 Gestione delle varianti (Ristorante) 100%RPf_5.1.4 Immissione di note ad un articolo 100%RSf_5.1.5 Inserimento di un articolo fuori listino 70%RSq_5.1.6 Ricerca di un articolo 100%

Requisiti della Tab Conto

RSf_5.2.1 Collegare un messaggio a una comanda 100%RSf_5.2.2 Lista degli ultimi dettagli ordine inseriti 100%RSf_5.2.3 Lista dei dettagli ordine di un ordine 100%


56

4.1. SODDISFACIMENTO DEI REQUISITI



RPf_5.2.4 Modi�ca di un dettaglio ordine 100%RSq_5.2.5 Lista di raggruppamento degli articoli 100%RSq_5.2.6 Lista di raggruppamento degli categorie 100%

Requisiti della Tab Cliente

RSq_5.3.1 Visualizzazione delle informazioni del cliente 100%RSf_5.3.2 Collegamento di un cliente all'ordine corrente 100%RSf_5.3.3 Ricerca e selezione da residenti nelle camere 100%RSf_5.3.4 Ricerca e selezione da prenotazioni passanti esterni 100%RSf_5.3.5 Ricerca e selezione di un cliente da anagra�ca soggetti 100%RSp_5.3.6 Ricerca in anagra�ca soggetti veloce 90%

Requisiti Globali

RSf_5.4 Sospensione di una comanda 100%RPf_5.5 Salvataggio di una comanda su database mobile 100%RPf_5.6 Salvataggio delle modi�che su database mobile 100%

Agenda

ROq_6.1 Visualizzazione degli appuntamenti giornalieri 0%ROf_6.2 Gestione appuntamenti 0%ROf_6.2.1 Modi�ca appuntamento 0%ROf_6.2.2 Creazione appuntamento 0%ROf_6.2.3 Eliminazione appuntamento 0%ROp_6.3 Ottimizzazione appuntamenti 0%

Tabella 4.1: Tabella dell'avanzamento nei requisiti dell'appli-cazione

Come risulta chiaro dalla tabella relativa all'avanzamento nei requisiti, du-rante lo sviluppo mi è stato possibile raggiungere nella quasi totalità i requisiticonsiderati primari, eccezione fatta per il visualizzazione delle risorse tuttoraincompleta nell'implementazione di alcune caratteristiche.Per quanto riguarda il raggiungimento dei requisiti secondari c'è da registrare ilmancato completamento delle funzionalità di controllo dei dispositivi di stam-pa e della connessione con la rete aziendale nel modulo �Utilities�; mentre perquanto concerne il modulo per la gestione ordine la funzionalità di inserimentoin comanda di un articolo fuori listino sono state riscontrate alcune di�coltànella logica di associazione del nuovo articolo a una destinazione di stampa.Purtroppo il tempo concesso dallo stage non è stato su�ciente per la realiz-zazione del modulo software della gestione dell'agenda e dei requisiti a questocollegati, che in previsione di ciò erano già stati considerati come opzionali.

57


4.2 Divario conoscitivo

Le conoscenze in mio possesso acquisite durante il corso di laurea triennale sonostate adeguate, se non indispensabili, allo svolgimento dell'attività di stage. Lenozioni acquisite durante il corso e il progetto di ingegneria del software sonostate fondamentali nella fase di studio di fattibilità, ma ancora di più nell'attiv-ità di progettazione; senza tali nozioni non avrei sicuramente saputo procederenella progettazione in maniera così metodica.Un altro aspetto fondamentale per questa tipologia di applicazione è stato lostudio degli algoritmi da utilizzare per ottenere un risultato sperato nella migliore�cienza possibile, e tutto questo grazie alle conoscenze acquisite nel corso dialgoritmi e strutture dati; il calcolo della complessità e il confronto tra algoritmiè divenuto molto utile nelle scelte di sviluppo.Altre conoscenze di grande importanza già in mio possesso ma in parte insu�ci-enti sono state quelle acquisite durante il corso di basi dati e sistemi informativi;Lo studio della struttura di un database e l'utilizzo del linguaggio SQL durantetale corso di laurea mi è stato di grande aiuto nella comprensione e interazionecol database di Planet Hotel.Purtroppo sono sorte alcune di�coltà a causa della mancanza di alcune nozionisull'ottimizzazione delle query, dato che nello sviluppo di applicazioni gestionaliè consueto un utilizzo intensivo delle basi dati e dell'enorme mole di dati chequeste contengono, soprattutto in ambito CRM nel quale l'applicazione è orien-tata all'acquisizione della maggior quantità di informazioni possibile riguardantiil cliente; tale problema viene ampli�cato se l'applicazione atta a eseguire taliquery risulta essere un'applicazione per dispositivi mobile, aventi una potenzadi calcolo limitata.

58

4.3. CONOSCENZE ED ESPERIENZE ACQUISITE

4.3 Conoscenze ed esperienze acquisite

Durante l'attività di stage mi sono ritrovato a operare con strumenti di ma-nipolazione di database sino ad allora per me sconosciuti e di tecnologie di cuiin precedenza avevo sentito solo parlare, come ODBC e la sincronizzazione tradatabase.Dello standard ODBC è stato fatto ampio uso nella fase di studio del databasedi Planet Hotel, ed ho imparato a riconoscerne le proprietà e i limiti attraversola connessione con altre applicazioni.Sempre durante la fase di analisi del dominio ho avuto occasione di studiare ecomprendere la struttura e i meccanismi propri di un'applicazione gestionale, inparticolare della struttura di un database che la sopporta.Attraverso lo studio delle tecnologie di sincronizzazione mi sono reso conto deimeccanismi e delle problematiche relative a tali tecnologie, e soprattutto la dif-ferenza tra le soluzioni proposte dalle dai DBMS di case produttrici di�erenti;purtroppo l'apprendimento di queste tecniche non è stato completo anche acausa della vastità e della complessità di questo argomento in rapporto al tem-po a disposizione.Dallo studio e utilizzo di applicazioni gestionali ho appresso soprattutto l'aspet-to dell'interazione con l'utente in situazioni reali; grazie all'esperienza che iltutor aziendale ha maturato nel corso di anni dedicati alla creazione di questatipologia di applicazioni, ho imparato a ragionare da punto di vista dell'utente�nale del prodotto, ponendomi nell'ottica di realizzare un'applicazione di sem-plice utilizzo e che potesse soddisfare le esigenze di un addetto ad un puntovendita.Grazie alla scelta di Windev Mobile 16 come ambiente di sviluppo integrato, hoappreso la tecnica di sviluppo RAD supportata dall'utilizzo di strumenti CASEla quale si è rivelata fondamentale nella realizzazione dell'applicazione, anchese inizialmente vista con scetticismo poiché di�orme dalle tecniche di program-mazione da me già sperimentate; testimoni di ciò sono i risultati che ho ottenutoin termini di soddisfacimento dei requisiti, di�cilmente raggiungibili attraversola programmazione tradizionale in tempi così brevi.

59


4.4 Considerazioni personali

Al termine dell'attività di stage presso Sintesi SAS ho potuto fare il punto dellasituazione per quanto riguarda il contributo fornitomi da questa esperienza allamia crescita professionale e personale.Riguardo all'aspetto personale ho maturato nel rapporto con il tutor azien-dale e coi colleghi, spesso potevano esserci incomprensioni relative ad alcunimeccanismi o alla poco chiara de�nizione di alcune funzionalità, ma attraver-so un atteggiamento umile e paziente da entrambe le parti, è stato possibile ilmantenimento dello stato di armonia all'interno dell'azienda. Sotto l'aspettoprofessionale ho imparato a mettere da parte le mie scelte di sviluppo dettateda iniziative personali e, qualora potessero portare ad una maggiore e�cienzao usabilità, sottoponendole e discutendole con il tutor aziendale, di modo darendere l'applicazione WalkingPH conforme alle aspettative e allo stile azien-dale de�nito con Planet Hotel. Il fatto di essere stato il solo ad aver seguito larealizzazione dell'applicazione WalkingPH, in tutte le sue fasi, mi ha permessodi valutare le mie capacità e mancanze nell'a�rontare il progetto, oltre al fattodi rendermi responsabile di un prodotto che sapevo essere soggetto a valutazioneda parte del tutor aziendale, nonché il titolare dell'azienda.Dopo quanto ho appreso e realizzato durante questa esperienza lavorativa, pos-so ritenermi soddisfatto di come si è svolto lo stage aziendale e sarei pronto aripetere questo tipo di esperienza professionale se me ne capitasse l'occasione.

60

Appendice AWindev

Windev è un ambiente di sviluppo integrato (IDE) appartenente alla softwarehouse francese PCSoft, la cui prima versione risale al 1993; tale ambiente disviluppo esegue esclusivamente su macchine aventi come sistema operativo Mi-crosoft Windows, nonostante sia possibile il deployment delle applicazioni anchesu Linux.

Al giorno d'oggi l'ultima versione rilasciata dalla casa produttrice è la 16,messa in commercio a partire da Marzo 2011. Lo scopo dei prodotti Windevè il poter fornire all'utente uno strumento potente e completo per facilitarelo sviluppo di applicazioni gestionali attraverso l'utilizzo di strumenti CASEintegrati, infatti il moto di Windev è �Develop ten times faster�.La linea Windev consiste in tre prodotti, di�erenziati dalla destinazione delleapplicazioni sviluppate:

• Windev che consente lo sviluppo di applicazioni destinate a elaboratoridi tipo desktop, o i più recenti dispositivi tablet, aventi come sistema op-erativo Microsoft Windows oppure una distribuzione di Linux, è previstain alternativa la possibilità di creare applicazioni Java eseguibili da unaJVM

• Webdev consente la creazione di siti e applicazioni web secondo gli stan-dard de�niti dalla W3C attraverso l'utilizzo di tecnologie come HTML,CSS, JavaScript e XML, comprese le techiche AJAX per l'interattivitàdelle applicazioni nelle pagine web.

• Windev Mobile è un ambiente di sviluppo integrato per la realizzazionedi applicazioni destinate a dispositivi mobile come PocketPC o smart-phone.

A.1 Le caratteristiche

Le caratteristiche in comune ai tre IDE della linea Windev, che rendono iquesti prodotti validi nella realizzazione di applicazioni gestionali possono essereriassunti nei seguenti paragra� tematici.

61

APPENDICE A. WINDEV

A.1.1 Il DBMS proprietario e l'accesso a database esterni

L'utilizzo di un DBMS di ultima generazione proprietario denominato HyperFileSQL (abbreviato è HFSQL ) ed è disponibile in quattro varianti, a seconda delleesigenze dell'utente:

• HFSQL Classic da utilizzare per applicazioni dedicate a dispositivi PCdesktop o a tablet.

• HFSQL C/S che sta per client e server per applicazioni che utilizzano larete per lo scambio di informazioni.

• HFSQL Cluster, ovvero un database HyperFile SQL con struttura comune,ma i cui dati sono distribuiti in di�erenti aree geogra�che.

• HFSQLMobile per applicazioni realizzate conWindev Mobile, un databaseleggero adatto ai dispositivi moble anche non recenti.

Tutte tre le versioni permettono di accedere a database esterni, rendendoquindi i prodotti della linea Windev estremamente versatili nella realizzazionedi applicazioni nell'ambito gestionale; le modalità di accesso a database esterniche mettono a disposizione i tre IDE sono i seguenti:

• E�ettuando una connessione al database tramite l'utilizzo dei driver ODBCspeci�ci al DBMS desiderato.

• Tramite l'utilizzo delle API fornite dallo standard Microsoft OLEDB, viaconnessione ODBC, in maniera pratica e senza dover installare ulterioresoftware che non siano i driver ODBC del DBMS in oggetto.

• Utilizzano lo strumento di conversione del database dal quale si accede viaconnessione ODBC, in un database di tipo HFSQL (da non considerarsicome un accesso a un database esterno ma una vera e propria conversione,molto utile se si vuole fare l'importazione dei record da un altro databasemantenendone la struttura).

• L'ultima e meno economica modalità consiste nell'acquisto di una licenzadi un modulo software aggiuntivo da PCSoft riguardante l'accesso nativoal DBMS desiderato (opzione dispendiosa in quanto ogni licenza costaquasi quanto un singolo IDE della linea Windev).

A.1.2 Il WLanguage

I prodotti per lo sviluppo Windev utilizzano di un linguaggio di programmazionedi quarta generazione (4GL) chiamato WLanguage, per la de�nizione delle clas-si dell'applicazione e nella codi�ca delle funzioni connesse a un evento generatoda un componente gra�co.Tale linguaggio di programmazione permette la chiamata di funzioni anche com-plesse, come l'avvio di un componente software aggiuntivo (il manager di connes-sioni a reti wireless) tramite una sintassi semplice ed essenziale. Il WLanguagepermette inoltre la connessione e manipolazione di un database (attraverso lemodalità di accesso precedentemente descritti) e l'esecuzione di query de�nitein precedenza o tramite l'immissione di codice SQL �grezzo�.

62

A.1. LE CARATTERISTICHE

A.1.3 Gli strumenti integrati

Ulteriori caratteristiche degli ambienti di sviluppo della linea Windev sono lapresenza di strumenti integrati ed editor gra�ci di tipo CASE che hanno lo scopodi facilitare e aiutare l'utente durante lo sviluppo di applicazioni software. Glistrumenti più importanti forniti dagli IDE sono i seguenti:

• L'integrazione al loro interno degli strumenti necessari per la progettazionedel software, dai diagrammi UML al deployment.

• Lo strumento di conversione di progetto dà all'utente la possibilità disviluppare l'applicazione con tanto di database annesso per una delle treversioni disponibili e importarne tutte le funzionalità in un'altro IDE.

• Uno strumento che mette in grado l'utente di consultare il contenuto e lastruttura dell'intero database utilizzato nello sviluppo dell'applicazione,attraverso un ambiente gra�co integrato chiamato Analysis.

• Un editor gra�co per la creazione e il test di query, anche di notevolecomplessità.

• La presenza di un generatore di report integrato del sistema, che perme-tte di organizzare le informazioni da visulizzare in una struttura di tipodrill-down.

• Gli strumenti di debug e di riepilogo di esecuzione chiamato Audit, per-mettono di tenere sotto controllo lo stato delle variabili (anche nel casodi oggetti) durante l'esecuzione dell'applicazione; inoltre, grazie ad Au-

dit, è possibile visualizzare informazioni aggiuntive e suggerimenti perl'ottimizzazione dell'applicazione.

• La presenza della modalità di sviluppo di tipo RAD, la quale crea auto-maticamente moduli software, comprensivi di interfaccia gra�ca, generatipartendo dalla struttura di una o più tabelle di un database presente nellasezione Analysis del progetto.

63

APPENDICE A. WINDEV

64

Appendice BGlossario

0-9

4GL Acronimo di fourth-generation programming language che signi�ca lin-guaggi di programmazione di quarta generazione. Questa categoria dilinguaggi di programmazione consentono la manipolazione di oggetti odatabase relazionali attraverso una sintassi semplice ma inadatti alla de-scrizione di algoritmi di tipo procedurale.

A

AJAX Conosciuto come acronimo per asynchronous JavaScript and XML èun insieme di tecniche di sviluppo di applicazioni web lato interattiveche sfruttano l'oggetto XMLHttpRequest per lo scambio di dati (asin-crono) tra client e server senza dover e�ettuare il refresh della pagina. Icomponenti utilizzati per lo sviluppo di un'applicazione attraverso la tec-nica AJAX, possono essere scritti nei seguenti linguaggi: HTML, DOM,JavaScript e XML

Android è un insieme di componenti software, tra cui un sistema operativobasato su kernel, dedicato a dispositivi mobile come tablet o smartphone

API l'acronimo sta per Application Programming Interface ovvero l'insieme difunzioni fornite al programmatore allo scopo di generare una sorta di as-trazione rispetto al programma o al sistema a cui appartengono. Attraver-so queste funzioni il programmatore può dunque far eseguire operazioniad un sistema senza conoscerne la struttura interna, né i meccanismi difunzionamento.

65

APPENDICE B. GLOSSARIO

B

Booking Nel settore alberghiero il booking (sta appunto per prenotazione) èl'insieme di strumenti che permettono al cliente di prenotare una risorsaappartenente a una struttura alberghiera, sia essa una camera, una salaconvegni o un tavolo nel reparto ristorazione.

Bug Termine gergale informatico usato per indicare un errore logico nella scrit-tura di codice software, i bug vengono classi�cati a seconda della lorogravità, quindi sull'impatto che hanno nell'applicazione.

C

CASE Con strumenti CASE (Computer-aided software engineering) si inten-dono gli strumenti che supportano lo sviluppo del software attraverso in-terfacce gra�che e librerie di funzionalità e consentono uno sviluppo delsoftware in modo assistito. Tali sistemi hanno notevolmente sempli�catola scrittura di linee di codice con relativi bene�ci anche alla conformitàagli standard del software stesso.

Comanda Una comanda è un entità che compone un ordine, la quale raggruppagli articoli e la loro quantità (dettagli d'ordine) che un cliente richiede adun addetto alla vendita o cameriere. La comanda nasce con l'inserimentodel primo articolo e viene chiusa al momento in cui il cliente congedal'addetto alla vendita.

CRM la sigla sta per Customer relationship management, ed è un concetto co-mune nelle aziende turistiche. Il CRM è l'insieme di operazioni orientate aottenere la �ducia della clientela, cercando di creare un ambiente familiaree gradevole. Questo approccio ha lo scopo di attirare nuova clientela masoprattutto mantenere saldi i rapporti con i clienti storici oppure impor-tanti. Un esempio di operazioni facenti parte del CRM di un albergo sonol'invio al cliente di o�erte che lo possano interessare tramite newsletter

oppure degli auguri durante le festività.

CSS Il CSS (l'acronimo sta per Cascading Style Sheets ) è un linguaggio uti-lizzato per la de�nizione dello stile per la visualizzazione di una paginaHTML. Anche questo linguaggio come l'HTML è costituito da tag ed èstato standardizzato dall'ente W3C; la nascita è dovuta alla necessità diseparare i contenuti (presenti nel �le HTML) dallo stile di visualizzazionee formattazione del documento ( descritta nel �le CSS).

D

DBMS Un Database Management System è un sistema software che consentela creazione e la manipolazione di tabelle e record di un database in modo

66

e�ciente da parte di uno o più utenti anche contemporaneamente. Es-istono in commercio molti tipi di DBMS, divisi a seconda della tipologia didatabase da questi gestito, e possono essere RDBMS (Relational DBMS ),ODBMS (Object DBMS ), DBMS navigazionali e DBMS multidimensionali(ad esempo Oracle e Sybase)

Debug Tipo di strumenti che permettono agli sviluppatori di compiere con-trolli su porzioni di codice, durante l'esecuzione di un programma, attea debellare errori di programmazione. Uno strumento di debug inoltrepuò visualizzare lo stato, e quindi il contenuto, delle variabili coinvoltenell'esecuzione di un programma.

Deployment operazioni per la adattamento di un software al funzionamento suun sistema operativo o dispositivo che ne richieda la relativa installazionee messa in funzione.

Drill-down Tecnica informatica usata per condurre analisi su strutture datimulti-dimensionali; tale tecnica, appartenente all'ambito del data mining,permettono l'accesso ai dati a diversi livelli di gerarchia.

F

Form gra�che Con questo termine si intende un raggruppamento di oggettigra�ci, disposti ordinatamente all'interno di un'interfaccia gra�ca fornitada una applicazione.

H

HTML L'acronimo sta per HyperText Markup Language, è il linguaggio dimarkup la cui sintassi è de�nita dallo standard World Wide Web Consor-

tium (W3C) e viene utilizzato per la creazione di pagine web. Caratteristi-ca principale del linguaggio è l'utilizzo di tag per de�nire le caratteristichedegli elementi da visualizzare.

HFSQL L'acronimo signi�ca HyperFile SQL ed è un DBMS proprietario uti-lizzato dai prodotti della linea Windev (argomento approfondito del para-grafo relativo a Windev).

I

IDE Tradotto in italiano è l'acronimo che identi�ca un ambiente di sviluppointegrato, che permette ai programmatori di avere tutti gli strumenti nec-essari alla creazione di software in un unica applicazione. Infatti gli stru-menti presenti in un IDE sono: un editor per la scrittura del codice, unsistema di controllo di versione, un interprete o compilatore e gli strumentiper e�ettuare il debug.

67


J

Java Java è un linguaggio di programmazione multipiattaforma orientato aglioggetti, nato nel 1992. Java è un marchio registrato di Oracle.

JavaScript è un linguaggio di scripting orientato agli oggetti standardizzatonel 1996 e avente la sintassi simile a quella del linguaggio Java (Sun Mi-crosystems). Questo linguaggio composto da script è spesso utilizzato perla scrittura di applicazioni Web.

JVM Acronimo che sta per Java Virtual Machine ed è lo strumento appar-tentente alla piattaforma Java, che permette l'esecuzione del bytecode(prodotto dalla compilazione di codice sorgente scritto nel linguaggio Java)

M

MVC IL Model View Controller è un pattern architetturale molto di�uso nellosviluppo di interfacce gra�che di sistemi software object-oriented. talepattern è basato sulla divisione del software in componenti che coincidonocon:

• Il model fornisce i metodi per accedere ai dati utili all'applicazione.

• Il view visualizza i dati contenuti nel model e si occupa dell'inter-azione con l'utente.

• Il controller riceve i comandi dell'utente ( attraverso il view) e li attuamodi�cando lo stato del model e della view.

O

ODBC L'acronimo sta per Open Database Connectivity ed è uno standarddi interfacce software per l'accesso a un DBMS, indipendentemente daltipo di DBMS, dal sistema operativo o dal linguaggio di programmazioneutilizzato. L'accesso al DBMS tramite ODBC avviene attraverso un driverspeci�co a seconda del tipo di DBMS al quale ci si vuole connettere.

OLEDB L'Object Linking and Embedding, Database é un API prodotta da Mi-crosoft che permette l'accesso a risorse eterogenee secondo un approcciounico, implementato da interfacce standard. Disegnata allo scopo di sosti-tuire ad alto livello l'ODBC, mettendo a disposizione un più vasto insiemedi funzioni atte a gestire non solo basi di dati relazionali ma anche nonrelazionali e orientate agli oggetti.

Open source Con open source si intende un software sviluppato da program-matori indipendenti e il cui codice circola liberamente.

68

P

PMS L'acronimo sta per l'espressione anglosassone Property Management Sys-

tem, con la quale si intende un software per la gestione di strutturenell'ambito alberghiero o turistico.

PocketPC Nome con cui Microsoft identi�ca la propria linea di computer pal-mari, i PocketPC sono dispositivi dotati di schermo tattile e integrano unsistema operativo Windows CE o Mobile; spesso integrano al loro internofunzioni di telefonia cellulare con supporto UMTS e GSM.

R

RAD Acronimo di Rapid Application development, che è una metodologia disviluppo di software che permette la generazione rapida di codice partendodalla creazione e ride�nizione iterativa di prototipi.

Record Nell'ambito dei database, un record è un entità, identi�cata da unachiave univoca, che raggruppa delle informazioni presenti all'interno diuna tabella di un database, visualizzabili sotto forma di riga.

Report Nell'ambito dei sistemi informativi, un report informativo consiste inun documento riassuntivo contenente informazioni in forma tabellare oschematizzata.

S

SQL SQL è l'acronimo di Structured Query Language ed è un linguaggio diinterrogazione di database basati sul modello relazionale, progettato perconsentire all'utente:

• La lettura, la modi�ca e la gestione dei dati memorizzati.

• La creazione e modi�ca della struttura di database.

• La creazione e gestione dell'accesso ai dati e degli strumenti di con-trollo.

Shell La shell è la �nestra di comando nella quale si immettono operazioni informa scritta da far eseguire al sistema operativo. In Windows si attivaattraverso l'esecuzione del comando cmd, mentre su Linux viene chiamataterminal.

Singleton Il singleton è in un pattern creazionale, descritto dalla �Gang of

four�, che coinvolge una classe che permette l'istanziazione di un solooggetto del proprio tipo durante l'esecuzione di un'applicazione. Ogniqualvolta si tenti di istanziare un nuovo oggetto appartenente alla classeSingleton, e fosse già presente un oggetto istanziato della medesima classe,viene impedita la creazione del nuovo oggetto e viene passato il riferimentoall'oggetto relativo alla prima istanza.

69


Smartphone Dispositivo mobile che integra le funzioni di telefonia cellularead un sistema operativo grazie al quale è possibile gestire l'installazionedi applicazioni aggiuntive.

Struttura ricettiva Una struttura, nell'ambiente turistico, viene de�nita ricetti-va qualora assuma lo scopo di accogliere la clientela all'interno dello sta-bilimento; essa non solo è caratterizzata dal luogo adibito a tale funzione,ma soprattutto dalle operazioni svolte dagli addetti al servizio ricettivo.Ad esempio una struttura ricettiva può essere individuata nella hall di unhotel con il personale di servizio addetto ai bagagli e alla segreteria.

T

Template Un template è un modello de�nito a priori per realizzare successi-vamente elementi simili, coerenti con la forma prede�nita .

Trigger Procedura SQL nella quale vengono speci�cate le operazioni automa-tizzate da eseguire al veri�carsi di un evento una certa tabella del database.

Thread Processo eseguito in maniera concorrente ad altri processi, nella stessoelaboratore.

U

UML L'Uni�ed Modeling Language è un linguaggio per la modellazione e per laspeci�ca de�nito nel 1996 dai �tre amigos� (Ivar Jacobson, Grady Booche Jim Rumbaugh) allo scopo di uni�care i modelli di rappresentazionedei sistemi precedentemente esistenti in ingegneria del software. Questolinguaggio è costituito da una semantica precisa e utilizza viste e diagram-mi correlati , tra cui i diagrammi use-case, delle classe, degli oggetti, disequenza e delle attività.

Use case Gli Use Case Diagram sono diagrammi �nalizzati alla rappresen-tazione delle funzioni presenti in un sistema, descritte dal punto di vistadell'interazione di un utente (de�nito actor) col sistema stesso. Questidiagrammi vengono spesso impiegati come strumento per rappresentare irequisiti funzionali di un sistema (le Use Case View).

V

Visual studio Ambiente di sviluppo integrato (IDE) prodotto da Microsoft,orientato alla realizzazione di applicazioni, web application e web servicesanche attraverso la tecnica RAD. Supporta diversi tipi di linguaggio tracui C, C++, C#, .Net, ASP .Net e Visual Basic

70

W

W3C la sigla identi�ca l'associazione World Wide Web Consortium, fondatanel 1994 da Tim Berners Lee in collaborazione con il CERN di Ginevra e ilMIT (Massachusetts Institute of Technology); tale associazione ha lo scopodi standardizzare e migliorare i linguaggi e i protocolli per l'evoluzione delWeb.

Windows Mobile Sistema operativo dedicato di Microsoft dedicato ai dispos-itivi mobile del tipo PocketPC

WLanguage Linguaggio di programmazione proprietario di quarta generazionedei prodotti della linea Windev dell'azienda francese PCSoft.

X

XML Siglia di eXtensible Markup Language ovvero linguaggio marcatore cheestende altri linguaggi di tipo marcatore. L'XML è utilizzato spesso comelinguaggio per il trasferimento di dati tra tipi di DBMS diversi, è utiliz-zato anche per creare nuovi linguaggi che hanno lo scopo di descrivere lastruttura di documenti.

71


72

Bibliogra�a

• Sito internet di wikipedia, rielaborazione dei termini per il glossariohttp://en.wikipedia.org

• Sito del dizionario informatico, rielaborazione dei termini per il glossariohttp://www.dizionarioinformatico.com

• Sito internet di Planet Hotel, storia di Sintesi e Planet Hotelhttp://www.planethotel.biz

• Sito internet di Sybase, funzionalità di SQL anywhere 8.0http://www.sybase.com

• Sito internet inglese per Windevhttp://www.windev.com

• Dispense di ingegneria del software del Professor Tullio Vardanegahttp://www.math.unipd.it/~tullio/IS-1/2010/

• Guide to the Software Engineering Body of Knowledge (SWEBOK)http://www.computer.org/portal/web/swebok/htmlformat

73


74

Elenco delle �gure

1.1 Copertina depiant di Planet Hotel . . . . . . . . . . . . . . . . . 31.2 Form di prenotazione presente nel modulo Front Desk . . . . . . 41.3 Gra�co predittivo generato da una funzione del modulo Back O�ce 51.4 Tableau a colori per la gestione dell'occupazione tavoli nel modulo

Ristorante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.5 Logo di Sybase . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1 Ciclo di sviluppo incrementale secondo lo standard ISO 12207 . . 153.2 Diagramma di Gantt riguardante il piano di lavoro . . . . . . . . 173.3 Diagramma temporale delle ordinazioni in un ristorante . . . . . 213.4 Diagramma temporale delle prestazioni erogate in un wellness

center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.5 Diagramma temporale della spesa in un minimarket . . . . . . . 233.6 Schema di sincronizzazione della tecnologia Mobilink . . . . . . . 243.7 Struttura di un database Ultralite accessibile da un applicazione

Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.8 Struttura dell'applicazione �ponte� . . . . . . . . . . . . . . . . . 273.9 Schema del funzionamento della tecnica Universal Replication di

Windev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.10 Confronto tra il metodo di sviluppo RAD ed il metodo tradizionale 303.11 Tabelle relative ai agli articoli e ai listini dei punti vendita . . . . 343.12 Diagramma delle relazioni tra i moduli software di WalkingPH . 353.13 Diagramma dei casi d'uso della tab �Comanda� . . . . . . . . . . 363.14 Diagramma dei casi d'uso della tab �Conto� . . . . . . . . . . . . 373.15 Schema delle componenti informative di un ordine . . . . . . . . 453.16 Diagramma delle classi relative alla gestione delle ordinazioni . . 473.17 Form gra�che relative all'autenticazione, la schermata principale

e la selezione del contesto . . . . . . . . . . . . . . . . . . . . . . 493.18 Le tre tab che compongono la gestione ordine: comanda, conto e

cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.19 Tre schermate di esempio per la tab Comanda: selezione articolo,

inserimento manuale della quantità, inserimento di varianti . . . 513.20 Schema delle operazioni per la creazione di un dettaglio d'ordine 513.21 Tre schermate della tab conto: ultima comanda, ordine intero e

riepilogo articoli di varianti . . . . . . . . . . . . . . . . . . . . . 52

75

ELENCO DELLE FIGURE

76

Elenco delle tabelle

2.1 Tabella riassuntiva dei vincoli hardware e software . . . . . . . . 12

3.1 Tabella di soddisfacimento dei vincoli da parte delle tecnologieviste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2 tabella dei requisiti del modulo di autenticazione . . . . . . . . . 393.3 Tabella dei requisiti del modulo relativo alla schermata principale 403.4 Tabella dei requisiti del modulo Utilities . . . . . . . . . . . . . . 403.5 Tabella dei requisiti del modulo Risorse . . . . . . . . . . . . . . 413.6 Tabella dei requisiti della gestione ordine . . . . . . . . . . . . . 433.7 Tabella dei requisiti del modulo Agenda . . . . . . . . . . . . . . 43

4.1 Tabella dell'avanzamento nei requisiti dell'applicazione . . . . . . 57

77

WalkingPH: un'applicazione CRM mobile polivalente con la ...

Documents

Transcript of WalkingPH: un'applicazione CRM mobile polivalente con la ...