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'attività di stage che ha avuto luogo presso l'azienda Sintesi SAS, nalizzato alla
realizzazione dell'applicazione WalkingPH.
Nel primo capitolo è descritta l'azienda nel suo complesso, in particolar modo il
campo in cui opera, la sua storia e il prodotto di punta aziendale ovvero Planet
Hotel.
Il secondo capitolo contiene la descrizione del progetto di stage e la sua integrazione all'interno della strategia aziendale, no a denire gli obiettivi e i
vincoli ai quali il progetto è sottoposto.
Nel terzo capitolo è trattata l'attività di stage vera e propria, comprendente le
fasi di analisi del dominio, studio di fattibilità, progettazione e sviluppo dell'applicazione WalkingPH.
Inne nel quarto capitolo sono espresse alcune valutazioni riguardanti l'andamento e la conclusione dell'attivita di stage.
Convenzioni tipograche
I termini specici del dominio o tecnici ed acronimi sono segnalati alla loro prima
occorrenza attraverso la sottolineatura, tali termini sono riportati nel Glossario
assieme 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
Dati sull'azienda
1.2
Storia dell'azienda
. . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.3
Politica aziendale . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.4
1.5
2
Planet Hotel
. . . . . . . . . . . . . . . . . . . . . . . . . . .
1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.4.1
Struttura del prodotto . . . . . . . . . . . . . . . . . . . .
4
1.4.2
Ciclo di vita . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.4.3
Tecnologie impiegate . . . . . . . . . . . . . . . . . . . . .
7
Il futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
Il Progetto
9
2.1
La strategia aziendale
. . . . . . . . . . . . . . . . . . . . . . . .
9
2.2
Il progetto di stage all'interno della strategia aziendale . . . . . .
9
2.2.1
2.3
2.4
3
1
1.1
Evoluzione del progetto
Obiettivo del progetto
Vincoli applicativi
. . . . . . . . . . . . . . . . . . .
10
. . . . . . . . . . . . . . . . . . . . . . . .
11
. . . . . . . . . . . . . . . . . . . . . . . . . .
Vincoli software e strutturali
. . . . . . . . . . . . . . . .
12
2.4.2
Vincoli hardware . . . . . . . . . . . . . . . . . . . . . . .
12
Stage
3.1
3.2
3.3
3.4
11
2.4.1
13
Pianicazione delle attività
. . . . . . . . . . . . . . . . . . . . .
3.1.1
Obiettivi dello stage
. . . . . . . . . . . . . . . . . . . . .
13
13
3.1.2
Approccio al progetto
. . . . . . . . . . . . . . . . . . . .
14
3.1.3
Piano di lavoro . . . . . . . . . . . . . . . . . . . . . . . .
15
3.1.4
Revisioni e controllo qualità . . . . . . . . . . . . . . . . .
18
Analisi e studio del dominio . . . . . . . . . . . . . . . . . . . . .
20
3.2.1
. . . . . . . . . . . . . . . . .
20
Scelta degli strumenti di sviluppo . . . . . . . . . . . . . . . . . .
23
Un'applicazione polivalente
3.3.1
Tecnologia per la sincronizzazione
. . . . . . . . . . . . .
23
3.3.2
Soluzione scelta per la sincronizzazione . . . . . . . . . . .
29
3.3.3
L'IDE utilizzato: Windev Mobile 16
30
. . . . . . . . . . . .
Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.4.1
Progettazione del database
. . . . . . . . . . . . . . . . .
32
3.4.2
Divisione in moduli software
. . . . . . . . . . . . . . . .
35
3.4.3
Analisi dei requisiti . . . . . . . . . . . . . . . . . . . . . .
38
V
INDICE
3.4.4
3.5
4
. . . . . . . . . . . . .
44
Sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Struttura e diagrammi delle classi
48
3.5.1
Operazioni preliminari . . . . . . . . . . . . . . . . . . . .
48
3.5.2
Le iterazioni del metodo RAD
48
3.5.3
L'interfaccia graca
3.5.4
Lo sviluppo del modulo per la gestione ordine
. . . . . .
50
3.5.5
Funzionalità di salvataggio di emergenza . . . . . . . . . .
53
3.5.6
Dicoltà riscontrate . . . . . . . . . . . . . . . . . . . . .
53
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
Valutazione retrospettiva
4.1
Soddisfacimento dei requisiti
4.1.1
49
55
. . . . . . . . . . . . . . . . . . . .
55
Avanzamento nei requisiti . . . . . . . . . . . . . . . . . .
56
4.2
Divario conoscitivo . . . . . . . . . . . . . . . . . . . . . . . . . .
58
4.3
Conoscenze ed esperienze acquisite . . . . . . . . . . . . . . . . .
59
4.4
Considerazioni personali . . . . . . . . . . . . . . . . . . . . . . .
60
A Windev
A.1
61
Le caratteristiche . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
A.1.1
Il DBMS proprietario e l'accesso a database esterni . . . .
62
A.1.2
Il WLanguage . . . . . . . . . . . . . . . . . . . . . . . . .
62
A.1.3
Gli strumenti integrati . . . . . . . . . . . . . . . . . . . .
63
B Glossario
64
VI
Capitolo
1
Dominio 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 descrizione
del 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 Ugo
Indirizzo: Via Salemi 5, 30174 Mestre - VE
Telefono: +39 0415020613
Fax: +39 041942207
Turor aziendale: Bovo Ugo
1.2 Storia dell'azienda
L'azienda Sintesi è stata fondata nel 1982. L'attività principale di Sintesi consiste nello sviluppo di applicazioni software per la gestione aziendale.
Inizialmente l'azienda si occupava di software gestionali nell'ambito dell'amministrazione, del settore commerciale, della gestione del magazzino, del controllo
di gestione e di produzione. La prima esperienza aziendale nell'ambito turistico
fu la gestione dell'Economato per Arrigo Cipriani, al Harry's Bar di Venezia,
commissionato da Olivetti; ciò ha portato Sintesi ad esperienze interessanti e
formative con aziende industriali e commerciali, anche di dimensioni importanti
e addirittura internazionali (quali la Olivetti, la Yale Security Product, la BestEgypt).
Successivamente, dal 1984 ad ora, l'azienda si è orientata verso le applicazioni
nell'ambito turistico: hotel, campeggi, villaggi turistici, centri prenotazioni, ristoranti e distretti territoriali. Proprio grazie agli anni di lavoro in interventi nell'ambito dell'organizzazione e dell'architettura commerciale delle strutture ricettive
e turistiche, alla produzione di software l'azienda ha aancato 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 a
creare un prodotto software che presentasse il Tableau a colori, realizzato nell'ambito del progetto condotto con SEAC-Confcommercio e COALCE di Cervia.
Da allora, il ruolo di Sintesi consisteva nell'essere la produttrice di software nell'ambito turistico per Olivetti e SEAC-Confcommercio, ma anche un partner
tecnologico di Yale per quanto riguarda i sistemi informativi.
Non è un caso quindi che Sintesi sia una delle poche aziende in Europa ad
aver ottenuto l'omologazione di un Registro Navale Internazionale (RINA) per
i prodotti software di tipo Building Automation on-line, di cui uno è stato installato a bordo di due navi passeggeri.
Altre esperienze aziendali degne di nota sono la realizzazione di un sistema
informativo per la Confesercenti Toscana, studio di fattibilità per un progetto riguardante il distretto turistico per le Terme di Santa Cesarea e Comunità
Montana del Gargano, la progettazione e realizzazione della business unit per
strutture alberghiere per la Yale Security Product, avente come area di competenza Italia, India e Nord Africa, oltre a molte altre consulenze nel settore
turistico-ricettivo.
Nel 1996 è iniziato lo sviluppo del progetto Planet Hotel, quarta generazione
del software gestionale per le strutture turistico-ricettive sviluppato dall'azienda.
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 2011
sono in fase di sviluppo una linea di applicazioni del tipo social che potrebbero
vedere la pubblicazione di una prima applicazione social business entro l'anno
corrente.
1.3 Politica aziendale
L'azienda cerca di coniugare al meglio l'esperienza acquisita nel ambito dei progetti portati a termine in precedenza, dai quali deriva un impostazione professionale per la risoluzione dei problemi inerenti le varie problematiche più
ricorrenti nello sviluppo di software gestionali, con un'attitudine alla ricerca e
allo sviluppo, sperimentando le novità proposte dal panorama software mondiale, al ne di applicarle nell'ambito del settore turistico.
Inoltre Sintesi è molto recettiva per quanto riguarda le necessità dei clienti, il
quale molto spesso viene coinvolto attivamente nel suggerimento di funzioni,
moduli integrativi o programmi software che possano rendere il loro lavoro più
eciente.
Caratteristica dell'azienda è la particolare attenzione alle nuove tecnologie e ai
nuovi mezzi di comunicazione; dagli emergenti social network, ai sempre più
diusi dispositivi smartphone con sistemi operativi Android, symbian, windows
phone 7, a dispositivi portatili touchscreen come le tablet, potendone prevedere
un possibile utilizzo nel settore alberghiero.
Un chiaro esempio dell'interesse a queste nuove tecnologie è stato un progetto
di stage denominato ArtYou, il quale consiste in un social network legato al
mondo degli eventi e dell'arte, del quale è stata sviluppata l'applicazione per dispositivi con sistema operativo Android, mentre è tuttora in corso il deployment
per Symbian e iOS.
2
1.4.
PLANET HOTEL
1.4 Planet Hotel
Planet Hotel è il software gestionale per strutture turistico-ricettive di punta
di Sintesi, questo prodotto è articolato in una collana di moduli integrati tra
loro, allo scopo di essere essibile, esso infatti può essere impiegato in realtà
turistiche diverse tra loro: per questo tra gli utilizzatori del gestionale risultano
strutture alberghiere di piccola dimensione (Locanda Al Gallo di Oderzo, con
appena 12 camere), strutture del tipo business hotel di dimensioni importanti (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 quanto
riguarda la tipologia di struttura alberghiera, sia per quanto riguarda le dimensioni di quest'ultima; tutto ciò rende di fatto il prodotto un gestionale essibile e
completo. Proprio per questo Planet Hotel fornisce all'utente due approcci possibili durante l'utilizzo del gestionale: un approccio semplicato, per rendere
facile e veloce la registrazione o la consultazione dei dati, ed uno più ampio e
articolato; naturalmente l'utente è in grado di scegliere in qualunque momento
l'interfaccia più adatta alle sue esigenze.
Planet hotel è in continua evoluzione grazie all'integrazione del software gestionale con nuovi moduli orientati a supportare ogni aspetto del settore alberghiero; tra i moduli integrativi disponibili per il software, i più innovativi
sono il prodotto di importanti attività di ricerca nell'ambito tecnologico, anche
sviluppate in stretta collaborazione con istituti universitari.
Figura 1.1: Copertina depiant di Planet Hotel
3
CAPITOLO 1.
DOMINIO APPLICATIVO
1.4.1 Struttura del prodotto
Entrando più nel dettaglio, Planet Hotel è composto da ben 8 moduli software
che contengono al loro interno le funzionalità relative ad un settore specico
delle strutture alberghiere. Questi moduli e le loro funzionalità sono descritte
brevemente nelle successive sezioni.
Front Desk
Consiste nell'insieme di applicazioni che costituiscono il nucleo vero e proprio di
Planet Hotel, aggregando al suo interno le funzioni di base necessarie durante
le 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), attraverso
ricerche e visualizzazione dei dettagli della prenotazione, ma anche consentendo
l'operatività visuale grazie ad un'interfaccia di tipo Tableau nella quale vengono
visualizzate schematicamente le camere presenti nell'hotel e il loro stato.
Sempre da questo modulo è possibile eettuare le operazioni di check-out, denire
le tarie e i pacchetti, nonché possibili modiche al conto del cliente. Il modulo
in questione presenta anche una funzione di controllo automatico di cassa e di
contabilità, oltre a fornire una possibile integrazione con il sistema di building
automation, 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 Oce
Le funzionalità integrate nel modulo Back Oce comprendono la rendicontazione contabile, ovvero i dati provenienti dalle casse, le informazioni sui ricavi
e sui sospesi, ma anche il controllo degli addebiti, siano essi manuali o automatici. Tale modulo comprende al suo interno delle funzioni per la redazione di
report specici che consentono all'utente di esaminare consuntivi di occupazione
e consumi, oltre alle stime su situazioni predittive.
É inoltre presente una funzione di mailing integrata con le anagrache clienti,
agenzie e ditte, contribuendo signicativamente al CRM.
Figura 1.3: Graco predittivo generato da una funzione del modulo Back Oce
Amministrazione
Il modulo Amministrazione comprende tre diversi aspetti della gestione contabile di una struttura alberghiera:
•
Contabilità generale: integra le operazioni contabili alberghiere, spaziando
dalla contabilità generale e IVA, ad un modello semplicato di riclassicazione di bilancio, agevolando l'operatore nella gestione completa delle attività di controllo e di rilevazione scale, in osservanza delle norme vigenti
in merito.
•
Centri di costi e ricavo: permette la suddivisione dell'attività in reparti
distinti in base al costo e al ricavo, cosi rendere possibile la ripartizione
5
CAPITOLO 1.
DOMINIO APPLICATIVO
dei movimenti contabili in modo automatico o attraverso percentuali predeterminate, al ne di generare appositi report in grado di fotografare la
redditività di ogni reparto.
•
Estratti conto:
rende possibile la gestione delle scadenze di pagamen-
to, grazie all'ausilio di una completa dinamica delle partite aperte, delle
lettere di sollecito e dei saldi automatici delle partite.
Economato
Tale modulo consente la gestione di un magazzino centrale di una struttura
turistica e dei depositi ad esso connessi, comprende anche alcuni funzioni automatiche che gestiscono l'aggiornamento della situazione durante operazioni di
carico e scarico di prodotti verso altri depositi o strutture come lo possono essere ristoranti, dispense, discoteche, piani camere e vani di manutenzione. Sono
presenti anche funzioni di interrogazione di giacenza, di rimanenza iniziale e informazioni dettagliate sulle operazioni di carico e scarico, oltre alla possibilità di
accedere a una panoramica dalla quali si possono ottenere valutazioni analitiche
riguardanti ciascun magazzino o deposito specico.
Moneta elettronica
Un sistema informatico che consente al cliente il pagamento di beni e servizi
all'interno della struttura alberghiera con una tessera magnetica collegata ad
un borsellino elettronico relativo al cliente; la gestione del sistema potrà essere
di tipo a credito (prepagata con somme a scalare) oppure a debito (addebito su
un conto e saldo alla chiusura).
Booking center
Questo modulo software consente di avere un gestore di prenotazioni centralizzato, fondamentale nella gestione di catene di alberghi o gruppi di strutture
turistiche. Il software fornisce in tempo reale la situazione di disponibilità di uno
stabile o dell'intera catena attraverso l'utilizzo di maschere dinamiche, questo
consentirà il reindirizzamento delle prenotazioni secondo la politica adottata
dall'azienda alberghiera.
Prenotazione on-line
Gestisce tutte le necessità legate alla presentazione di listini, di oerte e disponibilità, attraverso l'integrazione del della piattaforma software con un sito internet anche preesistente. Rende possibile la visualizzazione della disponibilità e il
calcolo in tempo reale del prezzo di soggiorno attraverso listini tariari caricati
in precedenza; il cliente sarà inne messo in condizione di pagare on-line l'intero
importo della prenotazione oppure dell'anticipo.
Bar, Ristorante, Negozi
Questo modulo comprende le funzionalità necessarie alla gestione autonoma del
servizio ai tavoli, dall'apertura di un conto all'inserimento delle comanda da
parte di un operatore, all'emissione di un conto, ai riepiloghi di cassa; è prevista anche una funzione di stampa dei vari ordini secondo delle destinazioni
6
1.4.
predenite, atte alla preparazione dell'ordine stesso.
PLANET HOTEL
Sempre grazie all'inte-
grazione con il sistema Planet Hotel è possibile l'addebito dei prodotti consumati
direttamente nel conto collegato al cliente.
Figura 1.4: Tableau a colori per la gestione dell'occupazione tavoli nel modulo
Ristorante
1.4.2 Ciclo di vita
Planet Hotel è stato nel corso degli anni corretto e ottimizzato attraverso aggiornamenti rilasciati periodicamente da Sintesi. L'aspetto più importante però
consiste nel rilascio di nuovi moduli che integrano il software di nuove funzionalità talvolta concepite all'interno di Sintesi, altrimenti suggerite dagli stessi
clienti in base alle loro necessità. Ciò ha permesso a Planet Hotel di essere un
prodotto così longevo.
1.4.3 Tecnologie impiegate
Le tecnologie impiegate nella realizzazione di Planet Hotel quarta generazione
possono considerarsi datate, essendo degli strumenti software in commercio da
più di dieci anni. Le prime tre versioni di Planet Hotel (che allora portava il
nome di Excelsior) erano state sviluppate con tre strumenti di sviluppo differenti in base alla destinazione nale del software: in Business Basic per PC
Olivetti M20, Basic per PC MS-DOS e XBase-Clipper con DBIII in ambiente
SCO Unix.
7
CAPITOLO 1.
DOMINIO APPLICATIVO
L'ambiente software che è stato utilizzato per lo sviluppo della quarta generazione di Planet Hotel è Power++, un RAD acquisito da Sybase, che risulta
essere tra i prodotti archiviati e non più supportati della medesima software
house. Per quanto riguarda la gestione della base di dati, Planet Hotel è stato
creato con SQL Anywhere 5.0, sempre appartenente a Sybase, poi successivamente aggiornato no alla versione 8.0, nella quale è possibile la generazione di
database mobile di tipo UltraLite, e la possibile sincronizzazione con il database
consolidato (dal quale è stato generato il codice Ultralite) attraverso la tecnologia MobiLink (quest'aspetto è stato spiegato meglio nel capitolo riguardante lo
stage, 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 generazione di Planet Hotel, utilizzando strumenti tecnologici più all'avanguardia, al
ne di migliorarne l'aspetto graco, la portabilità e soprattutto le prestazioni.
Onde evolvere Planet Hotel in architetture integranti i mondi Desktop, Web e
Mobile, dal 2009 tutti i moduli di nuova realizzazione della linea di Planet Hotel sono sviluppati con IDE moderni: è stato utilizzato Microsoft Visual Studio
2008 e 2010, successivamente abbandonato in favore dei tre powerful IDE della
linea Windev, appartenenti alla software house francese PCSoft.
Questi am-
bienti integrati di sviluppo, particolar modo per Windev Mobile, sono ampiamente descritti nellla sezione riguardante gli strumenti utilizzati nel progetto
di stage e nell'appendice A. La strategia scelta per la migrazione della versione
Planet Hotel Windows/C++ verso la nuova generazione avverrà realizzando
moduli aggiuntivi (che utilizzano lo stesso database), al ne di acquisire l'ottimale conoscenza dei nuovi strumenti di sviluppo messi a disposizione dagli IDE
Windev; a novembre 2011 inizierà lo sviluppo sostitutivo dei vecchi moduli
C++.
8
Capitolo
2
Il Progetto
2.1 La strategia aziendale
L'azienda nella quale è stata svolta l'attività di stage utilizza una particolare organizzazione del lavoro. Ad ogni programmatore è adato un singolo progetto
e ne seguirà tutte le sue fasi, dallo studio di fattibilità, all'analisi del dominio,
dalla progettazione allo sviluppo vero e proprio; grazie questo il programmatore
ha una visione globale del progetto e ne conosce perfettamente ogni dettaglio.
Attualmente si possono individuare due progetti attivi che avanzano simultaneamente oltre al progetto di cui è oggetto questa relazione: un progetto consiste
nella creazione di un booking on-line, mentre il secondo è materia di uno stage
che consiste nel deployment dell'applicazione per Symbian e Iphone del precedentemente citato social network ArtYou.
A mio avviso questa strategia aziendale è più che altro dettata dalla presenza
in 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, assume
un'importanza fondamentale l'aspetto della relazione con il cliente da parte di
un operatore alberghiero, e ciò deve essere coaudiuvato attraverso l'utilizzo delle
applicazioni 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 soddisfare
l'idea di delizzazione con il cliente, quale strategia per fornire un servizio al
massimo dell'ecienza, con il ne di attrarre nuovi clienti e mantenere saldi i
rapporti con clienti abituali e importanti (attraverso l'analisi dei dati riguardanti le preferenze del cliente durante le precedenti permanenze e mantenendolo
informato 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 tre
moduli per la gestione del CRM di un centro Wellness presente all'interno di
una struttura alberghiera. Il primo modulo consiste nella creazione di un software che consenta a un medico, appartenente allo sta alberghiero, di gestire
in maniera eciente e automatizzata il controllo medico obbligatorio, prima
di poter somministrare ad un cliente le cure e i prodotti del centro benessere;
possono essere individuate dunque due parti essenziali nel primo modulo, una
parte in cui il medico crea un questionario sotto forma di template per ogni
tipologia di visita medica, personalizzando le domande da sottoporre al cliente
e indicando le eventuali risposte di default, la seconda parte invece consiste nella
compilazione del questionario durante la visita medica del cliente da parte del
medico; naturalmente tutti i dati inseriti saranno salvati nella realtiva tabella
del database di Planet Hotel.
Il secondo modulo tratta la gestione di un'agenda che organizza gli appuntamenti
per la somministrazione di cure nel centro benessere, si tratta di un calendario
multidimensionale che consente la prenotazione, la modica e al disdetta di
un trattamento da parte di un operatore, attraverso l'utilizzo di un interfaccia
graca interattiva che visualizzi la disponibilità delle risorse e del personale a
disposizione, all'interno del centro benessere, in funzione del tempo.
Si tratta dunque di un applicazione organizza in tempo reale l'attività del personale e l'impiego delle risorse, rendendo possibile la consultazione e la stampa
di 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 ovvero
un'applicazione di gestione di CRM per palmari PocketPC (con sistema operativo Windows Mobile 5 o 6) o smartphone (con sistema operativo Android)
che consenta all'operatore la consultazione e modica del proprio programma
di attività giornaliero e la registrazione e addebito dei trattamenti e prodotti
somministrati al cliente.
L'applicazione mobile prevede la sicronizzazione del
database mobile con il database consolidato qualora fosse disponibile la connessione con la rete wireless, consentendo anche l'esecuzione in modalità o-
line dell'applicazione scrivendo le modiche sul database mobile in attesa della
sincronizzazione successiva.
2.2.1 Evoluzione del progetto
Durante la fase di denizione del progetto con il tutor aziendale ci siamo resi
conto che i meccanismi di funzionamento di un'applicazione per la gestione del
CRM di un centro wellness potevano benissimo essere generalizzati e adattati
a qualsiasi punto vendita presente della realtà alberghiera, infatti è possibile
individuare molti elementi in comune tra i vari esercizi di commerciali o di
erogazione di servizi: nell'erogazione di un servizio, una stanza contenente strumentazioni potrebbe essere vista come una risorsa, allo stesso modo il bancone
di un bar, la cassa di un mini-market e il tavolo di un ristorante potranno essere
considerati come risorse alle quali collegare l'ordine di beni e servizi richiesti da
un cliente.
Analogamente i beni e servizi possono essere distinti in categorie (come le
pietanze servite in un ristorante vendono raggruppate in portate) e individuati
in 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 cameriere
che prende le ordinazioni ai tavoli di un ristorante, un massaggiatore che eroga
trattamenti benessere utilizzando e addebitando prodotti quali oli, creme o candele profumate, oppure una cassiera di un minimarket all'interno delle struttura
alberghiera o addirittura un responsabile addetto alle gite guidate organizzate
dall'Hotel stesso.
Queste considerazioni hanno portato all'allargamento del dominio del progetto
non più solo al modulo di Planet Hotel relativo al wellness, ma anche al modulo
contenente la gestione di un bar, di uno ristorante o di un punto vendita generico, rendendo così l'oggetto del progetto di stage un applicazione orientata al
CRM estremamente versatile, anche in previsione di destinazioni future.
2.3 Obiettivo del progetto
L'obiettivo del progetto di stage è dunque la realizzazione di un'applicazione
mobile per la gestione del CRM di un punto vendita generico all'interno di una
realtà turistica.
L'applicazione risultante deve avere queste caratteristiche:
•
Il software deve poter mettere in condizione l'operatore di poter eettuare
ordinazioni di beni e servizi richiesti da un cliente, e di poterne addebitare
il costo nel relativo conto, qualora il cliente di tipo residente o avente
una prenotazione attiva.
•
Un aspetto fondamentale consiste nel fatto che l'applicazione sia solida e
sicura, soprattutto in caso di malfunzionamento del dispositivo sul quale
viene eseguita.
•
Deve essere possibile il cambio del punto vendita e di operatore durante
l'esecuzione, attraverso il salvataggio del contesto precedente e il caricamento da database di quello nuovo.
•
L'applicazione deve essere scritta e pensata in funzione dell'utilizzo che ne
farà l'utente nale, quindi il software deve essere di semplice utilizzo ma
al tempo stesso completo.
•
Il programma deve poter sfruttare i tempi di inutilizzo, per poter eseguire
le necessarie operazioni di sincronizzazione tra il database consolidato e
quello mobile, le quali in genere risultano lunghe e possono portare a
indesiderati rallentamenti di sistema.
•
L'applicazione mobile deve poter essere eseguita su dispositivi mobile quali
PocketPC e smartphone Android.
,
2.4 Vincoli applicativi
Durante la fase di prima analisi del progetto sono stati identicati vincoli imposti dalle tecnologie coinvolte nello sviluppo dell'applicazione mobile i quali si
possono 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 eettua una sincronizzazione con
alcune tabelle del database di Planet Hotel, tra i vincoli imposti vi è proprio
quello di dover sincronizzare il database mobile con un database consolidato di
tipo SQL Anywhere versione 8, d'altro canto però in caso di un possibile riscrittura di Planet Hotel, le modiche da apportare all'applicazione per renderla
compatibile con la nuova versione, deve richiedere il minor dispendio di tempo
e risorse; ciò signica che la sincronizzazione dovrà avvenire anche con database
consolidati di tipo HFSQL (descritti nel paragrafo relativo a gli IDE della linea
Windev).
Un ulteriore vincolo richiesto è la possibilità di far eseguire l'applicazione su
diversi dispositivi mobile, ciò comporta restrizioni riguardo alle tecnologie supportate; per fare un esempio, il sistema operativo Android non ammette tuttora
la 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, derivano
dalla necessità di eseguire il deployment dell'applicazione anche per dispositivi
con Windows Mobile 5 e 6, tali dispositivi sono in genere PocketPC ed hanno
però una limitata potenza di calcolo e ancor più lento accesso alla memoria
secondaria, tanto che l'esecuzione di query su tabelle di un database mobile,
risulta richiedere un tempo non indierente, qualora i record da elaborare siano
numerosi.
Codice
V01_St
Descrizione
Tipo
Il database mobile deve avere una struttura
Strutturale
combatibile con quella del database di Planet
Hotel
V02_Sf
Possibilità di sincronizzazione con i database
Software
di tipo Sybase SQL Anywhere 8
V03_Sf
Possibilità di sincronizzazione con database
Software
HyperFile SQL
V04_Sf
Nella versione per Android il database mobile
Software
deve essere obbligatoriamente SQLite
V05_Sf
L'applicazione deve poter essere eseguita su
Software
sistemi operativi Windows Mobile
V06_Hd
L'applicazione deve poter essere usabile anche
Hardware
nell'esecuzione su dispositivi PocketPC
Tabella 2.1: Tabella riassuntiva dei vincoli hardware e software
12
Capitolo
3
Stage
3.1 Pianicazione delle attività
Al ne di identicare le attività da svolgere durante lo stage e dare loro un
contesto temporale, su indicazione del tutor universitario, è stato stilato un
documento nel quele venivano specicati gli obiettivi dello stage e un piano
di lavoro sucientemente dettagliato, tale da fornire sia allo studente che al
titolare 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 probabilità di ottenere al termine dello stage un'applicazione solida e che rispetti i
parametri di qualità richiesti dall'azienda.
Obiettivi primari
Gli obiettivi primari sono stati divisi in due categorie, dove gli obiettivi della seconda categoria potranno essere sviluppati convenientemente solo qualora
siano stati conseguiti tutti quelli presenti nella prima categoria.
Qui di seguito vengono riportati gli obiettivi in maniera schematica e rispettando
la divisione in categorie di appartenenza precedentemente accennata.
1. Studio di fattibilità
•
Indagine e scelta della tecnologia per lo sviluppo dell'applicazione
mobile.
•
Indagine e scelta della tecnologia adatta alla sincronizzazione tra
il database mobile e il database consolidato, secondo esigenze di
scalabilità e compatibilità.
•
Sviluppo di un prototipo di applicazione mobile, per eseguire test
sulla sincronizzazione tra Database mobile e consolidato, utilizzando
le tecnologie scelte.
13
CAPITOLO 3.
STAGE
2. Progettazione e Sviluppo
•
Progettazione e creazione del database mobile, attraverso la denizione
delle tabelle e funzioni necessarie alla sincronizzazione.
•
Realizzazione del diagramma delle classi per il funzionamento dell'applicazione.
•
Progettazione e realizzazione delle form grache funzionali all'applicazione.
Obiettivi secondari
Gli obiettivi secondari dello stage consistono in un modulo relativo all'interfaccia dell'applicazione mobile con dispositivi di stampa attraverso le stampanti
presenti in rete.
•
Progettazione e realizzazione di un modulo applicativo dedicato alla creazione
di report stampabili.
•
Progettazione e sviluppo di funzioni di interfacciamento con stampanti di
rete per la stampa di report.
Obiettivi opzionali
Gli obiettivi opzionali del progetto consistono nella realizzazione di un modulo integrativo all'applicazione per la gestione e controllo delle attività di un
operatore all'interno della struttura alberghiera.
•
Progettazione e realizzazione di un'interfaccia utente per gestione e l'organizzazione delle attività.
•
Realizzazione di un'interfaccia graca per la consultazione dell'agenda
relativa all'operatore.
3.1.2 Approccio al progetto
Un fattore non trascurabile nella stesura del piano di progetto è stato il tenere
conto delle risorse in termini di personale che sarebbero state impiegate nello
svolgimento delle attività di progetto.
Come precedentemente spiegato nel capitolo riguardante il progetto, in particolare nella strategia aziendale, con ogni probabilità mi sarei trovato a svolgere da
solo la grande maggioranza delle attività preliminari di progetto, con la ebile
speranza di essere aancato da una persona aggiuntiva durante la fase di sviluppo; ciò nonostante avrei potuto sempre contare nel supporto del tutor aziendale
qualora avessi avuto bisogno di chiarimenti sui meccanismi di funzionamento e
sulla struttura del PMS aziendale.
Tenendo conto di questi fattori, in accordo col tutor aziendale, ho preferito un
approccio simile a quello denito in ingegneria del software come modello incrementale (ISO 12207); questa scelta è stata dettata soprattutto dal fatto di
essere il solo dedicato a questo progetto, il che mi permetteva di avere una visione globale del progetto, a patto di dover dedicare molto tempo all'analisi del
dominio 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 sviluppo
iterando il ciclo presente nel modello incrementale (progettazione nel dettaglio
e realizzazione) ntanto il risultato non fosse stato quello gradito, e procedere
con 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 conseguimento
del maggior numero di obiettivi descritti in precedenza, ho stilato con il tutor
aziendale un dettagliato piano di lavoro, secondo il quale il progetto di stage
doveva essere diviso in cinque fasi distinte, aventi una durata stimata in giornate
lavorative di 8 ore ciascuna.
Analisi di dominio
•
Nozioni sull'organizzazione interna di una struttura ricettiva, in particolare nei reparti di ricevimento, segreteria e operativo nel settore turistico
e 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 settore
alberghiero.
15
CAPITOLO 3.
•
STAGE
Analisi della struttura dei database utilizzati dalle applicazioni in uso alle
aziende del settore.
Durata: 6 giorni lavorativi.
Studio di fattibilità
•
Indagine sugli strumenti di sviluppo di applicazioni per PDA.
•
Analisi delle tecnologie per la sincronizzazione tra database mobile e database
consolidato.
•
Studio degli strumenti per la produzione di report e stampa su periferiche
di rete.
•
Stesura documentazione relativa allo studio di fattibilità
Durata: 6 giorni lavorativi.
Progettazione
•
Divisione dell'applicazione in moduli software (database, graca, connessioni e interfacce).
•
Formalizzazione delle tabelle e relazioni nel database mobile
•
Denizione delle form grache di consultazione e inserimento dati.
•
Stesura documentazione relativa alla progettazione, integrata con diagrammi UML e use-case.
Durata: 5 giorni lavorativi.
Sviluppo
•
Attività di sviluppo dell'applicazione mobile
•
Integrazione con il PMS aziendale
•
Creazione ed esecuzione di test funzionali.
Durata: 17 giorni lavorativi.
Prove di carico
•
Prova conclusiva di carico, con l'esecuzione simultanea dell'applicazione
su più dispositivi.
Durata: 3 giorni lavorativi.
16
3.1.
PIANIFICAZIONE DELLE ATTIVITÀ
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 abbiamo
deciso in comune accordo quelle che dovevano essere le linee guida per il controllo
della qualità delle attività svolte durante lo stage.
Data la diversa natura delle attività svolte a seconda della fase di progetto alle
quali appartenevano, sono stati decisi due diversi approcci nel controllo della
qualità del lavoro svolto: revisioni di analisi e revisioni di sviluppo.
Qui di seguito ho riportato le linee guida convenute, distinte in base alla fase in
cui il progetto si trovava.
Revisioni di analisi
Il comportamento da me adottato durante le fasi preliminari allo sviluppo è
stato il seguente:
•
In un breve breng quotidiano sottoponevo all'attenzione del tutor aziendale le informazioni da me raccolte e analizzate.
•
Qualora sorgessero eventuali dubbi durante un'attività di analisi, sulle
tecnologie o su un meccanismo di Planet Hotel, avrei dovuto chiedere
chiarimenti al tutor aziendale, onde evitare fraintendimenti.
•
Al termine di ogni singola attività descritta nel piano di lavoro sarebbe
stato fatto un punto della situazione, in modo da decidere come procedere
con le attività successive.
Revisioni di sviluppo
Una volta completate le attività di analisi e di progettazione, è stata arontata
la fase di sviluppo del software, e il comportamento convenuto per il controllo
della qualità è stato così denito:
•
Disegnata una form con i relativi oggetti graci, avrei dovuto sottoporla
al tutor aziendale per vericarne la chiarezza, in previsione dell'utilizzo di
un utente nale.
•
Qualora una funzione richiedesse un tempo di calcolo eccessivamente prolungato e intaccare l'usabilità del sistema, avrei dovuto individuare le
soluzioni che a mio avviso fossero le più adatte, e sottoporre e discutere il
problema con il tutor aziendale al ne di individuare la soluzione migliore.
•
Al termine dello sviluppo delle funzionalità presenti in una form e dopo
aver eseguito tutti i test funzionali del caso, avrei dovuto presentare tale
form, in esecuzione sul dispositivo mobile di test, all'attenzione del tutor
di modo che ne potesse constatare il corretto funzionamento e l'eettiva
usabilità.
Questi controlli frequenti, soprattutto nella fase di sviluppo sono risultati fondamentali, poiché permettevano la rettica del funzionamento dell'applicazione in
tempi relativamente brevi, qualora il risultato non fosse stato quello desiderato
come nale dal tutor aziendale.
18
3.1.
PIANIFICAZIONE DELLE ATTIVITÀ
Rapporto settimanale
Per quanto riguarda la rilevazione da parte del tutor universitario del lavoro
da me svolto durante lo stage aziendale, è stato concordato che ogni settimana,
per le otto settimane corrispondenti della durata totale, avrei dovuto inviare al
docente un rapporto dettagliato riguardante le attività svolte, correlato di uno
schema che quanticasse lo stato nel raggiungimento degli obiettivi di stage in
forma percentuale.
Questo report settimanale veniva inoltre sottoposto anche al tutor aziendale, in
modo tale da renderlo informato sullo stato globale sull'andamento del progetto
di stage.
19
CAPITOLO 3.
STAGE
3.2 Analisi e studio del dominio
Nelle settimane iniziali dell'attività di stage ho svolto un importante studio
riguardante le operazioni eseguite dal personale di una struttura adibita al wellness, e più in generale ai meccanismi riguardanti la vendita di beni e servizi
all'interno di una struttura alberghiera.
Grazie a un caso fortuito ho avuto l'occasione di eettuare un sopralluogo all'Hotel Mioni-Pezzato di Abano Montegrotto (PD), al di fuori dell'orario di lavoro, e
di poter cosi raccogliere informazioni sulle tipologie di servizi erogati e rendermi
conto delle situazioni reali che possono intervenire durante la somministrazione
di prodotti e cure all'interno di una struttura di quel tipo, benché non fossero
utilizzati 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 studiate in un supporto di tipo software, tra cui l'inserimento di una prenotazione
oppure l'addebito sul conto di un cliente derivato dall'acquisto di un prodotto.
In questo modo potevo comprendere il meccanismo di inserimento delle informazioni sotto forma di record all'interno delle varie tabelle del database di Planet Hotel; ho studiato anche la struttura del database, composta dalle relazioni
tra le chiavi e le chiavi esterne che intercorrevano tra le tabelle, visualizzabili
attraverso l'ausilio degli strumenti di gestione graci messi a disposizione dal
DBMS SQL Anywhere 8 di Sybase.
3.2.1 Un'applicazione polivalente
Proseguendo nello studio dell'ambito wellness e delle applicazioni riguardanti
l'ambito alberghiero, tra cui applicazioni precedentemente studiate per la gestione di un ristorante, concepito internamente a Sintesi ma non ancora realizzato, il tutor aziendale ed io ci siamo resi conto che il fatto di suddividere le cure
e i prodotti per tipologia, poteva essere fatto anche per un punto vendita che
potesse essere un negozio o un reparto ristorativo all'interno di una struttura
alberghiera.
Le stesse similitudini intercorrevano persino nei meccanismi grazie ai quali gli
addetti 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 intero
identicativo univoco, quindi le form grache e le funzioni di ricerca e selezione
del cliente all'interno dell'anagraca potevano essere eseguite indipendentemente
dal punto vendita nel quale il cliente richieda l'acquisto di un bene o l'erogazione
di un servizio.
Ci siamo inne resi conto che il punto vendita che richiedeva il meccanismo
di gestione più complesso è la struttura ristorativa, mentre tutti gli altri punti
vendita richiedevano una gestione più semplice, tale da risultare una derivata
semplicata della gestione di tipo ristorativo.
Nei seguenti paragra sono riportati alcuni esempi delle similitudini tra le strutture dati contenenti le ordinazioni per tre tipi di punti vendita apparentemente
incompatibili.
20
3.2.
ANALISI E STUDIO DEL DOMINIO
Punto vendita 1: ristorante
Comincio l'analisi di funzionamento riportando l'esempio del punto vendita ristorativo. Dallo schema si possono notare gli elementi base che compongono un
ordine: l'ordine stesso, le comande, i dettagli d'ordine e le uscite, posizionate
in funzione del tempo di vita di un ordine, il quale viene creato all'inizio del
pasto e che viene chiuso nel momento un cui il cliente lascia il ristorante.
Al ristorante un cliente può eettuare una o più ordinazioni (chiamate comande e distribuite nell'arco di tempo della durata del pasto), nelle quali vengono
ordinate svariate portate e bevande (gli articoli presenti nel listino e chiamati
dettagli ordine ) secondo una specica sequenza di uscita (antipasti, primi,
secondi), tali ordinazioni sono però raggruppate in un ordine.
La complessità nella gestione delle uscite risulta chiara dallo schema temporale
riportato in seguito, infatti un dettaglio d'ordine può essere associato a un'uscita
indipendentemente 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 relativo alle uscite degli articoli nel ristorante non si pone più, perciò avremo una
sequenza di ordinazioni coerente con lo scorrere del tempo.
Lo schema di seguito riportato tratta le richieste di un cliente ad un operatore, prima richiedendo tre prestazioni o prodotti (identicate dai tre dettagli
ordine, che possono essere un massaggio lombare(1), con miele(2) e candele
profumate (3)), successivamente decide di richiedere altre tre prestazioni prima
della chiusura del conto.
Anche qui come per il ristorante, possiamo identicare gli elementi base di un
ordine:
21
CAPITOLO 3.
•
STAGE
L'ordine, che viene creato al momento dell'arrivo del cliente e chiuso
all'uscita dal centro.
•
Le comande, che identicano 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 avviso
la più semplice in termini di meccaniche operative, il punto vendita minimarket
riduce gli elementi dell'ordine, necessari in un ristorante, a coincidere tra loro.
Come schematizzato dall'illustrazione possiamo vedere che l'ordine è composto
da una sola comanda e nasce nel momento in cui un cliente si presenta alla
cassa e viene chiuso nel momento del pagamento o dell'addebito degli articoli
acquistati, i quali coincidono coi dettagli ordine.
In questo caso quella che prima era chiamata uscita, coincide con la spesa del
cliente, 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 lo
sviluppo 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 fattibilità più complessa è proprio quella riguardante la sincronizzazione tra database
lo consolidato e mobile. Tra tutte le tecnologie prese in esame nessuna ha potuto soddisfare tutti i vincoli imposti dal dominio.
Per l'identicazione delle
tecnologie di sincronizzazione esaminate ho scelto la sigla synchro seguita da
un numero sequenziale.
Qui sotto è riportato il risultato dello studio di fattibilità riguardante le tecnologie di sincronizzazione.
Synchro 1: Mobilink e Ultralite
La prima tecnologia di sincronizzazione presa in esame è quella fornita da Sybase
SQL Anywhere 8 per la sincronizzazione dei database dei dispositivi mobile, attraverso 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 denite a priori (la
versione 8 di SQL Anywhere non permette l'esecuzione di query con codice SQL
creato dinamicamente, ma solo attraverso query parametriche predenite).
Mobilink è la tecnologia utilizzata per la gestione della sincronizzazione tra
database prodotti da Sybase, per mezzo del modello client-server.
Nell'immagine possiamo vedere in maniera schematica il funzionamento della
sincronizzazione 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 manipolare la struttura di un database SQL Anywhere 8, ma cosa più importante,
è possibile utilizzare un editor per la creazione dei le necessari all'accesso a
un database di tipo Ultralite, generato partendo dalla struttura di un database
preesistente.
La procedura per la creazione di un database Ultralite con un
client Mobilink integrato e dell'interfaccia di accesso di Java è la seguente:
1. Accedere a un database SQL Anywhere 8 attraverso una connessione
ODBC.
2. Creare un utente di tipo Ultralite e attivare la sottoscrizione al database
connesso.
3. Aggiungere alla sottoscrizione creata tutte le tabelle necessarie all'applicazione che userà Ultralite.
4. Aggiungere alla sottoscrizione tutte le query parametriche necessarie alla
consultazione del database mobile.
5. Congurare nella sottoscrizione i parametri per la sincronizzazione via
Mobilink.
6. Denire e aggiungere al database consolidato eventuali trigger o procedure
di sincronizzazione.
7. Eseguire il comando da shell per la creazione del database Ultralite relativo
alla sottoscrizione.
8. Generazione dei le delle classi e dell'interfaccia in Java SE per l'accesso
al 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 funzioni
Mobilink.
24
3.3.
SCELTA DEGLI STRUMENTI DI SVILUPPO
•
Un le .db nel quale è persente il database Ultralite.
•
Un interfaccia Java che descrive le funzioni di accesso al database mobile
e per la sincronizzazione.
immagine mobilink
Figura 3.7: Struttura di un database Ultralite accessibile da un applicazione
Java
Considerazioni:
Per vericare le potenzialità di questa tecnologia è stato sviluppato, in collaborazione con un programmatore di Sintesi, un prototipo di applicazione Java (e
C++ eettuata dal mio collega), che accedesse a un database di due sole tabelle
e che ne eettuasse 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 in
Java SE (Standard Edition), e assenti in Java ME (Mobile Edition), a
nulla ha portato l'individuazione e l'inserimento manuale delle librerie
necessarie, a causa di un errore a runtime.
•
La stessa cosa vale per l'integrazione con un prototipo di applicazione per
Android, 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 documentazione
in merito e dalla sollevazione di un errore generico in fase di esecuzione
dell'applicazione C++.
•
L'esecuzione dell'applicazione Java su dispositivi PocketPC avrebbe reso
necessaria l'installazione di JVM per Windows Mobile 5 anche di tipo
25
CAPITOLO 3.
STAGE
opensource (Maysaifu), ma dalla natura instabile e non contenenti le
librerie necessarie.
•
Visti i punti precedenti la scarsa cura nella segnalazione dell'entità degli
errori riscontrati nell'utilizzo dell'accesso a un database Ultralite, hanno
reso la fase di test un esperienza piuttosto frustrante.
•
Il dover ridenire o creare nuove query, comporta la rigenerazione e la
riscrittura dei tre le attraverso i quali avviene l'accesso al database mobile, rendendo necessaria una lunga attività di test sulle modiche apportate.
Ribadisco nuovamente che il DBMS utilizzato è SQL Anywhere 8, quello utilizzato dal ultima versione di Planet Hotel, probabilmente versioni più recenti o
future del DBMS Sybase renderanno possibili le operazioni di integrazione da
noi eettuate con insuccesso.
Synchro 2: collegamento remoto via ODBC
Non una vera e propria sincronizzazione quanto una connessione remota via
ODBC al database di Planet Hotel. L'idea era quella di eseguire una lunga serie
di query di tipo select sulle tabelle del database consolidato (connesso remotamente via ODBC) al ne di popolare il database mobile con le informazioni
ricevute, 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 vincoli
tecnologici ssati la rendono irrealizzabile a causa dei seguenti problemi:
•
Windows Mobile non fornisce nè un ODBC driver manager nè un ODBC
administrator, quindi nemmeno la possibilità di accesso a remoto via
ODBC.
•
Lo stesso vale per le applicazioni per Android, dove sono presenti librerie
solo per SQLite.
•
La rete aziendale avrebbe dicilmente supportato il trasferimento di moli
non indierenti di dati, sia in termini di adabilità del segnale (per reti
Wi-), sia in termini di velocità di trasferimento.
Synchro 3:
Mobile
OLEDB via ODBC Sybase, HFSQL classic e HFSQL
Questa soluzione consiste in un applicazione ponte realizzata in Windev che
accede al database di Planet Hotel attraverso l'utilizzo dello standard OLEDB
via connessione ODBC, tale standard avrebbe premesso la scrittura e la lettura delle informazioni presenti nel database di tipo SQL Anywhere 8. Dovrà
esserci un modulo software in grado di eettuare una sincronizzazione tra le
informazioni ricevute dal database di Planet Hotel e un database di struttura
identica ma creato usando HFSQL Classic. Tutto ciò anché possa essere utilizzato lo strumento di sincronizzazione tra un database HFSQL classic e un
database HFSQL Mobile (che è utilizzato dall'applicazione mobile) presente in
Windev e Windev mobile; la tecnica di sincronizzazione automatica utilizzata
26
3.3.
SCELTA DEGLI STRUMENTI DI SVILUPPO
prende il nome di Universal Replication.
Nell'immagine sottostante è schematizzata la struttura dell'applicazione che fa
da ponte ai due database.
Figura 3.8: Struttura dell'applicazione ponte
La tecnica per la sincronizzazione chiamata Universal Replication è uno dei
quattro metodi di sincronizzazione per database HFSQL che gli IDE Windev
mettono a disposizione, ma è l'unica che coinvolge database HFSQL Mobile.
Il meccanismo utilizzato per questo tipo di sincronizzazione consiste nella creazione
e nell'invio di le .rpa tra le entità master (database consolidato) e uno o più
subscriber (database mobile). La procedura utilizzata per la congurazione delle
entità precedente descritte è la seguente:
1. Attivare l'Universal Replication attraverso il comando specico.
2. Creare il le identicatore del Master replica.
3. Creare un le Subscribe Replica per ogni dispositivo mobile dando come
parametro il riferimento al Master Replica
4. Avviare la sincronizzazione iniziale dei subscribers con le informazioni del
Master :
•
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 volta
terminato 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 di
Windev
Considerazioni: Questa soluzione, per quanto complessa possa risultare, è
da considerare la migliore tra quelle viste nora. La soluzione è valida sia nell'eventualità in cui venga mantenuto il database attuale di Planet Hotel (al quale
si accede con OLEDB via ODBC), sia nell'eventualità di una quinta edizione del
PMS aziendale realizzata in Windev, dato che la sincronizzazione tra database
HFSQL è già prevista dalla Universal Replication, quindi l'applicazione ponte
non sarebbe più richiesta al ne della sincronizzazione e gli script di congurazione delle entità Master
e Subscriber diventerebbero riutilizzabili.
Tra i
fattori da prendere in considerazione riguardo a questa tecnica è il fatto che
utilizzando lo standard OLEDB via ODBC si perde ogni riferimento alle chiavi primarie ed esterne delle tabelle, e di conseguenza anche le relazioni tra le
tabelle.
Synchro 4: accesso nativo a database Sybase e HFSQL Mobile
Questa tecnica è molto simile rispetto a quella vista in precedenza, eccezione
fatta 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 accesso
nativo a database Sybase. Ciò permetterebbe di mantenere le chiavi e le relazioni
tra le tabelle, oltre alle procedure e ai trigger. Purtroppo quest'ipotesi è stata
subito scartata per due motivi essenzialmente economici:
•
Il prezzo del modulo software di accesso nativo è molto alto, nonché la
licenza per il suo utilizzo è valida per un solo computer.
•
Anche in caso di acquisto del modulo di accesso nativo, il tipo del database
al quale si vuole accedere deve essere Adaptive Server Enterprise 10 (ASE
10) o superiore, quindi sarebbe necessario un avanzamento di versione per
il database di Planet Hotel (dunque gli l'acquisto della versione ASE 12
di Sybase e del modulo di accesso nativo a Sybase di Windev)
28
3.3.
SCELTA DEGLI STRUMENTI DI SVILUPPO
3.3.2 Soluzione scelta per la sincronizzazione
Dopo aver preso in esame le varie possibilità per eettuare la sincronizzazione tra
database consolidato e database mobile, possiamo riepilogare in forma tabulare
le relazioni tra soluzione considerata e soddisfacimento dei vincoli (Si se il
vincolo risulta soddisfatto, No se non soddisfatto).
Codice Vincolo
Synchro 1
Synchro 2
Synchro 3
V01St
V02Sf
Synchro 4
Si
Si
Si
Si
Si
No
Si
No
V03Sf
No
No
Si
Si
V04Sf
No
No
No
No
V05sf
No
No
Si
Si
V06Hd
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 rispettati e per la reale fattibilità, tra le soluzioni prese in considerazione la soluzione
Synchro 3 sia la migliore, poiché è realizzabile senza l'acquisto di ulteriore
software.
Dalla tabella emerge anche il fatto che nessuna tra le soluzioni individuate soddisfa il vincolo V04sf, ovvero l'utilizzo di database SQLite su dispositivi Android, perché attualmente la sincronizzazione di database SQLite non è ancora
stata implementata per né database di tipo Sybase né di tipo HFSQL. Presentate queste considerazioni al tutor aziendale abbiamo appurato il fatto che
l'aspetto negativo nella realizzazione della soluzione Synchro 3 sta nel poter
richiedere no a due mesi di lavoro e nell'impiego di più di una persona, data
la complessità e la delicatezza nella formalizzazione e sviluppo delle funzioni di
sincronizzazione presenti nell'applicazione ponte.
Ciò ha portato il tutor aziendale a prendere le seguenti conclusioni riguardanti
lo svolgimento delle attività e il ridimensionamento degli obiettivi dello stage:
•
Accantonare temporaneamente la parte del progetto di stage relativa alla
sincronizzazione tra database di Planet Hotel e quello di WalkingPH, e
valutare la possibilità che diventi materia per uno stage.
•
Realizzare l'applicazione WalkingPH attraverso l'utilizzo del IDE Windev
Mobile 16 e eettuando il deployment su dispositivi con sistemi operativi Windows Mobile 5 e 6, nella speranza che nelle versioni successive
di Windev possa essere disponibile l'utilizzo del Universal Replication
o di una tecnica simile anche per sincronizzare database di applicazioni
Android.
29
CAPITOLO 3.
STAGE
3.3.3 L'IDE utilizzato: Windev Mobile 16
L'IDE scelto per la realizzazione dell'applicazione WalkingPH è il sistema di
sviluppo integrato Windev Mobile 16 della linea di prodotti Windev della soft-
ware house francese PCSoft. In realtà la scelta di questo ambiente di sviluppo
era già presa in considerazione dal tutor aziendale n nei primi studi preliminari sul progetto, vista l'imminente inizio della realizzazione di Planet Hotel
proprio con i prodotti della stessa linea (per informazioni aggiuntive riguardo ai
prodotti Windev consultare l'appendice A). Come database mobile è stato scelto, come prevedibile, HFSQL Mobile, data la concreta possibilità di poter essere
sincronizzato con un database HFSQL classic, ovvero il database col quale verrà
realizzata la nuova versione di Planet Hotel.
L'IDE Windev Mobile 16 integra al suo interno strumenti di tipo CASE orientati
a un metodo di sviluppo RAD. Purtroppo in Sintesi era ed è tuttora presente
una sola licenza d'utilizzo per l'IDE nora descritto, ciò signica che anche
durante la fase di sviluppo, non sarei stato aancato 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 la
realizzazione di prototipi di applicazione, i quali vengono integrati di nuove
funzionalità secondo un metodo iterativo, ripetuto no a quando il risultato
ottenuto 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 graci; tale metodo consente allo sviluppatore di tenere
sotto controllo lo stato di avanzamento nella realizzazione del software grazie a
una visione globale di tutte le funzionalità in esso implementate.
svantaggi del metodo RAD sono:
30
I principali
3.3.
•
SCELTA DEGLI STRUMENTI DI SVILUPPO
La scarsa scalabilità del risultato nale, dato che le migliorie sono realizzabili solo mediante ulteriori iterazioni della tecnica di sviluppo RAD.
•
Il rischio di appesantire gradualmente l'applicazione durante le iterazioni
di 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 eettuate avvenivano su dispositivi mobile reali (PocketPC iPAQ) e non solo attraverso il simulatore messo
a disposizione da Windev Mobile.
I problemi riscontrati
Purtroppo i prodotti della linea Windev non hanno solo caratteristiche positive.
Come confermato dal forum uciale e non uciale, sono presenti molti bug,
distribuiti in maniera abbastanza omogenea, alcuni di questi di lieve entità, altri clamorosi.
Per fare un esempio di bug di entità rilevante, le funzioni collegate a un evento
generato dall'interazione dell'utente con un componente graco talvolta, non
vengono eseguiti come l'utente si aspetterebbe, se non addirittura ignorati.
Un altro aspetto molto carente dei prodotti Windev è costituito dalla documentazione, inadeguata e a volte assente: funzioni molto importanti fornite dal
IDE, che meriterebbero un approfondimento dettagliato e degli esempi di utilizzo, sono riassunte in poche righe, costringendo l'utente a sperimentarne lui
stesso le modalità di utilizzo.
Tutto questo comporta un iniziale dispendio di tempo ed energie da parte
dell'utente per cercare una soluzione alternativa alle sue esigenze.
31
CAPITOLO 3.
STAGE
3.4 Progettazione
Nonostante le modiche apportate agli obiettivi di progetto in fase di studio di
fattibilità, la progettazione dell'applicazione WalkingPH è stata svolta coerentemente con quanto preventivato nel piano di lavoro; ciò signica che le attività
relative alla progettazione sono state da me svolte rispettando un programma
diviso 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 modo
da avere una struttura il più simile possibile a quella di Planet Hotel ma non
necessariamente identica.
Infatti nel database mobile ci sono due tipi di tabelle caratterizzate dall'uso che
ne fa l'applicazione mobile.
Tabelle Consultate
Le tabelle consultate contengono tutti i dati che l'applicazione necessita per la
costruzione di un contesto nel quale l'utente andrà ad operare.
Queste tabelle non sono necessariamente di struttura identica a quella usata
nel database di Planet Hotel, infatti essendo suciente una sincronizzazione
unidirezionale proveniente dal database consolidato, essa può avvenire tramite
l'ausilio di viste speciche riguardanti solo le informazioni necessarie all'applicazione, in maniera tale da non appesantire la trasmissioni di dati durante la
sincronizzazione con informazioni superue.
Dato il numero considerevole di tabelle di questa tipologia è stata eettuata un
ulteriore suddivisione logica di queste in due componenti, in base all'ambito di
utilizzo:
• Anagraca clienti e prenotazioni
alle quali appartengono tutte le
tabelle che registrano i dati anagraci dei clienti e suddividono questi
a seconda della tipologia di prenotazione eettuata.
•
Le tabelle relative alla
gestione dei listini dei punti vendita, le quali
organizzano le informazioni sugli articoli presenti nei punti vendita e le
caratteristiche ad essi collegate.
Tabelle Modicate
Le tabelle che appartengono a questa categoria sono soggette a operazioni di inserimento, modica e cancellazione durante l'esecuzione dell'applicazione WalkingPH, proprio per questo mantengono la stessa struttura del database consolidato.
Una tabella degna di nota è quella denominata System, al cui interno è presente un solo record contenente tutti i parametri di sistema dell'applicazione,
comprese le informazioni relative allo stato dell'applicazione durante il precedente utilizzo, in modo da non richiedere l'utente di denire ad ogni avvio il
contesto nel quale opera (potrà cambiarlo in qualsiasi momento successivamente
all'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 listini
le cui tabelle appartengono alla categoria Consultate.
Infatti alla selezione del punto vendita desiderato l'applicazione deve poter caricare l'intero listino ad esso collegato, comprensivo delle caratteristiche degli
articoli 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 oerte del giorno (tabella Menu_del_ giorno),
•
la categoria di cui fa parte l'articolo (chiamata Portata) e il colore a
questa associato.
Come risulta chiaro a una prima visione, il nome dato alle tabelle è dovuto
alla precedente destinazione di gestione ristorante, poi generalizzata in punto
vendita 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 conoscenze
acquisite durante lo studio delle altre applicazioni CRM nella fase di studio del
dominio, mi è stato possibile suddividere l'applicazione in moduli aventi speciche funzionalità e il più possibile indipendenti l'uno dall'altro; i diagrammi
usati per descrivere la struttura dei moduli software e formalizzarne le funzionalità sono i diagrammi casi d'uso (use-case diagrams ), appartenenti al linguaggio di modellazione UML. I moduli software di cui è composta l'applicazione
WalkingPH sono:
1.
Autenticazione: gestisce l'identicazione e l'accesso di un operatore.
2.
Schermata Principale: visualizza e permette la modica del contesto.
3.
Utilities: modulo per la modica dei parametri dell'applicazione e strumenti per l'amministratore.
4.
Risorse: visualizza lo stato delle risorse e l'accesso agli ordini ad esse
collegate.
5.
Gestione ordine: permette la gestione delle ordinazioni di un cliente, ed
è diviso in tre sotto-moduli
• Tab Comanda,
• Tab Conto,
per gestire l'inserimento degli articoli.
per la modica e il riepilogo delle ordinazioni.
• Tab Cliente,
permette la ricerca e selezione di un cliente dall'ana-
graca per collegarlo all'ordine corrente.
6.
Agenda: modulo per il CRM delle strutture wellness.
35
CAPITOLO 3.
STAGE
Di tutte questi moduli sono stati deniti i casi d'uso attraverso gli appositi use-
case diagrams integrati durante la stesura della documentazione relativa alla
fase di progettazione.
Il modulo per la gestione ordine
Questo modulo software è il importante e complesso tra i sei, infatti è il vero e
proprio nucleo polivalente nella gestione delle vendite; il modulo della gestione
ordini è a sua volta suddiviso in in tre tab distinte ma attive contemporaneamente e aggiornate in tempo reale poiché condividono gli stessi dati.
Nelle
sezioni successive la relazione procede con l'esposizione dei formalismi usati per
la denizione dei casi d'uso e delle funzionalità proprie delle due tab di maggior
rilevanza 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 denito 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 vendita
di 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 riepilogo
e di modica o eliminazione di singoli dettagli d'ordine.
Funzionalità di base:
•
Visualizzazione e modica dell'intero ordine.
•
Visualizzazione e modica della comanda corrente.
•
Inserimento di un messaggio in testa alla comanda corrente.
•
Salvataggio della comanda corrente e delle modiche 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 classicati i requisiti relativi ai moduli software e alle loro funzionalità. Per quanto riguarda la classicazione dei requisiti
è stato utilizzata la seguente codica per identicare il requisito.
•
Il codice che identica ogni requisito avrà come prima lettera la lettera
R maiuscola, per non confondere il requisito con il codice dei vincoli che
iniziano 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 identicativo del requisito consiste in un numero
decimale con la classicazione decima Dewey (DDC) la quale utilizza serie
di numeri interi positivi, separati da un punto, che indicano il contesto di
appartenenza del requisito secondo una classicazione 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, fatta
eccezione per il modulo ordini, nel quale la cifra indica la tab di
appartenenza del requisito.
3. Qualora fosse presente una terza cifra, signica che il requisito in realtà è un sotto-requisito, il quale deve essere soddisfatto achè il requisito associato (indicato dal secondo numero) possa essere anch'esso
soddisfatto (secondo la scala gerarchica).
I requisiti riportati non sono stati deniti 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-
Immissione di nome utente e password dell'opera-
eratore
tore negli appositi campi graci e verica della loro
corrispondenza
RSf_1.2
Autenticazione am-
Verica della corrispondenza della password dell'am-
ministratore
ministratore, per l'accesso agli strumenti del modulo
Utilities
RPf_1.3
Identicazione
Lettura delle informazioni sull'operatore da database
tipologia operatore
e determinazione della categoria di appartenenza
Tabella 3.2: tabella dei requisiti del modulo di autenticazione
Schermata principale
Codice
Nome
Descrizione
RPf_2.1
Selezione contesto
Funzionalità
di
modica
del
contesto
nel
quale
l'operatore utilizza il dispositivo mobile
RPf_2.1.1
Selezione
punto
vendita
Selezione per mezzo di combobox del punto vendita e della cassa ad esso collegata, tra quelli presenti nel database mobile. Questo determinerà il listino da caricare in memoria qualora la selezione fosse
confermata
RPf_2.1.2
Selezione sala
Selezione attraverso combobox dello stabile e della
sala a cui si fa riferimento per il caricamento delle
risorse
RSq_2.1.3
Selezione in memo-
Preselezione del punto vendita, della cassa, della sala
ria
e dello stabile in base allo stato dell'applicazione o
alle selezioni salvate in precedenza
RPf_2.2
RPf_2.3
Caricamento
Funzionalità di caricamento in memoria del listino
contesto
del punto vendita e delle risorse della sala
Chisura sessione
Funzionalità
di
chiusura
della
sessione,
de-
allocazione del listino del punto vendita, e ritorno
alla schermata di autenticazione
RPq_2.4
Visualizzazione del-
Visualizzazione attraverso una forma tabulare delle
lo stato
informazioni
relative
allo
stato
e
al
contesto
dell'applicazione
RPf_2.5
Accesso a Risorse
Nel caso in cui l'operatore che ha eettuato l'accesso fosse un cameriere o un commesso, sarà possibile accedere al modulo riguardante la gestione delle
risorse
continua nella pagina successiva
39
CAPITOLO 3.
STAGE
Tabella 3.3 continua dalla pagina precendente
Codice
RSf_2.6
Nome
Descrizione
Accesso ad Agenda
Nel caso in cui l'operatore che ha eettuato l'accesso
fosse un massaggiatore di un centro benessere, sarà
possibile accedere al modulo riguardante la gestione
dell'agenda.
Tabella 3.3: Tabella dei requisiti del modulo relativo alla schermata
principale
Utilities
Codice
Nome
Descrizione
RSf_3.1
Gestione dispositivi
Funzionalità di gestione dei dispositivi per la stampa
di stampa
di report e un test per la verica del funzionamento
di questi
RSf_3.2
Test di connessione
Eettua un test delle funzionalità di collegamento
con le risorse di rete.
RSf_3.3
Avvio
Avvio delle operazioni per la sincronizzazione unidi-
sincronizzazione
rezionale dal database consolidato verso il database
mobile
RSq_3.4
Impostazioni
Form graca per l'inserimento e la modica dei
dell'applicazione
parametri di funzionamento dell'applicazione.
tra
cui l'identicativo del database subscriber, l'identicatore relativo al terminale e l'indirizzo IP relativo
al terminale usato.
Tabella 3.4: Tabella dei requisiti del modulo Utilities
Risorse
Codice
Nome
RPq_4.1
Visualizzazione del-
Descrizione
Visualizzazione graca attraverso un looper
lo stato delle risorse
risorse presenti in una sala e del loro stato mediante
delle
la colorazione dell'area ad esse assegnata
RPf_4.2
Accesso a un ordine
Selezione della risorsa e gestione dell'accesso al-
aperto
l'ordine
collegato
a
una risorsa
aperto
ad
essa
collegato,
e
la
modica
di quest'ultimo attraverso le funzionalità messe a
disposizione dal modulo software di gestione degli
ordini
RPf_4.3
Accesso
ad
anagraca camere
Visualizzazione per mezzo di un looper delle camere
dell'hotel con una prenotazione attiva
continua nella pagina successiva
40
3.4.
PROGETTAZIONE
Tabella 3.5 continua dalla pagina precendente
Codice
RPf_4.3.1
RPf_4.4
Nome
Selezione
Descrizione
dei
resi-
Visualizzazione sotto forma di lista e selezione dei
denti di una camera
residenti di una camera
Accesso
Visualizzazione e selezione per mezzo di un looper
ad
graca
ana-
passanti
dei passanti esterni aventi una prenotazione attiva
esterni
RSf_4.5
RPf_4.6
Accesso
ad
Visualizzazione e selezione per mezzo di un looper
anagraca
delle prenotazioni eseguite per conto di membri del
personale
personale della struttura alberghiera
Eliminazione di un
Esecuzione
ordine
nazione degli oggetti e dei record nel database mobile
delle
operazioni
necessarie
all'elimi-
relativi all'ordine da eliminare
RPf_4.7
Creazione
di
un
nuovo ordine
Esecuzione delle operazioni di creazione di un nuovo ordine, comprendenti la costruzione dei relativi
oggetti e della registrazione degli appositi record
all'interno della tabella Ordine del database mobile
ROf_4.8
RSq_4.9
Divisione di un or-
Strumento per la divisione dell'ordine in sotto-ordini
dine
per l'addebito su conti cliente separati
Salvataggio
emergenza
di
Meccanismo di protezione dei dati per il salvataggio
dello
dello stato degli ordini, atto alla prevenzione della
stato degli ordini
perdita di dati.
Questo meccanismo viene attivato
in caso si verichino situazioni di emergenza (carica
della batteria insuciente
Tabella 3.5: Tabella dei requisiti del modulo Risorse
Gestione ordine
Codice
Nome
Descrizione
Requisiti della Tab Comanda
RPf_5.1.1
Selezione di un arti-
Navigazione dell'operatore attraverso due liste di-
colo
namiche, la prima riguardante le categorie di articoli, la seconda contenente gli articoli relativi alla
categoria selezionata nella prima lista
RPf_5.1.2
Determinazione
Selezione veloce o manuale della numero di unità
quantità
dell'articolo
selezionato
dovranno
comparire
nel
dettaglio d'ordine
RSf_5.1.3
Gestione delle vari-
Funzionalità di gestione delle modiche aggiuntive
anti (Ristorante)
o negative riguardanti gli ingredienti usati per la
preparazione di un articolo nel caso di un punto
vendita ristorante
RPf_5.1.4
Immissione di note
Possibilità di collegare all'articolo delle note che lo
ad un articolo
riguardano
continua nella pagina successiva
41
CAPITOLO 3.
STAGE
Tabella 3.6 continua dalla pagina precendente
Codice
RSf_5.1.5
Nome
Inserimento
Descrizione
di
un
Funzionalità che permette all'operatore di inserire
articolo fuori listino
un articolo non presente a listino nella comanda,
indicandone la descrizione, il prezzo e la quantità
desiderata
RSq_5.1.6
Ricerca di un arti-
Ricerca di un articolo nel listino attraverso l'utiliz-
colo
zo di una stringa e visualizzazione e selezione dei
risultati
Requisiti della Tab Conto
RSf_5.2.1
Collegare
un
saggio
una
a
mes-
Funzionalità di inserimento di un messaggio in tes-
co-
ta alla comanda, utilizzato internamente al punto
manda
RSf_5.2.2
RSf_5.2.3
Lista
vendita, per comunicare situazioni particolari
ultimi
Visualizzazione dei dettagli d'ordine inseriti nella
dettagli ordine in-
nuova comanda, ma non ancora scritti all'interno del
seriti
database mobile
Lista
degli
dei
dettagli
Visualizzazione dei dettagli d'ordine inseriti all'inter-
ordine di un ordine
no di un ordine, comprensivi dei dettagli della nuova
comanda, non ancora scritti all'interno del database
mobile
RPf_5.2.4
Modica di un det-
Funzionalità di modica della quantità, dell'ordine
taglio ordine
di uscita o eliminazione di un dettaglio d'ordine
selezionato dalla lista di riepilogo
RSq_5.2.5
Lista di raggruppa-
Visualizzazione sotto forma di lista degli articoli pre-
mento degli articoli
senti nell'ordine, comprensivi di quantità e di prezzo
(la selezione non è abilitata)
RSq_5.2.6
Lista di raggruppa-
Visualizzazione sotto forma di lista delle categorie
mento
degli articoli presenti nell'ordine,
degli
cate-
gorie
comprensive di
quantità (la selezione non è abilitata)
Requisiti della Tab Cliente
RSq_5.3.1
Visualizzazione
Popolamento di una struttura graca tabulare con-
delle
tenente le informazioni organizzate relative a un
informazioni
del cliente
RSf_5.3.2
cliente
Collegamento di un
Accesso alle funzionalità di ricerca di un cliente e
cliente
gestione del risultato da esse restituito
all'ordine
corrente
RSf_5.3.3
Ricerca e selezione
Ricerca
da
stringa, secondo diverse modalità, visualizzazione
residenti
nelle
camere
di
un
residente
attraverso
l'uso
di
una
del risultato di ricerca (con tipo di arrangiamento e
camera di appartenenza) e selezione del nominativo
RSf_5.3.4
Ricerca e selezione
Ricerca di un passante esterno attraverso l'uso di una
da
stringa, secondo diverse modalità, visualizzazione del
prenotazioni
passanti esterni
RSf_5.3.5
risultato di ricerca e selezione del nominativo
Ricerca e selezione
Ricerca di un cliente attraverso l'uso di una stringa,
di
secondo diverse modalità, visualizzazione dei clienti
un
cliente
da
anagraca soggetti
trovati e selezione del nominativo
continua nella pagina successiva
42
3.4.
PROGETTAZIONE
Tabella 3.6 continua dalla pagina precendente
Codice
Nome
Descrizione
RSp_5.3.6
Ricerca in anagra-
La ricerca nell'anagraca soggetti deve essere svolta
ca soggetti veloce
in tempi ragionevolemnte brevi, nonostante avvenga
su tabelle contententi migliaia di nominativi
Requisiti Globali
RSf_5.4
Sospensione di una
Salvataggio temporaneo del riferimento di una co-
comanda
manda in corso, per riprenderene l'inserimento delle
ordinazioni in un momento successivo
RPf_5.5
Salvataggio
di
Scrittura nel database dei dettagli ordine, attraverso
una
su
query di inserimento, di una nuova comanda
comanda
database mobile
RPf_5.6
Salvataggio
delle
Gestione e registrazione su database delle modiche
su
apportate ad ordinazioni già presenti nel database
modiche
database mobile
mobile,
attraverso l'utilizzo di query
di modica
(Update )
Tabella 3.6: Tabella dei requisiti della gestione ordine
Agenda
Codice
Nome
Descrizione
ROq_6.1
Visualizzazione
Visualizzazione graca degli appuntamenti sotto for-
degli appuntamenti
ma
giornalieri
appuntamenti in funziona della durata
ROf_6.2
Gestione
appunta-
menti
ROf_6.2.1
ROf_6.2.2
ROf_6.2.3
ROp_6.3
Modica
di
calendario,
Funzionalità
per
con
la
la
rappresentazione
gestione
degli
degli
appuntamenti
presenti nel programma giornaliero
appunta-
Modica di un appuntamento esistente all'interno del
mento
programma giornaliero
Creazione appunta-
Inserimento di un nuovo appuntamento all'interno
mento
del programma giornaliero
Eliminazione
Eliminazione
appuntamento
programma e notica
Ottimizzazione ap-
Riorganizzazione degli appuntamenti in seguito a
puntamenti
modiche del programma giornaliero e notica.
di
un
appuntamento
Tabella 3.7: Tabella dei requisiti del modulo Agenda
43
esistente
dal
CAPITOLO 3.
STAGE
3.4.4 Struttura e diagrammi delle classi
Essendo Windev Mobile 16 un ambiente di sviluppo che integra strumenti di
tipo CASE, permette una netta divisione dell'applicazione secondo il pattern architetturale MVC; proprio per questo il diagramma delle classi riguarda solo la
struttura della parte Model, mentre sia la parte View che la parte Control vengono denite attraverso l'utilizzo degli specici strumenti CASE forniti nell'IDE
di 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 query
sul database mobile, soprattutto quando queste coinvolgevano tabelle contenenti
un numero considerevole di record; tutto ciò provocava un tempo d'attesa tale
da intaccare l'usabilità dell'applicazione.
Data l'impossibilità di ottimizzare in misura rilevante le query, l'unica soluzione
possibile a questo problema non poteva essere che il caricamento nella memoria
principale del dispositivo, le informazioni contenute nel database sotto forma di
oggetti, e le relazioni attraverso puntatori agli oggetti stessi.
Per rendere questo possibile è stato necessario denire la struttura delle classi
in 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 progettazione
del database mobile), una volta caricati i relativi oggetti in memoria, non
ci sarebbe stato bisogno di accedere nuovamente al database mobile.
•
Nel caso invece delle tabelle Modicabili è stato necessario un caricamento iniziale delle informazioni, dopo il quale è stato gestito una sorta di
aggiornamento parallelo tra gli oggetti in RAM e le informazioni presenti
nelle tabelle del database mobile, posticipando l'esecuzione delle funzioni
di aggiornamento del database ai momenti di inattività dell'applicazione
(sempre per non inuire sull'usabilità, essendo dispendiose in termini di
tempo e risorse).
L'architettura delle classi
Come per il database, anche nell'architettura delle classi è possibile individuare
elementi tali da raggruppare le classi dell'applicazione in componenti speciche
al 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 tutte
le informazioni contenute nella parte Model e la cui costruzione è gestita
nelle modalità denite dal pattern Singleton.
•
•
Le classi dedicate all'organizzazione del
Listino del punto vendita.
La gerarchia delle classi per la distinzione delle tipologie di
relative informazioni anagrache.
44
Clienti e le
3.4.
•
Le classi per la
PROGETTAZIONE
Gestione degli ordini
Nella sezione successiva tratta nel dettaglio la componente più importante tra
quelle 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 blocchi, riguardante l'organizzazione di un ordine e le sue informazioni identicative
del contesto in cui viene creato.
Come si evince dallo schema ogni oggetto della classe Ordine per esistere deve
obbligatoriamente appartenere a un contesto specico identicato attraverso i
relativi 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 oggetto
di classe
•
Operatore.
L'ordine deve essere collegabile ad una
Cassa, la quale è associata ad un
oggetto 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 dedicato
relativo nell'oggetto Ordine.
45
CAPITOLO 3.
STAGE
3. I singoli oggetti della classe DettaglioOrdine opportunamente contenuti in un vettore della relativa classe Comanda.
Per rendere più facile l'accesso agli oggetti di livello superiore, ogni oggetto
di livello inferiore possiede un riferimento all'oggetto che lo contiene (un oggetto
di 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 entrambe
le architetture, quella del database mobile con quella degli oggetti caricati in
memoria.
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 fase
di sviluppo dell'applicazione WalkingPH, prestando attenzione a descrivere gli
aspetti 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 sono
state generate le classi relative alla parte Model dell'applicazione, opportunamente formalizzate durante la progettazione attraverso gli strumenti UML messi
a disposizione da Windev Mobile.
Successivamente ho provveduto nell'importazione dei dati provenienti da un
database di Planet Hotel di prova, talvolta per mezzo dell'utilizzo dello strumento di conversione fornito dall'IDE, in altre occasioni attraverso delle query
predenite, richiamate da funzioni di popolamento appositamente scritte.
Il caricamento dei dati
Una volta popolate le più importanti tabelle del database mobile è stato necessario procedere nella denizione dei metodi interni alle classi deniti builder,
i quali invocati da un oggetto padre, provvedono alla creazione di tutti gli
oggetti ad esso collegati per mezzo dell'esecuzione di query di selezione; ciò ha
permesso il caricamento in memoria principale dei dati presenti nel database
mobile per mezzo dell'invocazione a cascata di questa tipologia di metodi (invocati all'interno degli stessi costruttori).
L'invocazione a cascata dei metodi builder comportava l'esecuzione massiccia di
query di selezione nel database mobile, occupando per circa un minuto le risorse
del dispositivo mobile; l'accesso e l'elaborazione dei dati sotto forma di oggetti
risulta istantaneo, dopo il caricamento di questi in memoria principale.
Questo metodo è stato un compromesso adottato in funzione dell'usabilità dell'applicazione a fronte dell'occupazione della memoria RAM (circa il 60%) e del
attesa iniziale (il caricamento dati avviene una volta eettuato l'accesso).
Un aspetto da considerare consiste nel caricamento del listino del punto vendita, per impedire l'occupazione totale della memoria principale e un tempo di
attesa prolungato nella fase di caricamento, è stato deciso di caricare un solo
listino per volta e che, nel caso di un cambiamento del punto vendita, il vecchio
oggetto 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 disposizione da Windev, la creazione delle form grache è risultata semplice e
immediata, ciò nonostante nell'approccio allo sviluppo di un nuovo modulo software, prima dell'inizio delle iterazioni del cosiddetto ciclo dei prototipi, è stato
necessario compiere delle operazioni preliminari:
•
Presenza e coerenza nel database mobile dei dati necessari al funzionamento del nuovo modulo.
48
3.5.
•
SVILUPPO
Verica del corretto funzionamento dei metodi usati per il caricamento dei
dati in memoria.
•
Sperimentazione del funzionamento dei nuovi componenti graci che dovranno essere presenti nell'interfaccia graca, soprattutto riguardo la gestione
degli eventi a questi collegati.
Una volta compiute queste veriche sono stato in grado di proseguire nello
sviluppo dei prototipi secondo quanto previsto dalla tecnica RAD, integrando
nel modulo o nella form graca una funzionalità aggiuntiva e vericandone il
funzionamento attraverso l'esecuzione iterativa delle seguenti operazioni.
1. Denizione delle operazioni che la funzione deve eseguire e gli oggetti da
coinvolgere.
2. Scrittura del codice della funzione in WLanguage secondo quanto denito.
3. Inserimento della chiamata alla funzione nella posizione opportuna nel
codice della componente.
4. Compilare il progetto e correggere eventuali errori.
5. L'esecuzione della funzionalità aggiunta e vericarne il funzionamento con
gli strumenti di debug.
Grazie alla creazione iterativa di prototipi il tutor aziendale poteva visionare
in 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 graca
Figura 3.17: Form grache relative all'autenticazione, la schermata principale e
la selezione del contesto
Lo stile usato nelle interfacce grache delle nestre che compongono l'applicazione mobile sono state studiate in modo da consentire all'utente un'interazione con l'applicazione semplice e immediata.
49
CAPITOLO 3.
STAGE
L'utilizzo di eetti graci è pressoché assente, prediligendo l'usabilità all'estetica; questa scelta è stata fatta in base all'esigenza di avere un'applicazione usabile
e veloce, e che non sprecasse risorse in operazioni considerate inutili dal punto
di vista delle prestazioni.
Durante il caricamento dei dati l'utente viene informato dello stato di avanzamento attraverso la visualizzazione nella struttura delle classi in corso di
creazione e una barra di progresso percentuale; lo stesso vale per le situazioni in
cui i dati vengono salvati nel database attraverso query, durante le quali appare
all'utente una nestra di attesa con le informazioni sull'operazione in corso.
Dalle immagini di esempio è possibile notare che la dimensione dei componenti
graci interattivi, questi sono grandi e il testo al loro interno è ben leggibile;
inoltre la disposizione e le funzioni collegate ai bottoni permettono una selezione
rapida delle funzioni tipiche di un punto vendita, secondo i meccanismi studiati
durante l'analisi del dominio.
Un altro aspetto non di poco conto da tenere in considerazione durante la
creazione delle interfacce grache è stato la comparsa della tastiera a schermo ogni qualvolta l'utente accedeva a un oggetto graco di tipo editbox, tastiera
la cui è tale da occupare la parte del settore inferiore dello schermo tattile; per
questo motivo tutte gli oggetti graci per l'inserimento di testo sono stati posizionati nel settore superiore, in modo tale da dare modo all'utente di vedere
ciò 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 e
cliente
Il più complesso modulo da realizzare è stato sicuramente il modulo software
relativo alla gestione ordine. Questo modulo ha comportato uno sforzo notevole
dello sviluppo delle funzioni interne al modulo, in modo da mantenere in uno
stato coerente degli oggetti temporanei e condivisi dalle tre tab di cui è composto
il modulo, anche nel nel caso di un ritorno alla form Risorse (azione permessa
all'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 non
previste dalla progettazione; infatti era stato pensato che al momento di uscita
dal modulo di gestione ordine, le comande non inviate al database dovessero
essere cancellate. Nelle seguenti sezioni sono arontate 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, avete
al suo interno il puntatore a un oggetto ArticoloPV, una quantità e uscita ben
denite (insieme ai riferimenti agli oggetti contenenti le informazioni relative
all'operatore e al contesto in cui l'applicazione opera).
La raccolta di dati per la creazione di un dettaglio d'ordine deve avvenire
attraverso 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 (risultato 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 volta
determinato in modo univoco l'articolo sta all'utente determinarne:
quantità, di default impostata a una unita.
•
La
•
L'inserimento facoltativo di eventuali
note (selezionando tra le note pre-
denite o inserendole manualmente).
•
La sequenza di
uscita (da selezionare manualmente perché senza valore
predenito).
Se durante la selezione di questi parametri l'utente selezionasse un articolo diverso o una categoria dalle apposite liste, verrà chiamata una funzione che eettua
il ritorno al valore predenito della quantità e delle note, la deselezione dell'uscita e la cancellazione delle varianti temporaneamente memorizzate; naturalmente
questa procedura viene eseguita anche dopo la creazione e l'inserimento nella
comanda dell'oggetto rappresentante il dettaglio d'ordine, in modo da impedire
che i parametri precedenti inuiscano della creazione di un nuovo dettaglio d'ordine.
Un altro aspetto degno di nota relativo a questa nestra graca consiste nel ridimensionamento orizzontale delle listbox, per la selezione delle categorie e degli
articoli, come si può notare dalle immagini l'espansione avviene per la lista in
cui viene selezionato un elemento.
Lo sviluppo della tab Conto
Figura 3.21: Tre schermate della tab conto: ultima comanda, ordine intero e
riepilogo articoli di varianti
Quest'interfaccia graca ha il compito di riepilogare all'operatore lo stato
degli articoli inseriti, secondo 4 tipologie di visualizzazione, selezionabili con gli
appositi 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.
• COMP.,
SVILUPPO
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 contengono, partendo da sinistra, informazioni relative alla quantità, il nome dell'articolo, la sequenza di uscita e il prezzo unitario.
Tra questi riepiloghi sotto forma di tabella solo nei primi due casi è attivata
la selezione del dettaglio d'ordine, essendo possibile apportare modiche della
quantità e dell'ordine di uscita, o deciderne l'eliminazione (è consentita anche
l'eliminazione delle note e delle varianti relative al singolo dettaglio).
Durante la modica dei dettagli d'ordine già presenti nel database mobile avviene
la memorizzazione dei puntatori agli oggetti coinvolti nella modica per mezzo di una lista, anché possano essere modicati anche i rispettivi record nel
database al momento del ritorno alla nestra delle Risorse e accorpata all'eventuale inserimento nella base dati della nuova comanda (operazione posticipata
perché possibilmente dispendiosa in termini di tempo).
3.5.5 Funzionalità di salvataggio di emergenza
Un'altra importante funzionalità inizialmente non prevista in fase di progettazione, ma implementata in fase di sviluppo è stata la funzionalità di salvataggio di emergenza collegata al modulo software Risorse dell'applicazione WalkingPH.
L'idea iniziale di questa funzionalità è sorta in seguito alla possibilità di sospensione e ripristino dello stato di una comanda; l'eventualità di avere una comanda
sospesa in concomitanza con una situazione imprevista o inevitabile, avrebbe
portato a un'irrimediabile perdita di dati (ad esempio un errore di sistema o
l'imminente spegnimento del dispositivo causato da una carica insuciente all'interno della batteria).
Per evitare tutto ciò è stata creata una funzione che al momento dell'invocazione
precede con una scansione degli ordini aperti e quando rileva una comanda
sospesa ne scrive i relativi dettagli d'ordine nel database mobile, marcandoli
con apposito un ag che li identica come sospesi.
Al momento del ripristino dello stato di esecuzione dell'applicazione i dettagli
d'ordine sospesi verranno ripristinati e successivamente cancellati dal database.
L'invocazione di tale funzione è adata alla gestione delle eccezioni ed errori di
Windev, e ad un thread, interno alla form Risorse, che periodicamente richiama
una funzione di sistema per la valutazione del livello di batteria del dispositivo.
3.5.6 Dicoltà riscontrate
Durante lo sviluppo non sono state riscontrate dicoltà insormontabili proprio
grazie al minuzioso lavoro svolto nelle fasi di studio di fattibilità e di progettazione.
Il fatto di usare Windev Mobile con l'ottica di trovare possibili complicazioni
(descritte nel paragrafo problemi riscontrati) mi ha fatto ragionare ponendo
attenzione alle possibili soluzioni alternative, discutendole con il tutor aziendale.
Un altro aspetto che mi ha creato qualche dicoltà sta nel fatto che l'approccio
53
CAPITOLO 3.
STAGE
a un IDE, per me nuovo, come autodidatta e senza personale esperto in azienda a cui sottoporre eventuali problemi, non è stato dei migliori, e l'inadeguata
documentazione relativa all'ambiente di sviluppo fornita da PCSoft, non ha di
certo aiutato.
Se al momento dell'inizio dello sviluppo avessi avuto le conoscenze sinora acquisite, avrei sicuramente potuto procedere in maniera più rapida ed eciente
nella realizzazione dell'applicazione.
Ciò nonostante posso dirmi soddisfatto del risultato ottenuto nello svolgimento
di quest'ultima fase del progetto.
54
Capitolo
4
Valutazione retrospettiva
In questo quarto e ultimo capitolo sono state riportate le valutazioni e le considerazioni, successive alla conclusione dell'attività di stage, in merito al completamento degli obiettivi pressati e dal punto di vista della crescita personale
e professionale maturata da questa esperienza.
4.1 Soddisfacimento dei requisiti
Come già spiegato nella sezione riguardante lo studio di fattibilità, durante lo
svolgimento delle attività lavorative, c'è stato un ridimensionamento degli obiettivi del progetto di stage; alla luce della complessità e importanza dell'aspetto
di sincronizzazione tra database attraverso un'applicazione ponte, la quale,
secondo le valutazioni mie e del tutor aziendale, avrebbe richiesto uno sforzo
tale da poter essere considerato come unico obiettivo di progetto per un ulteriore stage.
Il progetto di stage si è quindi trasformato nella realizzazione dell'applicazione
mobile WalkingPH integrante la gestione delle vendite, e predisposta sia alla
sincronizzazione che alla successiva integrazione con un modulo CRM relativo
alla gestione dell'agenda.
Il processo di sviluppo è stato quindi dedicato al completamento della gestione
delle vendite integrata, prediligendo la qualità ed ecienza del software realizzato più che ad un avanzamento forzato nello sviluppo di ulteriori moduli CRM.
Questo approccio è risultato vincente dal punto di vista del soddisfacimento dei
requisiti decretati come primari, poiché essendomi stato permesso di focalizzare la mia attenzione su quelli, ho potuto procedere nello sviluppo in maniera
metodica, tale da poter adempiere al raggiungimento dei requisiti secondari e
qualitativi in tempi contenuti.
Qui di seguito è riportata una tabella contenente i requisiti dichiarati in fase di
progettazione 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
Identicazione 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
RSf_3.1
Gestione dispositivi di stampa
30%
RSf_3.2
Test di connessione
20%
RSf_3.3
Avvio sincronizzazione
RSq_3.4
Impostazioni dell'applicazione
RPq_4.1
Visualizzazione dello stato delle risorse
RPf_4.2
Accesso a un ordine aperto collegato a una risorsa
100%
RPf_4.3
Accesso ad anagraca camere
100%
RPf_4.3.1
Selezione dei residenti di una camera
100%
RPf_4.4
Accesso ad anagraca passanti esterni
100%
RSf_4.5
Accesso ad anagraca 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
RSq_4.9
Salvataggio di emergenza dello stato degli ordini
0%
Utilities
0%
100%
Risorse
80%
20%
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
RSq_5.1.6
Ricerca di un articolo
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
70%
100%
Requisiti della Tab Conto
100%
continua nella pagina successiva
56
4.1.
SODDISFACIMENTO DEI REQUISITI
Tabella 4.1 continua dalla pagina precendente
Codice
Nome
Descrizione
RPf_5.2.4
Modica 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%
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 anagraca soggetti
100%
RSp_5.3.6
Ricerca in anagraca soggetti veloce
RSf_5.4
Sospensione di una comanda
100%
RPf_5.5
Salvataggio di una comanda su database mobile
100%
RPf_5.6
Salvataggio delle modiche su database mobile
100%
ROq_6.1
Visualizzazione degli appuntamenti giornalieri
0%
ROf_6.2
Gestione appuntamenti
0%
ROf_6.2.1
Modica appuntamento
0%
ROf_6.2.2
Creazione appuntamento
0%
ROf_6.2.3
Eliminazione appuntamento
0%
ROp_6.3
Ottimizzazione appuntamenti
0%
Requisiti della Tab Cliente
90%
Requisiti Globali
Agenda
Tabella 4.1:
Tabella dell'avanzamento nei requisiti dell'appli-
cazione
Come risulta chiaro dalla tabella relativa all'avanzamento nei requisiti, durante lo sviluppo mi è stato possibile raggiungere nella quasi totalità i requisiti
considerati primari, eccezione fatta per il visualizzazione delle risorse tuttora
incompleta nell'implementazione di alcune caratteristiche.
Per quanto riguarda il raggiungimento dei requisiti secondari c'è da registrare il
mancato completamento delle funzionalità di controllo dei dispositivi di stampa e della connessione con la rete aziendale nel modulo Utilities ; mentre per
quanto concerne il modulo per la gestione ordine la funzionalità di inserimento
in comanda di un articolo fuori listino sono state riscontrate alcune dicoltà
nella logica di associazione del nuovo articolo a una destinazione di stampa.
Purtroppo il tempo concesso dallo stage non è stato suciente per la realizzazione del modulo software della gestione dell'agenda e dei requisiti a questo
collegati, che in previsione di ciò erano già stati considerati come opzionali.
57
CAPITOLO 4.
VALUTAZIONE RETROSPETTIVA
4.2 Divario conoscitivo
Le conoscenze in mio possesso acquisite durante il corso di laurea triennale sono
state adeguate, se non indispensabili, allo svolgimento dell'attività di stage. Le
nozioni acquisite durante il corso e il progetto di ingegneria del software sono
state fondamentali nella fase di studio di fattibilità, ma ancora di più nell'attività di progettazione; senza tali nozioni non avrei sicuramente saputo procedere
nella progettazione in maniera così metodica.
Un altro aspetto fondamentale per questa tipologia di applicazione è stato lo
studio degli algoritmi da utilizzare per ottenere un risultato sperato nella miglior
ecienza possibile, e tutto questo grazie alle conoscenze acquisite nel corso di
algoritmi 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 insucienti 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 durante
tale corso di laurea mi è stato di grande aiuto nella comprensione e interazione
col database di Planet Hotel.
Purtroppo sono sorte alcune dicoltà a causa della mancanza di alcune nozioni
sull'ottimizzazione delle query, dato che nello sviluppo di applicazioni gestionali
è consueto un utilizzo intensivo delle basi dati e dell'enorme mole di dati che
queste contengono, soprattutto in ambito CRM nel quale l'applicazione è orientata all'acquisizione della maggior quantità di informazioni possibile riguardanti
il cliente; tale problema viene amplicato se l'applicazione atta a eseguire tali
query risulta essere un'applicazione per dispositivi mobile, aventi una potenza
di 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 manipolazione di database sino ad allora per me sconosciuti e di tecnologie di cui
in precedenza avevo sentito solo parlare, come ODBC e la sincronizzazione tra
database.
Dello standard ODBC è stato fatto ampio uso nella fase di studio del database
di Planet Hotel, ed ho imparato a riconoscerne le proprietà e i limiti attraverso
la connessione con altre applicazioni.
Sempre durante la fase di analisi del dominio ho avuto occasione di studiare e
comprendere la struttura e i meccanismi propri di un'applicazione gestionale, in
particolare della struttura di un database che la sopporta.
Attraverso lo studio delle tecnologie di sincronizzazione mi sono reso conto dei
meccanismi e delle problematiche relative a tali tecnologie, e soprattutto la differenza tra le soluzioni proposte dalle dai DBMS di case produttrici dierenti;
purtroppo l'apprendimento di queste tecniche non è stato completo anche a
causa della vastità e della complessità di questo argomento in rapporto al tempo a disposizione.
Dallo studio e utilizzo di applicazioni gestionali ho appresso soprattutto l'aspetto dell'interazione con l'utente in situazioni reali; grazie all'esperienza che il
tutor aziendale ha maturato nel corso di anni dedicati alla creazione di questa
tipologia di applicazioni, ho imparato a ragionare da punto di vista dell'utente
nale del prodotto, ponendomi nell'ottica di realizzare un'applicazione di semplice utilizzo e che potesse soddisfare le esigenze di un addetto ad un punto
vendita.
Grazie alla scelta di Windev Mobile 16 come ambiente di sviluppo integrato, ho
appreso la tecnica di sviluppo RAD supportata dall'utilizzo di strumenti CASE
la quale si è rivelata fondamentale nella realizzazione dell'applicazione, anche
se inizialmente vista con scetticismo poiché diorme dalle tecniche di programmazione da me già sperimentate; testimoni di ciò sono i risultati che ho ottenuto
in termini di soddisfacimento dei requisiti, dicilmente raggiungibili attraverso
la programmazione tradizionale in tempi così brevi.
59
CAPITOLO 4.
VALUTAZIONE RETROSPETTIVA
4.4 Considerazioni personali
Al termine dell'attività di stage presso Sintesi SAS ho potuto fare il punto della
situazione per quanto riguarda il contributo fornitomi da questa esperienza alla
mia crescita professionale e personale.
Riguardo all'aspetto personale ho maturato nel rapporto con il tutor aziendale e coi colleghi, spesso potevano esserci incomprensioni relative ad alcuni
meccanismi o alla poco chiara denizione di alcune funzionalità, ma attraverso un atteggiamento umile e paziente da entrambe le parti, è stato possibile il
mantenimento dello stato di armonia all'interno dell'azienda.
Sotto l'aspetto
professionale ho imparato a mettere da parte le mie scelte di sviluppo dettate
da iniziative personali e, qualora potessero portare ad una maggiore ecienza
o usabilità, sottoponendole e discutendole con il tutor aziendale, di modo da
rendere l'applicazione WalkingPH conforme alle aspettative e allo stile aziendale denito con Planet Hotel. Il fatto di essere stato il solo ad aver seguito la
realizzazione dell'applicazione WalkingPH, in tutte le sue fasi, mi ha permesso
di valutare le mie capacità e mancanze nell'arontare il progetto, oltre al fatto
di rendermi responsabile di un prodotto che sapevo essere soggetto a valutazione
da parte del tutor aziendale, nonché il titolare dell'azienda.
Dopo quanto ho appreso e realizzato durante questa esperienza lavorativa, posso ritenermi soddisfatto di come si è svolto lo stage aziendale e sarei pronto a
ripetere questo tipo di esperienza professionale se me ne capitasse l'occasione.
60
Appendice
A
Windev
Windev è un ambiente di sviluppo integrato (IDE) appartenente alla software
house francese PCSoft, la cui prima versione risale al 1993; tale ambiente di
sviluppo esegue esclusivamente su macchine aventi come sistema operativo Microsoft Windows, nonostante sia possibile il deployment delle applicazioni anche
su 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 facilitare
lo sviluppo di applicazioni gestionali attraverso l'utilizzo di strumenti CASE
integrati, infatti il moto di Windev è Develop ten times faster .
La linea Windev consiste in tre prodotti, dierenziati dalla destinazione delle
applicazioni sviluppate:
• Windev
che consente lo sviluppo di applicazioni destinate a elaboratori
di tipo desktop, o i più recenti dispositivi tablet, aventi come sistema operativo Microsoft Windows oppure una distribuzione di Linux, è prevista
in alternativa la possibilità di creare applicazioni Java eseguibili da una
JVM
• Webdev
consente la creazione di siti e applicazioni web secondo gli stan-
dard deniti 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 realizzazione
di applicazioni destinate a dispositivi mobile come PocketPC o smartphone.
A.1 Le caratteristiche
Le caratteristiche in comune ai tre IDE della linea Windev, che rendono i
questi prodotti validi nella realizzazione di applicazioni gestionali possono essere
riassunti 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 HyperFile
SQL (abbreviato è HFSQL ) ed è disponibile in quattro varianti, a seconda delle
esigenze dell'utente:
•
HFSQL Classic da utilizzare per applicazioni dedicate a dispositivi PC
desktop o a tablet.
•
HFSQL C/S che sta per client e server per applicazioni che utilizzano la
rete per lo scambio di informazioni.
•
HFSQL Cluster, ovvero un database HyperFile SQL con struttura comune,
ma i cui dati sono distribuiti in dierenti aree geograche.
•
HFSQL Mobile per applicazioni realizzate con Windev Mobile, un database
leggero adatto ai dispositivi moble anche non recenti.
Tutte tre le versioni permettono di accedere a database esterni, rendendo
quindi i prodotti della linea Windev estremamente versatili nella realizzazione
di applicazioni nell'ambito gestionale; le modalità di accesso a database esterni
che mettono a disposizione i tre IDE sono i seguenti:
•
Eettuando una connessione al database tramite l'utilizzo dei driver ODBC
specici al DBMS desiderato.
•
Tramite l'utilizzo delle API fornite dallo standard Microsoft OLEDB, via
connessione ODBC, in maniera pratica e senza dover installare ulteriore
software che non siano i driver ODBC del DBMS in oggetto.
•
Utilizzano lo strumento di conversione del database dal quale si accede via
connessione ODBC, in un database di tipo HFSQL (da non considerarsi
come 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 database
mantenendone la struttura).
•
L'ultima e meno economica modalità consiste nell'acquisto di una licenza
di un modulo software aggiuntivo da PCSoft riguardante l'accesso nativo
al DBMS desiderato (opzione dispendiosa in quanto ogni licenza costa
quasi quanto un singolo IDE della linea Windev).
A.1.2 Il WLanguage
I prodotti per lo sviluppo Windev utilizzano di un linguaggio di programmazione
di quarta generazione (4GL) chiamato WLanguage, per la denizione delle classi dell'applicazione e nella codica delle funzioni connesse a un evento generato
da un componente graco.
Tale linguaggio di programmazione permette la chiamata di funzioni anche complesse, come l'avvio di un componente software aggiuntivo (il manager di connessioni a reti wireless) tramite una sintassi semplice ed essenziale. Il WLanguage
permette inoltre la connessione e manipolazione di un database (attraverso le
modalità di accesso precedentemente descritti) e l'esecuzione di query denite
in 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 la
presenza di strumenti integrati ed editor graci di tipo CASE che hanno lo scopo
di facilitare e aiutare l'utente durante lo sviluppo di applicazioni software. Gli
strumenti più importanti forniti dagli IDE sono i seguenti:
•
L'integrazione al loro interno degli strumenti necessari per la progettazione
del software, dai diagrammi UML al deployment.
•
Lo strumento di conversione di progetto dà all'utente la possibilità di
sviluppare l'applicazione con tanto di database annesso per una delle tre
versioni disponibili e importarne tutte le funzionalità in un'altro IDE.
•
Uno strumento che mette in grado l'utente di consultare il contenuto e la
struttura dell'intero database utilizzato nello sviluppo dell'applicazione,
attraverso un ambiente graco integrato chiamato Analysis.
•
Un editor graco per la creazione e il test di query, anche di notevole
complessità.
•
La presenza di un generatore di report integrato del sistema, che permette di organizzare le informazioni da visulizzare in una struttura di tipo
drill-down.
•
Gli strumenti di debug e di riepilogo di esecuzione chiamato Audit, permettono di tenere sotto controllo lo stato delle variabili (anche nel caso
di oggetti) durante l'esecuzione dell'applicazione; inoltre, grazie ad Au-
dit, è possibile visualizzare informazioni aggiuntive e suggerimenti per
l'ottimizzazione dell'applicazione.
•
La presenza della modalità di sviluppo di tipo RAD, la quale crea automaticamente moduli software, comprensivi di interfaccia graca, generati
partendo dalla struttura di una o più tabelle di un database presente nella
sezione Analysis del progetto.
63
APPENDICE A.
WINDEV
64
Appendice
B
Glossario
0-9
4GL Acronimo di fourth-generation programming language che signica linguaggi di programmazione di quarta generazione.
Questa categoria di
linguaggi di programmazione consentono la manipolazione di oggetti o
database relazionali attraverso una sintassi semplice ma inadatti alla descrizione 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 interattive
che sfruttano l'oggetto XMLHttpRequest per lo scambio di dati (asincrono) tra client e server senza dover eettuare il refresh della pagina. I
componenti utilizzati per lo sviluppo di un'applicazione attraverso la tecnica AJAX, possono essere scritti nei seguenti linguaggi: HTML, DOM,
JavaScript e XML
Android è un insieme di componenti software, tra cui un sistema operativo
basato su kernel, dedicato a dispositivi mobile come tablet o smartphone
API l'acronimo sta per Application Programming Interface ovvero l'insieme di
funzioni fornite al programmatore allo scopo di generare una sorta di astrazione rispetto al programma o al sistema a cui appartengono. Attraverso queste funzioni il programmatore può dunque far eseguire operazioni
ad un sistema senza conoscerne la struttura interna, né i meccanismi di
funzionamento.
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 risorsa
appartenente a una struttura alberghiera, sia essa una camera, una sala
convegni o un tavolo nel reparto ristorazione.
Bug Termine gergale informatico usato per indicare un errore logico nella scrittura di codice software, i bug vengono classicati a seconda della loro
gravità, quindi sull'impatto che hanno nell'applicazione.
C
CASE Con strumenti CASE (Computer-aided software engineering ) si intendono gli strumenti che supportano lo sviluppo del software attraverso interfacce grache e librerie di funzionalità e consentono uno sviluppo del
software in modo assistito. Tali sistemi hanno notevolmente semplicato
la scrittura di linee di codice con relativi beneci anche alla conformità
agli standard del software stesso.
Comanda Una comanda è un entità che compone un ordine, la quale raggruppa
gli articoli e la loro quantità (dettagli d'ordine) che un cliente richiede ad
un addetto alla vendita o cameriere. La comanda nasce con l'inserimento
del primo articolo e viene chiusa al momento in cui il cliente congeda
l'addetto alla vendita.
CRM la sigla sta per Customer relationship management, ed è un concetto comune nelle aziende turistiche. Il CRM è l'insieme di operazioni orientate a
ottenere la ducia della clientela, cercando di creare un ambiente familiare
e gradevole. Questo approccio ha lo scopo di attirare nuova clientela ma
soprattutto mantenere saldi i rapporti con i clienti storici oppure importanti. Un esempio di operazioni facenti parte del CRM di un albergo sono
l'invio al cliente di oerte che lo possano interessare tramite newsletter
oppure degli auguri durante le festività.
CSS Il CSS (l'acronimo sta per Cascading Style Sheets ) è un linguaggio utilizzato per la denizione dello stile per la visualizzazione di una pagina
HTML. Anche questo linguaggio come l'HTML è costituito da tag ed è
stato standardizzato dall'ente W3C; la nascita è dovuta alla necessità di
separare i contenuti (presenti nel le HTML) dallo stile di visualizzazione
e formattazione del documento ( descritta nel le CSS).
D
DBMS Un Database Management System è un sistema software che consente
la creazione e la manipolazione di tabelle e record di un database in modo
66
eciente da parte di uno o più utenti anche contemporaneamente.
Es-
istono in commercio molti tipi di DBMS, divisi a seconda della tipologia di
database 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 controlli su porzioni di codice, durante l'esecuzione di un programma, atte
a debellare errori di programmazione.
Uno strumento di debug inoltre
può visualizzare lo stato, e quindi il contenuto, delle variabili coinvolte
nell'esecuzione di un programma.
Deployment operazioni per la adattamento di un software al funzionamento su
un sistema operativo o dispositivo che ne richieda la relativa installazione
e messa in funzione.
Drill-down Tecnica informatica usata per condurre analisi su strutture dati
multi-dimensionali; tale tecnica, appartenente all'ambito del data mining,
permettono l'accesso ai dati a diversi livelli di gerarchia.
F
Form grache Con questo termine si intende un raggruppamento di oggetti
graci, disposti ordinatamente all'interno di un'interfaccia graca fornita
da una applicazione.
H
HTML L'acronimo sta per HyperText Markup Language, è il linguaggio di
markup la cui sintassi è denita dallo standard World Wide Web Consor-
tium (W3C) e viene utilizzato per la creazione di pagine web. Caratteristica principale del linguaggio è l'utilizzo di tag per denire le caratteristiche
degli elementi da visualizzare.
HFSQL L'acronimo signica HyperFile SQL ed è un DBMS proprietario utilizzato dai prodotti della linea Windev (argomento approfondito del paragrafo relativo a Windev).
I
IDE Tradotto in italiano è l'acronimo che identica un ambiente di sviluppo
integrato, che permette ai programmatori di avere tutti gli strumenti necessari alla creazione di software in un unica applicazione. Infatti gli strumenti presenti in un IDE sono: un editor per la scrittura del codice, un
sistema di controllo di versione, un interprete o compilatore e gli strumenti
per eettuare il debug.
67
APPENDICE B.
GLOSSARIO
J
Java Java è un linguaggio di programmazione multipiattaforma orientato agli
oggetti, nato nel 1992. Java è un marchio registrato di Oracle.
JavaScript è un linguaggio di scripting orientato agli oggetti standardizzato
nel 1996 e avente la sintassi simile a quella del linguaggio Java (Sun Microsystems). Questo linguaggio composto da script è spesso utilizzato per
la scrittura di applicazioni Web.
JVM Acronimo che sta per Java Virtual Machine ed è lo strumento appartentente 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 diuso nello
sviluppo di interfacce grache di sistemi software object-oriented.
tale
pattern è basato sulla divisione del software in componenti che coincidono
con:
•
Il model fornisce i metodi per accedere ai dati utili all'applicazione.
•
Il view visualizza i dati contenuti nel model e si occupa dell'interazione con l'utente.
•
Il controller riceve i comandi dell'utente ( attraverso il view) e li attua
modicando lo stato del model e della view.
O
ODBC L'acronimo sta per Open Database Connectivity ed è uno standard
di interfacce software per l'accesso a un DBMS, indipendentemente dal
tipo di DBMS, dal sistema operativo o dal linguaggio di programmazione
utilizzato. L'accesso al DBMS tramite ODBC avviene attraverso un driver
specico a seconda del tipo di DBMS al quale ci si vuole connettere.
OLEDB L'Object Linking and Embedding, Database é un API prodotta da Microsoft che permette l'accesso a risorse eterogenee secondo un approccio
unico, implementato da interfacce standard. Disegnata allo scopo di sostituire ad alto livello l'ODBC, mettendo a disposizione un più vasto insieme
di funzioni atte a gestire non solo basi di dati relazionali ma anche non
relazionali e orientate agli oggetti.
Open source Con open source si intende un software sviluppato da programmatori indipendenti e il cui codice circola liberamente.
68
P
PMS L'acronimo sta per l'espressione anglosassone Property Management System, con la quale si intende un software per la gestione di strutture
nell'ambito alberghiero o turistico.
PocketPC Nome con cui Microsoft identica la propria linea di computer palmari, i PocketPC sono dispositivi dotati di schermo tattile e integrano un
sistema operativo Windows CE o Mobile; spesso integrano al loro interno
funzioni di telefonia cellulare con supporto UMTS e GSM.
R
RAD Acronimo di Rapid Application development, che è una metodologia di
sviluppo di software che permette la generazione rapida di codice partendo
dalla creazione e ridenizione iterativa di prototipi.
Record Nell'ambito dei database, un record è un entità, identicata da una
chiave univoca, che raggruppa delle informazioni presenti all'interno di
una tabella di un database, visualizzabili sotto forma di riga.
Report Nell'ambito dei sistemi informativi, un report informativo consiste in
un documento riassuntivo contenente informazioni in forma tabellare o
schematizzata.
S
SQL SQL è l'acronimo di Structured Query Language ed è un linguaggio di
interrogazione di database basati sul modello relazionale, progettato per
consentire all'utente:
•
La lettura, la modica e la gestione dei dati memorizzati.
•
La creazione e modica della struttura di database.
•
La creazione e gestione dell'accesso ai dati e degli strumenti di controllo.
Shell La shell è la nestra di comando nella quale si immettono operazioni in
forma scritta da far eseguire al sistema operativo. In Windows si attiva
attraverso l'esecuzione del comando cmd, mentre su Linux viene chiamata
terminal.
Singleton Il singleton è in un pattern creazionale, descritto dalla Gang of
four , che coinvolge una classe che permette l'istanziazione di un solo
oggetto del proprio tipo durante l'esecuzione di un'applicazione.
Ogni
qualvolta si tenti di istanziare un nuovo oggetto appartenente alla classe
Singleton, e fosse già presente un oggetto istanziato della medesima classe,
viene impedita la creazione del nuovo oggetto e viene passato il riferimento
all'oggetto relativo alla prima istanza.
69
APPENDICE B.
GLOSSARIO
Smartphone Dispositivo mobile che integra le funzioni di telefonia cellulare
ad un sistema operativo grazie al quale è possibile gestire l'installazione
di applicazioni aggiuntive.
Struttura ricettiva Una struttura, nell'ambiente turistico, viene denita ricettiva qualora assuma lo scopo di accogliere la clientela all'interno dello stabilimento; 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 un
hotel con il personale di servizio addetto ai bagagli e alla segreteria.
T
Template Un template è un modello denito a priori per realizzare successivamente elementi simili, coerenti con la forma predenita .
Trigger Procedura SQL nella quale vengono specicate le operazioni automatizzate da eseguire al vericarsi di un evento una certa tabella del database.
Thread Processo eseguito in maniera concorrente ad altri processi, nella stesso
elaboratore.
U
UML L'Unied Modeling Language è un linguaggio per la modellazione e per la
specica denito nel 1996 dai tre amigos (Ivar Jacobson, Grady Booch
e Jim Rumbaugh) allo scopo di unicare i modelli di rappresentazione
dei sistemi precedentemente esistenti in ingegneria del software. Questo
linguaggio è costituito da una semantica precisa e utilizza viste e diagrammi correlati , tra cui i diagrammi use-case, delle classe, degli oggetti, di
sequenza e delle attività.
Use case Gli Use Case Diagram sono diagrammi nalizzati alla rappresentazione delle funzioni presenti in un sistema, descritte dal punto di vista
dell'interazione di un utente (denito actor ) col sistema stesso.
Questi
diagrammi vengono spesso impiegati come strumento per rappresentare i
requisiti 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 services
anche attraverso la tecnica RAD. Supporta diversi tipi di linguaggio tra
cui C, C++, C#, .Net, ASP .Net e Visual Basic
70
W
W3C la sigla identica l'associazione World Wide Web Consortium, fondata
nel 1994 da Tim Berners Lee in collaborazione con il CERN di Ginevra e il
MIT (Massachusetts Institute of Technology); tale associazione ha lo scopo
di standardizzare e migliorare i linguaggi e i protocolli per l'evoluzione del
Web.
Windows Mobile Sistema operativo dedicato di Microsoft dedicato ai dispositivi mobile del tipo PocketPC
WLanguage Linguaggio di programmazione proprietario di quarta generazione
dei prodotti della linea Windev dell'azienda francese PCSoft.
X
XML Siglia di eXtensible Markup Language ovvero linguaggio marcatore che
estende altri linguaggi di tipo marcatore. L'XML è utilizzato spesso come
linguaggio per il trasferimento di dati tra tipi di DBMS diversi, è utilizzato anche per creare nuovi linguaggi che hanno lo scopo di descrivere la
struttura di documenti.
71
APPENDICE B.
GLOSSARIO
72
Bibliograa
•
Sito internet di wikipedia, rielaborazione dei termini per il glossario
http://en.wikipedia.org
•
Sito del dizionario informatico, rielaborazione dei termini per il glossario
http://www.dizionarioinformatico.com
•
Sito internet di Planet Hotel, storia di Sintesi e Planet Hotel
http://www.planethotel.biz
•
Sito internet di Sybase, funzionalità di SQL anywhere 8.0
http://www.sybase.com
•
Sito internet inglese per Windev
http://www.windev.com
•
Dispense di ingegneria del software del Professor Tullio Vardanega
http://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
APPENDICE B.
GLOSSARIO
74
Elenco delle gure
1.1
Copertina depiant di Planet Hotel
1.2
Form di prenotazione presente nel modulo Front Desk
. . . . . . . . . . . . . . . . .
1.3
Graco predittivo generato da una funzione del modulo Back Oce
1.4
Tableau a colori per la gestione dell'occupazione tavoli nel modulo
. . . . . .
3
4
5
Ristorante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.5
Logo di Sybase
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.1
Ciclo di sviluppo incrementale secondo lo standard ISO 12207 . .
15
3.2
Diagramma di Gantt riguardante il piano di lavoro . . . . . . . .
17
3.3
Diagramma temporale delle ordinazioni in un ristorante
21
3.4
. . . . .
Diagramma temporale delle prestazioni erogate in un wellness
center
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.5
Diagramma temporale della spesa in un minimarket
. . . . . . .
23
3.6
Schema di sincronizzazione della tecnologia Mobilink . . . . . . .
24
3.7
Struttura di un database Ultralite accessibile da un applicazione
Java
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8
Struttura dell'applicazione ponte
3.9
Schema del funzionamento della tecnica Universal Replication di
Windev
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
27
28
3.10 Confronto tra il metodo di sviluppo RAD ed il metodo tradizionale 30
3.11 Tabelle relative ai agli articoli e ai listini dei punti vendita . . . .
3.12 Diagramma delle relazioni tra i moduli software di WalkingPH
3.13 Diagramma dei casi d'uso della tab Comanda
3.14 Diagramma dei casi d'uso della tab Conto
34
.
35
. . . . . . . . . .
36
. . . . . . . . . . . .
3.15 Schema delle componenti informative di un ordine
. . . . . . . .
3.16 Diagramma delle classi relative alla gestione delle ordinazioni
. .
37
45
47
3.17 Form grache relative all'autenticazione, la schermata principale
e la selezione del contesto
. . . . . . . . . . . . . . . . . . . . . .
49
3.18 Le tre tab che compongono la gestione ordine: comanda, conto e
cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
3.19 Tre schermate di esempio per la tab Comanda: selezione articolo,
inserimento manuale della quantità, inserimento di varianti
. . .
3.20 Schema delle operazioni per la creazione di un dettaglio d'ordine
51
51
3.21 Tre schermate della tab conto: ultima comanda, ordine intero e
riepilogo articoli di varianti
. . . . . . . . . . . . . . . . . . . . .
75
52
ELENCO DELLE FIGURE
76
Elenco delle tabelle
2.1
3.1
Tabella riassuntiva dei vincoli hardware e software
. . . . . . . .
12
Tabella di soddisfacimento dei vincoli da parte delle tecnologie
viste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.2
tabella dei requisiti del modulo di autenticazione
39
3.3
Tabella dei requisiti del modulo relativo alla schermata principale
40
3.4
Tabella dei requisiti del modulo Utilities . . . . . . . . . . . . . .
40
3.5
Tabella dei requisiti del modulo Risorse
41
3.6
Tabella dei requisiti della gestione ordine
3.7
Tabella dei requisiti del modulo Agenda
4.1
. . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . .
43
. . . . . . . . . . . . . .
43
Tabella dell'avanzamento nei requisiti dell'applicazione . . . . . .
57
77
