AlphaTrading - Relazione Su Implementazione e Test

Documento di Implementazione
Gruppo Alpha
Andrea Martelli
Emanuele Mottola
Roberto Paolillo
Corso di laurea in Ingegneria Informatica Specialistica
Anno Accademico 2007/2008
AlphaTrading
http://alphaserver.selfip.org:8080/Trading
Gruppo Alpha Documento di Implementazione – 1.0 1
Indice
1 Introduzione......................................................................................................................................3
2 Sviluppo del sistema.........................................................................................................................4
2.1 Strumenti utilizzati....................................................................................................................4
2.1.1 Collaborazione online.......................................................................................................4
2.1.2 Modellazione e progetto....................................................................................................4
2.1.3 Implementazione ed esecuzione........................................................................................4
2.1.4 Test.....................................................................................................................................4
2.2 Business Logic..........................................................................................................................5
2.3 AJAX e il framework Backbase................................................................................................6
2.3.1 Architettura clientserver...................................................................................................8
2.3.2 Schema delle pagine con MPI...........................................................................................9
2.3.4 Backbase e il pattern MVC..............................................................................................11
2.3.5 Componenti.....................................................................................................................12
2.3.6 Funzionamento su browser eterogenei............................................................................13
2.3.7 Browser compatibili........................................................................................................14
2.3.8 Modello di programmazione...........................................................................................15
2.3.9 Servlet di supporto..........................................................................................................16
2.4 PowerCharts v3.......................................................................................................................17
3 Analisi di qualità.............................................................................................................................18
3.1 I parametri ISO........................................................................................................................18
3.1.1 Funzionalità......................................................................................................................19
3.1.2 Usabilità...........................................................................................................................19
3.1.3 Affidabilità ed efficienza.................................................................................................19
3.1.4 Manutenibilità..................................................................................................................20
3.1.5 Portabilità........................................................................................................................20
3.2 Metriche..................................................................................................................................21
3.2.1 Valori metrici di dettaglio................................................................................................21
3.3 Unit Test..................................................................................................................................23
3.3.1 Tool utilizzati...................................................................................................................23
3.3.2 Test case sviluppato per AlphaTrading...........................................................................23
3.4 Stress test................................................................................................................................25
4 Analisi dei costi del software..........................................................................................................26
5 Utilizzo del sistema........................................................................................................................28
5.1 Amministratore.......................................................................................................................28
5.2 Guest.......................................................................................................................................30
5.3 Utente base..............................................................................................................................37
5.4 Utente avanzato.......................................................................................................................41
6 Installazione del sistema.................................................................................................................46
6.1 Requisiti minimi......................................................................................................................46
6.2 Procedura d'installazione........................................................................................................46
1 Introduzione
Il presente documento rappresenta il completamento del progetto, da noi denominato “AlphaTrading”,
oggetto di quest’anno di corso, e si propone di illustrare sia da un punto di vista strettamente tecnico, sia da
quello dell’utente, le caratteristiche, le tecnologie e le funzionalità espresse dalla nostra piattaforma di
trading on line.
L’obiettivo del progetto è stata la creazione di un sito internet per il trading online che fornisse un’ampia
gamma di servizi, quali gestione dei conti, negoziazione ed analisi tecniche, e che fosse inoltre flessibile in
base alle necessità di varie categorie di utenti, più o meno esperti nel campo del trading. Grazie ad
un’accurata attività di pianificazione iniziale, e la assidua collaborazione tra i membri del gruppo, anche
online attraverso strumenti avanzati, i requisiti del progetto sono stati rispettati, sia in termini di tempo che di
funzionalità, portando alla creazione di un prodotto finito globalmente soddisfacente.
Nel seguito vedremo gli aspetti salienti delle fasi di sviluppo, utilizzo ed installazione.
2 Sviluppo del sistema
2.1 Strumenti utilizzati
Durante tutta la durata del progetto sono stati utilizzati molti strumenti, suddivisibili in categorie, atti a
facilitare e velocizzare le attività del ciclo di vita di progetto (analisi, progetto, implementazione), e raccolti in
questo schema riepilogativo.
2.1.1 Collaborazione online
• Gliffy (http://www.gliffy.com): utilizzato per la creazione collaborativa e la visualizzazione di
diagrammi di vario tipo, specialmente per la modellazione delle classi e del database.
• Google Groups (http://groups.google.it/): creazione di uno spazio web riservato al gruppo di lavoro
con funzione di forum, mailing list, archivio file di piccole dimensioni e wiki.
• Google Documents (http://docs.google.com/): visualizzazione e scrittura collaborativa e
contemporanea di documenti di testo.
• Server FTP privato (ftp://alphaserver.selfip.org): installato presso uno dei computer dei membri del
gruppo, attivo 24/24h e utilizzato per lo scambio di file di grosse dimensioni o backup.
• Assembla SVN (http://www.assembla.com): servizio gratuito e limitato a 500 MB di spazio,
comprendente SVN (SubVersioN), Trac, mailing list, wiki, promemoria e gestione milestones, chat,
files. Utilizzato per lo sviluppo collaborativo del codice sorgente del progetto.
• Instant messengers & VoIP: principalmente Gtalk, MSN Messenger e Skype, utilizzati per
comunicazioni di qualsiasi genere e videoconferenze su aspetti cruciali del progetto.
2.1.2 Modellazione e progetto
• NetBeans IDE: usato per la creazione dei diagrammi UML e la generazione del codice java a partire
da questi.
• fabFORCE DBDesigner: modellazione e creazione schema grafico del database.
• Microsoft Project: definizione e sequenziamento delle attività, assegnazione risorse e
pianificazione generale dei tempi.
• Microsoft Visio: creazione di diagrammi e illustrazioni di vario tipo.
• Dia Diagram Editor: creazione di diagrammi e illustrazioni di vario tipo.
• MySQL Administrator: amministrazione del database in locale e sul server dedicato al progetto.
2.1.3 Implementazione ed esecuzione
• NetBeans IDE: creazione applicazione Web. Programmazione HTML, JSP, XML, JavaScript, Java.
• Java SE Development Kit (JDK): Java Runtime Environment e librerie per lo sviluppo.
• Apache Tomcat: web server e web container con supporto a Jsp e Servlet.
• MySQL Community Server: DBMS transazionale multithread opensource.
• Backbase: tag library e script per la creazione di RIA (Rich Internet Applications) utilizzando
componenti AJAX (Asynchronous Javascript And Xml).
• InfoSoft PowerCharts: creazione di grafici “data driver” interattivi in Flash.
2.1.4 Test
• HTMLUnit: esploratore automatico di pagine html/javascript.
• JWebUnit: framework per la creazione di unit tests per applicazioni web.
2.2 Business Logic
DuL’implementazione del sistema ha preso le mosse dalla realizzazione della business logic del sistema,
ovvero la gerarchia di classi precedentemente modellata e generata automaticamente grazie alla funzionalità
integrata in NetBeans. La componente fondamentale, oltre che necessaria per le successive fasi di sviluppo
in quanto “substrato” di tutto il sistema, è il Demone, che realizza gran parte dell’elaborazione lato server,
insieme ad alcune servlets la cui utilità sarà discussa in seguito. Esso funge da collegamento tra la sorgente
dei dati di Borsa (Yahoo Finance) e il DBMS, e si occupa della gestione delle quotazioni e degli ordini. Senza
le variazioni prodotte dall’aggiornamento delle quotazioni e dall’esecuzione o annullamento degli ordini degli
utenti, il sistema sarebbe completamente statico e inutile.
Il Demone è realizzato utilizzando una classe detta Updater, contenente i metodi principali, e una classe
Daemon, deputata al controllo dell’esecuzione e alla gestione del log. In particolare, la classe updater
estende la classe TimerTask, a sua volta figlia di Runnable, e costituisce un thread lanciato periodicamente
con un intervallo di 5 minuti.
Nonostante i dettagli siano stati già analizzati nei documenti di analisi e di progetto, al fine di evidenziare le
funzionalità del sistema in modo semplice, illustriamo di seguito la logica base del sistema, i cui effetti
saranno riscontrabili dall’utente.
Fig. 1. aggiornamento quotazioni
Fig 2. esecuzione ordini
2.3 AJAX e il framework Backbase
AJAX è un termine per indicare un gruppo di tecniche e tecnologie di sviluppo web che consentono di creare
applicazioni web interattive:
• eXtensible HyperText Markup Language (XHTML – Linguaggio di marcatura di ipertesti estensibili) e
Cascading Style Sheet (CSS – Foglio di stile a cascata) per la presentazione delle informazioni.
• Document Object Model (DOM – Modello di documento ad oggetti), che è la rappresentazione
interna di una pagina web, manipolata attraverso JavaScript per visualizzare informazioni
dinamicamente ed interagire con esse.
• eXtensible Markup Language (XML – Linguaggio di marcatura estensibile) ed eXtensible Stylesheet
Language Transformations (XSLT – Linguaggio di trasformazione dell'XML) per l'interscambio di dati
tra browser e server, nonché per la manipolazione dei dati.
• L'oggetto XMLHttpRequest per scambiare dati XML in modo asincrono con il web server, usando il
protocollo HTTP. Questo comporta che il client non deve per forza attendere il completamento dello
scambio di dati prima che sia possibile un ulteriore interazione tra l'utente e l'applicazione. Come
risultato, il processamento JavaScript può avvenire simultaneamente con l'interazione clientserver,
inoltre non è necessaria la richiesta di una nuova pagina per mostrare i nuovi dati, così solo i dati
necessari sono scambiati col server, e l'interfaccia utente diventa molto più reattiva agli input
dell'utente.
• JavaScript unisce tutto insieme, è usato per interagire dinamicamente con le informazioni
visualizzate. Le funzioni JavaScript possono essere usate per cambiare lo stile o i contenuti, come
per manipolare l'albero DOM.
• Da una prospettiva tecnica, l'uso dell'oggetto XMLHttpRequest consente alle applicazioni di ricevere
dati dal server in modo asincrono; per esempio il risultato di una lunga query al database, mentre
l'utente continua a interagire con l'applicazione come presente nella pagina del browser. Una volta
che il trasferimento dati è completato, il JavaScript nel client aggiorna solo le parti della pagina che
lo necessitano mediante la manipolazione del DOM, senza riaggiornare l'intera pagina, come invece
richiesto da un applicazione web convenzionale, e senza forzare l'utente ad aspettane intanto che la
comunicazione col server sia completata.
• Da una prospettiva concettuale, la tecnologia AJAX consente di costruire delle applicazioni con
interfaccia a singola pagina (SPI Single Page Interface). Queste applicazioni hanno un solo
documento XHTML completo, nel quale il contenuto (dinamico) di file o dati saranno caricati.
• L'interazione dell'utente finale si concretizza nella richiesta asincrona di dati al server anziché nella
richiesta della pagina completa.
Questo comporta un aggiornamento parziale dell'interfaccia utente, offrendo come risultato una
risposta molto veloce all'utente, una transizione veloce tra gli stati e una piattaforma di lavoro stabile
e continua.
Il lookandfeel di una applicazione AJAX SPI può essere simile a quella di un applicazione desktop.
L'interfaccia è dentro una finestra, e l'interazione è presente nell'aggiornamento di parte di essa.
Negli ultimi anni sono stati sviluppati diversi frameworks AJAX per aiutare lo sviluppo di applicazioni AJAX,
riducendone la complessità.
Il framework lato client è unico per via della sua maturità, del modello di programmazione forte, della
ricchezza e assortimento di widgets per l'interfaccia e molto altro.
Usando AJAX con il modello SPI, è facile cambiare idea su come configurare il backend per servire al
meglio piccole richieste di dati asincrone. In questo modo si può aumentare le performance del server per
fornire agli utenti finali una esperienza web migliore.
Così l'interfaccia multi pagina (MPI MultiPage Interface) è sinonimo del classico modello di applicazione
web, mentre SPI con AJAX del modello di applicazioni web.
Prima che l'ogetto XMLHttpRequest diventi largamente supportato dai browser, le applicazioni che si
considerano sono MPI, che sono fatte da una serie di pagine web distinte, e ogni interazione dell'utente
finale che fa una richiesta diviene per il server una richiesta di aggiornamento dell'intera pagina.
Fig 3. aggiornamento delle pagine in applicazioni web “tradizionali”
Fig 4. aggiornamento delle pagine in ambiente AJAX/Backbase
2.3.1 Architettura clientserver
Quella clientserver è un'architettura a 2 livelli in cui si individuano il client (spesso un applicazione che usa
una interfaccia utente) e il server. Il software lato client manda delle richieste al server, che risponde con
delle informazioni aggiornate. Prima dell'avvento di AJAX, i web server controllavano la maggior parte delle
funzionalità di presentazione e applicazione: per questo un'applicazione tradizionale MPI è in realtà
un'applicazione a singolo livello. Con AJAX, JavaScript aggiorna la visualizzazione dinamicamente, il metodo
XMLHttpRequest manda dei nuovi dati dal client quando necessario, e il CSS astrae la presentazione dalla
struttura del documento. Così facendo, il motore (engine) AJAX nel browser prende in parte il posto di
funzionalità del web server, consentendo di controllare e manipolare gran parte del livello di presentazione. Il
motore AJAX media tra le richieste del client e il web server, instradando a quest'ultimo solo le informazioni
che devono essere processate. Spostando in questo modo alcune delle responsabilità dal server al client si
effettua un minor scambio di dati, ognuno con meno informazioni.
Quando progettate e implementate correttamente, le applicazioni AJAX vengono eseguire molto più
velocemente delle tradizionali applicazioni web, diminuendo la latenza e incrementando il potenziale
dell'applicazione mediante una forte interazione con l'utente.
Fig 5. raffronto tra Multiple Page e Single Page Interface
Alcune delle sfide comuni che gli sviluppatori AJAX devono affrontare sono:
• Sebbene tutti i browser moderni supportino l'oggetto XMLHttpRequest, la sua implementazione può
essere varia, richiedendo specifiche implementazioni in JavaScript per ognuno.
• L'invio di un XMLHttpRequest e la gestione degli eventi riguardanti i dati di risposta è tutt'altro che
semplice.
• JavaScript è un linguaggio pieno di funzionalità, orientato agli oggetti, e se non è applicato con rigore
nel processo di sviluppo, può succedere che il codice dell'applicazione venga implementato in
maniera non pulita e difficile da mantenere.
• E' richiesta una conoscenza avanzata di JavaScript e CSS per essere sicuri che I widgets AJAX
siano visualizzati uniformemente nei differenti browser.
• Lo standard HTML non ha il supporto per una ricca interfaccia di widgets, è richiesto quindi un
tempo aggiuntivo per sviluppare dei widgets dinamici e con funzionalità avanzate come il
draganddrop, il riposizionamento e il ridimensionamento dei dati.
• E' noioso e dispersivo in termini di tempo creare una libreria personalizzata di JavaScript e gestire
l'oggetto XMLHttpRequest in un applicazione AJAX.
• Le soluzioni sono spesso proprietarie, bloccando così gli sviluppatori in particolari tecnologie.
• I segnalibri e la cronologia dei browser possono essere difficoltose dove il browser non può tenere
traccie dei cambiamenti nelle sezioni delle pagine.
2.3.2 Schema delle pagine con MPI
In virtù dell'utilizzo di Backbase e, più in generale, di Ajax, lo schema delle pagine del sito và rivisto in quanto
alcune pagine originariamente distinte, ora sono funzionalmente “inglobate” in interfacce a pagina multipla
(MPI appunto).
2.3.4 Backbase e il pattern MVC
Il client processa a runtime tutti i vari linguaggi per costruire l'applicazione web dai documenti XML e
gestisce i cambiamenti di questi documenti. Durante il processo di costruzione, il client prende dei frammenti
(modello) di dati XML e ne renderizza l'output nel browser. Inoltre crea degli oggetti controllori che sono
connessi al modello, al relativo nodo di visualizzazione, alle definizioni dei widgets, e a qualsiasi altro evento
da gestire. Questi sono comunemente conosciuti come il pattern ModelloVistaControllore (MVC:
Model – View – Controller).
Fig 6. Modello MVC
MVC è un pattern architetturale che utilizza dei dati specifici del dominio (model) che sono separati mediante
un controllore dalla loro presentazione (view), così si aumenta notevolmente la flessibilità e la riusabilità.
Utilizzando Backbase il Client Runtime Engine applica il pattern MVC in questo modo: il browser carica il
documento XHTML e crea l'albero di DOM da esso. Una volta che il client ha caricato tutto, inizia la fase di
costruzione e il motore ispeziona l'albero di DOM cominciando a collezionare tutti I fragmenti che hanno un
tag Backbase abilitato. Questi frammenti sono le parti del documento XHTML racchiusi nel tag xmp (una tag
HTML deprecato) con la dicitura backbase=”true”. I frammenti così costruiti sono posizionati in una nuova
struttura XML che rappresenta il modello.
Il motore analizza questa struttura e costruisce due nuove versioni dei dati XML. Inizialmente questo crea
una serie di oggetti controllori, che il Client Runtime Engine rendererizza in un albero di viste che
rappresenta l'applicazione visualizzata.
2.3.5 Componenti
Fig 7. componenti di Backbase
Le caratteristiche descritte in seguito sono combinate nella seguente lista di componenti per il framework lato
client:
• La leggerezza del Client a runtime che funziona come un gestore d'interfaccia utente. Il motore
costruisce la web application e gestisce le interazioni degli utenti dall'interno di ogni browser,
mandando le richieste al server solo quando necessario. Si suppone che non siano solo supportati I
linguaggi che ogni browser è capace di gestire (XHTML, JavaScript, CSS, Xpath), ma anche molti
nuovi standard che diversi browser non sono ancora capaci di processare (Eventi di livello 3 DOM,
XInclude, SMIL) e linguaggi personalizzati definiti nel TDL.
• La Tag Library di Backbase (BTL) fornisce I widgets dell'interfaccia utente.
• Il linguaggio d'esecuzione dichiarativo XML(XEL).
• Il linguaggio di definizione dei tag (TDL Tag Definition Language).
• Le potenza di avere due API che consentono all'applicazione di interrogare il nucleo del motore
usando JavaScript o XEL
• Gli strumenti per gli sviluppatori che aiutano nel debugging e nel miglioramento delle prestazioni.
Fig 8. distribuzione delle funzioni tra client e server
2.3.6 Funzionamento su browser eterogenei
Tutti i browsers devono processare informazioni nella stesso esatto modo. Mentre la maggior parte di essi
supporta le stesse specifiche di base, spesso supportano differenti livelli di queste specifiche. Per esempio,
alcuni browser supportano differenti livelli delle specifiche DOM.
Inoltre i browser hanno diversi valori di default per alcuni elementi, e non implementano le stesse specifiche
di linguaggio. Al contrario questi implementano il linguaggio basandosi sulla loro personale interpretazione
degli standard. Questo è un grattacapo per gli sviluppatori, che sono costretti a spendere ore di
programmazione per essere sicuri che tutti i browser interpreteranno il loro codice nella stessa maniera.
Fig 9. equalizzazione degli standard di visualizzazione tra browser
Per risolvere il problema, Backbase fornisce una propria implementazione di questi standard diversamente
interpretati dai browser, ad esempio la propria implementazione di XHTML livella le implementazioni diverse
tra I browser. In questo modo quando il motore AJAX processa l'XHTML, questo mappa correttamente,
secondo gli standard del W3C, gli elementi e attributi per I vari browser in maniera automatica.
2.3.7 Browser compatibili
Grazie all’utilizzo di Backbase, e alle sue peculiarità appena descritte, è stato possibile rendere il sito
compatibile con un gran numero di browser, ricoprendo così la più alta percentuale possibile di utenza. Le
componenti più complesse delle pagine, infatti, sono realizzate col suddetto framework e quindi largamente
compatibili.
Fig 10. tabella delle compatibilità
2.3.8 Modello di programmazione
Il framework lato client offre un modello di programmazione semplice e robusto per gestire e manipolare le
applicazioni web. Con TDL si possono creare ed estendere gli elementi, senza la necessità di imparare dei
nuovi concetti poiché si usano quelli comuni, come metodi e proprietà. In maniera analoga la sintassi di
entrambe le API è semplice da comprendere. Esiste quindi la possibilità di scegliere se usare JavaScript o
XEL come linguaggio di programmazione, secondo i propri gusti.
L'uso di XEL ha un vantaggio preciso rispetto al JavaScript. Infatti quando si usa quest'ultimo per comandi
asincroni, c'è bisogno di una programmazione complessa e laboriosa per essere sicuri che i comandi
saranno eseguiti nella sequenza desiderata. Per esempio se si vuole effettuare un caricamento (usando
XMLHttpRequest), seguito da un messaggio di avviso, questo sarà mostrato probabilmente prima del
completamento della ricezione dei dati, senza un appropriata programmazione.
In XEL invece il messaggio aspetta fino a quando il caricamento sia completato.
Il modello di ereditarietà fornisce l'ereditarietà multipla, inoltre vengono fornito delle funzionalità precostruite
di getters e setters, di cambio degli attributi, costruttori e distruttori, infine dei tag per la creazione semplice
ed immediata degli elementi.
Di conseguenza si può utilizzare un linguaggio di programmazione potente che beneficia dell'astrazione,
della riusabilità nonché della manutenibilità del codice.
Gli sviluppatori che inseriscono istanze di questi elementi nelle applicazioni rimangono quindi all'oscuro della
loro complessità, possono semplicemente aggiungere dei widgets alle pagine web, settare gli attributi sui
tag, aggiungendo eventi e comandi.
Le ragioni precise per utilizzare XEL al posto di JavaScript sono essenzialmente tre:
• Preferenza personale – Se ci si trova a proprio agio con la sintassi basata su XML e non si conosce,
o non si vuole conoscere, JavaScript
• Eventi asincroni – E' difficile creare e gestire questo tipo di eventi con JavaScript
• Astrazione dei dati – Siccome XEL è un linguaggio dichiarativo basato su XML, è indipendente dalla
piattaforma. Tutto ciò che è richiesto per far lavorare XEL indipendentemente dal browser è legato al
fatto che questo sia capace di leggere frammenti XML e fogli di stile XSLT per convertire la sintassi
XEL nella sintassi che il browser è capace di comprendere
XEL contiene tutte le funzionalità di un linguaggio di programmazione, inclusa l'abilità di creare funzioni,
chiamare metodi, settare variabili, eseguire comandi JavaScript o Xpath, istruzioni condizionali o iterative,
catturare gli errori.
L'esempio seguente mostra come usare XEL in un'applicazione per agganciare un gestore degli eventi XEL
ad un elemento XHTML
Esempio 1 – implementazione base del gestore di eventi XEL
<div>
<e:handler event="click" type="text/javascript">
alert('I am clicked!');
</e:handler>
Click me!
</div>
I comandi delle funzioni sono forniti per rendere semplici i processi di programmazione complessi.
Si può accedervi in maniera dichiarativa, oppure usando la sintassi JavaScript.
L'esempio seguente mostra il metodo dichiarativo per caricare un frammento XML esterno:
Esempio 2 – Command load
<script xmlns:e="http://www.backbase.com/2006/xel"
xmlns:c=http://www.backbase.com/2006/command
xmlns="http://www.w3.org/1999/xhtml"
xmlns:b=http://www.backbase.com/2006/btl type="application/backbase+xml">
<div>
<e:handler event="click" type="application/xml">
<c:load url="data.xml" destination="id('destinationDiv')"
mode="replaceChildren"/>
</e:handler>
</div>
</script>
2.3.9 Servlet di supporto
Affinché gli elementi Ajax funzionino correttamente, il collegamento tra il componente visualizzato nel
browser e i dati presenti sul server dev’essere realizzato in modo opportuno. In particolare, l’oggetto
XmlHttpRequest (nascosto dall’implementazione Backbase) deve ottenere, appunto, in ingresso un flusso
dati XML. A tal fine sono state realizzate delle servlet che formattano i dati richiesti in XML e li inviano tramite
l’oggetto HttpServletResponse, come nel caso della visualizzazione del log di sistema, della lista dei
movimenti, o dei suggerimenti nella casella di ricerca dei titoli. A titolo esemplificativo, si riportano un
frammento della servlet getXmlLog:
Esempio 3 – frammento getXmlLog
public class getXmlLog extends HttpServlet {
// metodo chiamato sia da doGet che doPost
protected void processRequest(HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException {
response.setContentType("application/xml;charset=UTF-8");
PrintWriter out = response.getWriter();
try {
String log = Demone.getLog();
StringReader sr = new StringReader(log);
BufferedReader br = new BufferedReader(sr);
out.println("<log>");
String temp;
while((temp=br.readLine())!=null) {
int index = temp.indexOf(" | ");
out.println("<entry>");
String time = temp.substring(0, index);
String event = temp.substring(index+3);
out.println("<time>"+time+"</time>");
out.println("<event>"+event+"</event>");
out.println("</entry>");
}
out.println("</log>");
br.close();
sr.close();
} finally {
out.close();
}
}
2.4 PowerCharts v3
Nel tentativo di utilizzare il più possibile componenti preesistenti, e diversamente da quanto inizialmente
pianificato, per la realizzazione dei grafici è stato utilizzato PowerCharts, un set di widget avanzati che
permettono di disegnare grafici interattivi e visivamente d’impatto. È possibile ottenere grafici di vario tipo per
effettuare simulazioni, selezione visiva di dati e analisi finanziarie. Questo componente, sfruttando
intensivamente le funzionalità messe a disposizione da Adobe Flash, permette di aggiungere all’applicazione
web funzionalità tipiche delle RIA, con un netto miglioramento dell’esperienza dell’utente durante la
navigazione.
Fig 11. esempio di grafico candlestick con media mobile
3 Analisi di qualità
3.1 I parametri ISO
Tradizionalmente, i parametri (o fattori) rispetto a cui si può misurare o definire la qualità del software
vengono classificati in due famiglie: parametri esterni e parametri interni. I primi si riferiscono alla qualità del
software così come è percepita dai suoi utenti, e includono correttezza, affidabilità, robustezza, efficienza,
usabilità. I secondi si riferiscono alla qualità del software così come è percepita dagli sviluppatori, e
includono verificabilità, manutenibilità, riparabilità, evolvibilità, riusabilità, portabilità, leggibilità, modularità.
Non raramente esiste una correlazione fra questi due aspetti (banalizzando: il software mal scritto tende
anche a funzionare male).
Per effettuare una analisi di qualità del software in modo più rigoroso, ci si può rifare alla normativa ISO
9126, che individua 7 set di caratteristiche di qualità per un software:
• Funzionalità
• Usabilità
• Portabilità
• Affidabilità
• Efficienza
• Manutenibilità
Si analizzano ora nel dettaglio queste voci e valutando il comportamento di AlphaTrading sotto questi punti di
vista.
Fig 12. ISO/IEC 9126
3.1.1 Funzionalità
AlphaTrading include un set di funzionalità piuttosto ricco, che soddisfa sia i requisiti imposti che una serie di
altri requisiti impliciti, sorti durante le fasi di analisi e di progetto.
Tutti i casi d'uso previsti sono stati correttamente implementati, e per i casi d'uso più rilevanti sono stati
predisposti dei set di Unit Test, per verificare la correttezza formale e sostanziale dei risultati ottenuti.
A questo proposito si possono trovare ulteriori dettagli nella sezione relativa all'Unit Test.
Riassumendo:
Adeguatezza, Conformità, Accuratezza l software rispetta le specifiche ed esegue tutti i casi d'uso in
modo corretto (effettuati test che lo provano)
Interoperabilità Il software lavora correttamente con sistemi esterni, quali il
fornitore dati borsa e il sistema borsistico in generale
Sicurezza Viene controllata l'identità dell'utente e la comunicazione
avviene attraverso un canale crittografato HTTPs
Tab 1. funzionalità
3.1.2 Usabilità
L'utilizzo di AJAX e dei widget presenti in Backbase rendono l'utilizzo da parte dell'utente assai semplice ed
intuitivo, oltre a fornire una interfaccia grafica accattivante.
L'approccio gSPI (group of Single Page Interface) e i componenti desktoplike come finestre, pulsanti, slider
ecc, rendono l'utilizzo della web application in parte simile all'utilizzo di una applicazione desktop
tradizionale. Questo a completo vantaggio della semplicità di apprendimento e d'uso.
Riassumendo:
Semplicità di apprendimento Facilitata da un ambiente desktoplike
Semplicità di utilizzo Buona, grazie ad AJAX e all'approccio SPI
Look & Feel / Attrattività Elevata utilizzando i widget Backbase
Tab 2. usabilità
3.1.3 Affidabilità ed efficienza
Il software, laddove possibile, utilizza algoritmi ottimizzati e pattern di dettaglio che consentono una efficace
gestione della memoria e della CPU.
Attraverso una corretta gestione delle eccezioni Java, si evita il blocco del sistema in seguito a
malfunzionamenti di uno dei componenti.
Le prestazioni sono in parte aggravate dalla Java Virtual Machine in esecuzione attraverso il web container
Tomcat. Tuttavia riescono a gestire un carico moderato di utenti con tempi e utilizzo memoria pressoché
accettabili. A tale proposito si guardi la sezione riguardanti i test di efficienza (JMeter) per metriche e
valutazione delle prestazioni della webapplication.
Riassumendo:
Maturità I ristretti tempi di sviluppo non hanno consentito di raggiungere
un adeguato livello di maturità del software
Tolleranza ai guasti e Ricuperabilità Una adeguata gestione delle eccezioni consente di evitare il
blocco in caso di malfunzionamenti di un componente. Per
componenti esterni, le connessioni vengono tentate più di una
volta, per recuperare situazioni di irraggiungibilità temporanea
Prestazioni e Utilizzo risorse Per quanto possibile ottimizzate, utilizzando pattern di dettaglio
come il Flyweight per una più efficiente gestione della memoria
Tab 3. affidabilità ed efficienza
3.1.4 Manutenibilità
L'utilizzo di numerose tag library e tecnologie XML, sia lato server (JSTL command, function e format,
JavaBeans) che lato client (BACKBASE, XEL, XPath, XSLT, CSS) rendono il codice molto più facilmente
leggibile e modificabile rispetto all'utilizzo di blocchi di codice Java nelle pagine JSP, molto meno
amalgamate al codice HTML.
L'utilizzo dei fogli di stile di pagina (CSS) e XML (XSLT) permettono di attuare una netta separazione tra dati
e presentazione, rendendo il codice più semplice da mantenere.
XEL e XPath rendono immediatamente comprensibili le azioni e le funzioni Javascript. Inoltre Backbase
integra nel suo Client Runtime Engine molte funzionalità quali validazione dei form, comunicazione
asincrona, modifica dinamica del DOM. Tutto questo permette allo sviluppatore di ignorare questi aspetti,
affidandosi a codice funzionante, testato e supportato da più browser contemporaneamente.
Riassumendo:
Analizzabilità Elevata grazie all'utilizzo di numerose taglibrary, sia lato client che lato
server
Modificabilità Resa assai semplice dalla modularità del sistema e dall'utilizzo
dell'ambiente Java e delle tag libraries
Testabilità Opportuni meccanismi di fallback escludono le parti di codice dinamiche
che richiedono l'interazione dell'utente, permettendo l'esecuzione di routine
di test automatizzate
Tab 4. manutenibilità
3.1.5 Portabilità
La scelta dell'architettura software Java ha influito notevolmente sulle caratteristiche di portabilità del
software. Esso infatti può essere eseguito su numerose piattaforme server eterogenee, e la fase di
deployment è resa assai rapida dai meccanismi di packaging e archiviazione Java, come la creazione di file
WAR (Webapplication Archive).
Anche Backbase contribuisce alla portabilità, rendendo l'applicazione crossbrowser (come più volte
evidenziato).
Riassumendo:
Adattabilità alla macchina Vasta grazie all'utilizzo dell'architettura Java
Adattabilità al software La webapplication è crossbrowser, in quanto il Client Runtime Engine di
Backbase si preoccupa dell'equalizzazione delle funzionalità tra browser
differenti
Installabilità I file WAR rendono il deployment della web application immediato
Tab 5. portabilità
3.2 Metriche
Uno strumento in nostro possesso per la valutazione della qualità del software realizzato è rappresentato
dalle "metriche di prodotto". Esse rappresentano una valutazione quantitativa della dimensione di un certo
attributo del prodotto, in questo caso del software.
Le metriche qui riportate sono state calcolate con l'ausilio di diversi tool java, che analizzano il codice
sorgente o il bytecode (a seconda dei casi) e restituiscono i valori di alcuni parametri.
I tool utilizzati sono:
• JavaNCSS, per numero di statement e complessità ciclomatica
(http://www.kclee.de/clemens/java/javancss/)
• Ckjm, per le metriche CK (http://www.dmst.aueb.gr/dds/sw/ckjm/doc/metric.html)
• JDepend, per l'accoppiamento a livello di package
Le metriche Chidamber and Kemerer (anche conosciute come metriche CK) sono molto usate nell'analisi di
qualità di software orientato agli oggetti. Analizzano il software dal punto di vista delle classi, e sono:
• WMC: Weighted methods per class
• DIT: Depth of Inheritance Tree
• NOC: Number of Children
• CBO: Coupling between object classes
• RFC: Response for a Class
• LCOM: Lack of cohesion in methods
• Ca: Afferent couplin
Inoltre sono state calcolate alcune metriche a livello di funzione (raggruppate nel prospetto anche a livello di
classe). Nello specifico:
• NCSS: Non Commenting Source Statements
• CCN: Cyclomatic Complexity Number
3.2.1 Valori metrici di dettaglio
I valori metrici di dettaglio dei principali metodi sono elencati nella pagina seguente.
Classe Funzioni NCSS CBO (Ce) CCN MC WMC RFC LCOM Ca NPM
ajaxProxy 4 28 0 10 5 2,50 21 10 0 2
AnalisiTecnica 14 204 1 77 14 5,50 37 1 1 13
Andamento 30 109 2 36 30 1,20 50 0 1 29
Borsa 11 37 8 15 11 1,36 27 27 5 11
BorsaDAO 14 134 4 40 14 2,86 38 0 3 13
Conto 38 172 7 70 37 1,84 76 402 8 37
ContoDAO 24 269 4 83 24 3,46 60 0 3 23
DAO 4 4 0 4 4 1,00 4 6 11 4
DAOconCodice 1 1 1 1 1 1,00 1 0 9 1
DBConnector 2 10 0 5 3 2,50 9 1 13 3
Demone 10 97 1 30 12 3,00 47 28 5 10
ElementoConCodice 5 9 0 5 6 1,00 8 9 11 6
Elenchi 10 22 4 11 11 1,10 16 31 6 11
ElencoBorse 2 5 5 2 2 1,00 6 1 1 2
ElencoCompleto 8 24 2 11 8 1,38 19 2 4 8
ElencoIndici 2 5 5 2 2 1,00 6 1 2 2
ElencoSegmenti 2 5 5 2 2 1,00 6 1 2 2
ElencoTitoli 5 51 6 14 5 2,80 36 10 6 5
FornitoreDati 9 171 5 58 9 6,44 81 36 1 6
getMovimentiXml 4 24 2 5 5 1,25 28 10 0 2
getXmlLog 4 27 1 5 5 1,25 22 10 0 2
Indice 12 32 7 13 12 1,08 22 46 3 12
IndiceDAO 10 57 3 22 10 2,20 31 19 2 9
ListaTitoli 1 1 0 1 1 1,00 1 0 1 1
Login 7 24 1 13 7 1,86 12 0 1 7
Movimento 15 34 1 15 15 1,00 19 83 3 15
MovimentoDAO 8 47 3 13 8 1,63 40 6 2 7
ordina 4 50 13 10 5 2,50 44 10 0 2
Ordine 26 59 9 27 26 1,04 34 289 5 26
OrdineDAO 9 84 7 18 9 2,00 60 0 3 8
Quotazione 12 23 1 12 13 1,00 15 64 6 13
QuotazioneAzione 20 45 3 21 21 1,05 24 184 7 21
QuotazioneAzioneDAO 9 92 4 23 9 2,56 65 14 2 8
QuotazioneValuta 6 17 3 7 7 1,17 10 9 5 7
QuotazioneValutaDAO 9 70 4 24 9 2,67 53 14 2 8
Searcher 5 14 3 6 5 1,20 13 2 0 5
Segmento 10 27 5 11 10 1,10 21 21 5 10
SegmentoDAO 12 84 3 30 12 2,50 34 14 3 11
Titolo 13 38 7 17 13 1,31 24 54 7 13
TitoloDAO 12 136 7 38 12 3,17 71 28 2 11
TitoloPosseduto 20 44 1 20 20 1,00 25 158 4 20
TitoloPossedutoDAO 11 106 3 26 11 2,36 55 0 2 9
Updater 10 190 22 64 10 6,40 114 33 2 6
Utente 17 39 3 17 17 1,00 24 106 4 17
UtenteDAO 11 88 4 26 11 2,36 42 5 2 10
Valori medi 10,49 62,42 4 21,33 10,73 1,99 32,24 38,78 3,67 9,96
3.3 Unit Test
L'Unit Testing è la procedura con cui si verifica la più piccola parte di un sistema (software, in questo caso).
Nel caso della programmazione procedurale, l'unità corrisponde alla singola funzione. Per la
programmazione ad oggetti invece, l'unità è rappresentata dal metodo di una classe.
Nel caso di una webapplication, l'unit testing può essere applicato sia ai metodi delle classi che
costituiscono la core logic, che alle pagine web che costituiscono l'applicazione.
La nostra attenzione si è focalizzata proprio su quest'ultimo aspetto, in quanto testare il funzionamento delle
pagine comporta inevitabilmente testare classi e javabeans ad essi associati.
3.3.1 Tool utilizzati
Il framework per il testing Java più conosciuto e diffuso è JUnit. Creato da Kent Beck insieme ad Erich
Gamma fornisce una serie di classi per la definizione di "Test Cases" e "Test Suites", che attraverso le
asserzioni verificano la correttezza dei risultati ottenuti dalla chiamata di un metodo. JUnit è parte (principale)
di xUnit, una suite più ampia che comprende diversi altri tool per scenari di test più specifici.
Ne fa parte tra gli altri HttpUnit, dedicato al test delle pagine web. HttpUnit emula le principali funzionalità di
un browser web, incluso l'invio dei form, Javascript, autenticazione HTTP, redirezione ecc., e permette di
scrivere Test Cases in grado di esaminare le pagine ottenute a livello testuale, di XML DOM, di form, tabelle
e link.
Combinato con JUnit rende assai semplice la scrittura di routine di test automatizzato che verifichino il
funzionamento di una webapplication.
3.3.2 Test case sviluppato per AlphaTrading
Nel caso di AlphaTrading è risultato opportuno implementare una procedura di test che verificasse che,
partendo dall'elenco borse, tutti i link relativi a indici e segmenti e per ognuno di essi ogni link relativo ai titoli
contenuti portasse ad una pagina valida, contenente le informazioni sul titolo, senza generare eccezioni.
Infatti potrebbe verificarsi che un codice titolo erroneamente inserito del DB e/o non più presente nei listini
borsistici generi un eccezione non appena il fornitore dati cerchi di recuperare per esso le ultime quotazioni.
Codice java – test case di AlphaTrading
import com.gargoylesoftware.htmlunit.BrowserVersion;
import com.gargoylesoftware.htmlunit.WebClient;
import com.gargoylesoftware.htmlunit.html.HtmlPage;
import com.gargoylesoftware.htmlunit.html.ClickableElement;
..........
import java.util.ArrayList;
import java.util.List;
import junit.framework.TestCase;
public class TradingTest extends TestCase {
public TradingTest(String name) {
super(name);
}
@Override
public void setUp() throws Exception {
}
public void testTitoli() throws Exception {
final WebClient webClient = new WebClient(BrowserVersion.FIREFOX_2);
webClient.setJavaScriptEnabled(true);
webClient.setThrowExceptionOnScriptError(true);
webClient.setAlertHandler(new AlertHandler() {
public void handleAlert(Page page, String msg) {
System.out.println(msg);
}
});
String baseUrl = "http://localhost:8084";
HtmlPage page = (HtmlPage) webClient.getPage(baseUrl + "/Trading/borse.jsp?
testing=true");
assertNotNull(page.getHtmlElementById("main"));
List linksBorse = new ArrayList();
linksBorse = page.getByXPath("id('main')//a");
for (Object borsa : linksBorse) {
ClickableElement borsa_link = (ClickableElement) borsa;
try {
HtmlPage borsaPag = (HtmlPage)borsa_link.click();
System.out.println("Testing " + borsa_link.getTextContent());
assertEquals("AlphaTrading - Listino Titoli", borsaPag.getTitleText());
List linksPagine = new ArrayList();
linksPagine = borsaPag.getByXPath("id('pager')/a");
for (Object paginaListino : linksPagine) {
ClickableElement pagina_link = (ClickableElement) paginaListino;
try {
HtmlPage paginaPag = (HtmlPage)pagina_link.click();
List linksTitoli = new ArrayList();
linksTitoli = paginaPag.getByXPath("id('content')//table/tbody/tr");
for (Object titolo : linksTitoli) {
ClickableElement titolo_link = (ClickableElement) titolo;
try {
HtmlPage titoloPag = (HtmlPage) titolo_link.click();
} catch (FailingHttpStatusCodeException e) {
assertTrue(false);
}
}
assertTrue(false);
}
}
assertTrue(false);
}
}
}
}
La procedura implementata sfrutta JUnit e HttpUnit.
Si è realizzata la classe TradingTest che estende TestCase. Il comportamento predefinito di JUnit è quello di
eseguire automaticamente tutti i metodi il cui nome inizia con la keyword "test". Dunque abbiamo definito il
metodo testTitoli che implementa la routine precedentemente descritta.
Innanzitutto viene creato un oggetto WebClient, specificando che esso deve emulare Firefox 2, sia per
quanto riguarda l'header useragent che per la tipologia di DOM implementato (presenza dell'oggetto
XMLHttpRequest, ad esempio). Quindi, viene caricata borse.jsp e ottenuti con una query XPath tutti i tag "a"
(hyperlink) in essa presenti: ognuno di questi corrisponderà ad un segmento o ad un indice. Invocato il
metodo click() sull'oggetto ClickableElement ottenuto, si ottiene la pagina listino.jsp. Su questa si itera lo
stesso meccanismo, prima a livello di "pager", poi per quanto riguarda i titoli facenti parte della tabella.
Tutte queste operazioni sono inserite in blocchi try / catch / finally per la gestione di eventuali eccezioni. In
particolare, in caso una eccezione di tipo FailingHttpStatusCodeException (la richiesta HTTP restituisce un
codice di errore, ad esempio 500 Internal Server Error), viene fatta fallire una asserzione in modo che
fallisca l'intero TestCase.
Così strutturata, la routine di test ha permesso di individuare alcuni errori nella webapplication. E' dunque in
parte stata utile ad effettuare uno sviluppo guidato dai test (testdriven development), metodologia propria
dell'Extreme Programming (XP) secondo cui il codice viene progressivamente migliorato e corretto al fine di
cercare di superare una suite di test che rappresentano tutte le specifiche.
3.4 Stress test
Un altro test effettuato sulla webapplication realizzata è il test di carico, load test o stress test, che valutano
le prestazioni del server Tomcat per l'elaborazione delle pagine e la trasmissione all'utente, con un carico di
utenza variabile.
Il tool utilizzato per questo scopo è JMeter. Fa parte del progetto Apache Jakarta project e il suo scopo
principale è proprio quello di essere un load testing tool per l'analisi e la misurazione di una moltitudine di
servizi, con un approccio orientato alle webapplications. JMeter può essere usta come unit test per
connessioni JDBC, FTP, LDAP, Webservices, JMS, HTTP e per connessioni TCP generiche. Può essere
anche configurato come monitor, allo scopo di avere una interfaccia grafica con cui tenere sotto controllo lo
stato di salute del server e della connessione.
Nonostante JMeter sia comunemente classificato come un tool di "load generation", questa non è una
descrizione completa. Infatti JMeter supporta diversi meccanismi di asserzione, per assicurare che i dati
ricevuti siano corretti, verificare cookie, variabili di configurazione e una serie di altri test.
Nell'ambiente di sviluppo Netbeans è stato integrato il plugin JMeter, che permette di aggiungere "load
generation scripts" come file di progetto. I file vengono aperti e gestiti esternamente dalla GUI di JMeter
attraverso la quale è possibile configurare in maniera grafica il workbench e i thread group, unità
fondamentali che costituiscono lo script di test.
Lo script implementato, StressTest.jmx, prevede che venga creato un Thread Group che simula la
connessione contemporanea di 20 utenti, con un rampup di 0 secondi (quindi le connessioni iniziano tutte
simultaneamente). Ogni thread richiede al server la pagina index.jsp, effettua una asserzione sulla risposta
ricevuta (deve avere status code HTTP 200) e visualizza i risultati in forma grafica e tabellare.
Ecco una screenshot dello script, con i suoi componenti e i risultati di una sessione di test.
In particolare si è testato il collegamento ad AlphaServer da parte di uno dei client di sviluppo (si veda il
piano di progetto per ulteriori dettagli). La connessione ADSL non permette una grande banda di upload, e
questo giustifica i risultati prestazionali non esaltanti.
Fig 13. stress test
4 Analisi dei costi del software
I costi del software sono dovuti ai requisiti, all'hardware e alle risorse umane. Queste ultime costituiscono il
capitolo principale di costo sul quale sono focalizzate la maggior parte delle tecniche di stima. Il costo di un
progetto dipende dalla sua natura e dalle sue caratteristiche, l’accuratezza della stima dipende invece dalla
quantità di informazioni attendibili che si dispongono circa il prodotto finale. Quando il progetto si trova in
fase iniziale o durante lo studio di fattibilità, abbiamo solo un’idea approssimata delle funzionalità del sistema
e della quantità di informazioni che verranno scambiate. Malgrado queste limitazioni, gli attuali modelli di
stima dei costi forniscono dei dati attendibili ed accurati.
Per questi motivi l’analisi del costo del progetto in questione è stata svolta nella sua fase finale, in modo da
avere a disposizione l’implementazione completa e il maggior numero di informazioni possibili. Il modello
scelto, per la sua diffusione, semplicità ed accuratezza è il COCOMO 81, che rappresenta un punto
d’incontro tra i modelli empirici (Wolverton), quelli statistici (Walston e Felix) e quelli analitici (Putnam,
Halstead).
Rifacendoci allo standard, abbiamo scelto il livello di stima Intermediate, che considera i fattori dell’ambiente
del progetto software in funzione del loro effetto complessivo sui parametri del progetto stesso. Questo,
inoltre, è stato classificato come Organic (applicazioni di limitate dimensioni con requisiti poco stringenti e
ambiente di sviluppo noto), visto il suo ambito accademico e i forti vincoli di tempo a cui è stato sottoposto.
Di seguito è presentata la tabella riepilogativa dei moltiplicatori di sforzo (EM – Effort Multipliers), che
concorrono a costituire il fattore correttivo EAF, dato dal prodotto di tutti gli EM.
Fig 14. tabella riepilogativa moltiplicatori di sforzo
Il valore così calcolato è EAF = 0,9386. Quindi lo “sforzo totale” richiesto per lo sviluppo del software è:
E = EAF ∙ Enom = EAF ∙ a ∙ Sb
dove S è la dimensione del programma in KLOC (Kilo Lines Of Code), e a e b sono fattori stabiliti dallo
standard e schematizzati nella tabella seguente:
Considerati tutti i dati in possesso, quindi, è possibile effettuare le seguenti stime:
E = 0,9386 ∙ 3,20 ∙ 5,3391,05 = 17,44 MM (uominimese)
T = c ∙ Ed = 7,4 mesi (durata totale stimata del progetto)
Il modello fornisce una stima indiretta del costo, dal momento che si concentra principalmente sulle risorse
umane, i cui salari possono variare considerevolmente a seconda del contesto.
Inoltre, nel costo complessivo, dovranno essere considerati quelli inerenti le infrastrutture, l’energia,
l’hardware ed il software utilizzato.
Nel nostro caso, alcuni costi aggiuntivi possono essere, ad esempio, i seguenti:
• aInfoSoft PowerCharts Enterprise: 1999 $
• Hosting Java presso Hosty.it (Tomcat privato, 1 DB MySql 5, banda illimitata): 120€ / anno
5 Utilizzo del sistema
In questa sezione si illustrano le funzionalità del sistema dal punto di vista dell'utente, ponendo l'accento
sull'interfaccia e sui principali casi d'uso. E' da ricordare che il sistema è fruibile da diverse categorie di
utenti, di cui di seguito sono riassunte le caratteristiche:
• Amministratore: può consultare i listini in modalità base, cercare titoli ed accedere al pannello di
controllo, dal quale può controllare l'esecuzione del demone di aggiornamento.
• Guest (utente non loggato): può consultare i listini in modalità base, cercare titoli ed aprire un nuovo
conto AlphaTrading.
• Utente base: consultazione dei listini, ricerca di titoli, gestione del conto e possibilità di effettuare
depositi, bonifici, ed ordini di acquisto/vendita.
• Utente avanzato: tutte le funzioni dell'utente base, con in più la possibilità di gestire un portafoglio
"virtuale", atto a tenere sotto controllo e a simulare le negoziazioni, e di visualizzare il grafico
intraday e l'analisi tecnica dei titoli azionari.
In virtù di questa distinzione, nel prosieguo di questa sezione le funzionalità del sito saranno distinte per
categoria di utente e opportunamente suddivise laddove possibile.
5.1 Amministratore
La pagina fondamentale alla quale l'amministratore del sistema può accedere è il Pannello di Controllo:
Mediante un pulsante a due stati è possibile controllare l'esecuzione del demone di aggiornamento. Quando
questo è attivo, il suo log, riportante tutte le operazioni principali svolte e le eventuali segnalazioni di errore,
viene visualizzato in un'apposito componente Backbase di tipo "listGrid".
Dal momento che la sicurezza è un elemento fondamentale nel sistema in esame, questa pagina è
inaccessibile da parte di utenti non autorizzati. Inoltre, in caso di logout dell'amministratore, il contenuto della
pagina viene automaticamente e dinamicamente aggiornato, presentando un'eloquente messaggio di
accesso negato.
Un meccanismo analogo (reso possibile dagli handler di Backbase con la manipolazione del DOM) è stato
sfruttato in tutte le pagine che necessitano il controllo degli accessi, abilitando solo le parti consentite al
particolare tipo di utente. Ad esempio, per un utente base il grafico dell'analisi tecnica non è visibile, ma lo
diventa non appena si effettua il login come utente avanzato, senza mai effettuare il refresh della pagina.
5.2 Guest
Per gli utenti non registrati al sistema, o che non hanno ancora effettuato il login, la home page del sito si
presenta così:
Si può notare che la barra del menu principale è contextaware, in quanto presenta voci diverse a seconda
della tipologia di utente che visualizza la pagina.
Sulla destra si possono notare i due box per il login, con controllo della correttezza delle credenziali inserite,
e la casella di ricerca dei titoli. Questa è particolarmente utile all'utente in quanto lo assiste nella ricerca
presentandogli una lista di suggerimenti basata sui titoli presenti nel database di AlphaTrading, evitando così
ricerche a vuoto e offrendo all'utente un'interfaccia semplice e intuitiva. Il risultato della ricerca (effettuata sia
sul codice che sul nome esteso del titolo) è un listino simile a quello della figura seguente.
Nel corpo nella pagina e nella barra laterale sono infine presenti i link alle principali notizie finanziarie di
interesse generale, segnalate dal sito Yahoo Finance.
I risultati sono paginati numericamente e inseriti in una tabella arricchita graficamente da un gradevole
effetto di "illuminazione". Clickando su una riga si accede alla pagina di dettaglio del titolo.
Oltre al listino prodotto dalla ricerca, l'utente può ovviamente visualizzare anche l'elenco dei listini
internazionali, suddivisi per Borsa e segmenti:
Sulla destra, all'interno del box, un riepilogo delle variazioni dei principali indici internazionali. L'elenco dei
titoli di ciascun segmento/indice si presenta suddiviso per lettera come in figura.
Oltre a ciò, ovviamente un utente Guest ha due possibilità principali: effettuare il login o registrarsi al sistema
aprendo un nuovo conto.
Una caratteristica comune a tutti i form di AlphaTrading, è l'utilizzo di Ajax per la validazione. Se alcuni campi
non sono riempiti o sono stati immessi valori non validi, questi vengono contrassegnati in rosso e non viene
inviata alcuna richiesta http, evitando così diverse elaborazioni lato server e soprattutto il refresh della pagina
con i consueti messaggi di errore. Una volta completata correttamente la procedura, viene presentata
all'utente una pagina riepilogativa con tutti i dettagli sul suo conto.
5.3 Utente base
Le peculiarità introdotte dal profilo utente 'base' sono la possibilità di effettuare ordini e di conseguenza di
gestire il proprio conto e il portafoglio. All'interno della pagina di dettaglio di un titolo, infatti, tramite l'apposito
box laterale, è possibile specificare il tipo di ordine, l'importo,la quantità e la scadenza dello stesso.
L'ordine verrà preso quindi in consegna dal sistema (che segnalerà la correttezza dell'inserimento in un

popup all'interno della pagina), che ne verificherà periodicamente l'eseguibilità e, in caso affermativo,
realizzerà l'operazione richiesta. Anche in questo caso tutta l'interazione avviene in modo del tutto simile a
quanto succederebbe in un'applicazione desktop, il che si traduce in un vantaggio in termini di tempo, di
traffico http e di comfort per l'utente.
Quando l'utente acquista un titolo, può verificare lo stato del suo portafoglio e visualizzare lo storico degli
ordini da esso inseriti attraverso, appunto, la pagina Portafoglio.
La tabella dei titoli posseduti è del tutto simile a quella della pagina "listino.jsp", mentre lo storico degli ordini
è un componente interattivo Backbase di tipo "accordion".
Inoltre, l'utente può visualizzare i dati riepilogativi del suo conto ed effettuare operazioni di deposito e
bonifico.
5.4 Utente avanzato
Questa fascia d'utenza dispone, oltre che dei servizi offerti a tutti gli utenti registrati, di alcune funzionalità
riservate a traders più esperti e più esigenti. In primo luogo è possibile infatti gestire un "portafoglio virtuale",
sostanzialmente identico nella gestione rispetto al portafoglio reale, ma con alcune piccole differenze. Dal
momento che l'utilità del portafoglio virtuale è esclusivamente quella di "osservare" dei titoli e simulare i
guadagni e le perdite che deriverebbero dalle loro variazioni, l'aggiunta e la rimozione di questi non si riflette
in nessun movimento reale, lasciando immutata la situazione economica dell'utente. Inoltre la quantità
acquistabile virtualmente è fissata ad 1, ma pur con queste restrizioni si ha il vantaggio dell'esecuzione
immediata dell'ordine, senza attendere i consueti tempi del demone.
Per un maggior controllo e per acquisite informazioni aggiuntive sui titoli, l'utente avanzato ha a disposizione
una serie di funzionalità complesse all'interno della pagina di dettaglio dei titoli. Questa è infatti identica a
quella che si presenta agli altri utenti, ma con i grafici in aggiunta.
Oltre alle classiche informazioni su prezzo, denaro, lettera e volumi scambiati, è presente il grafico (in Flash)
dell'andamento intraday, ricavato sulla base delle quotazioni memorizzate nell'arco della giornata dal nostro
demone di aggiornamento (la risoluzione temporale dei valori è quindi di 5 minuti). Posizionandosi su un
punto del grafico è possibile inoltre conoscere l'esatto valore della curva in quel punto. L'aggiornamento del
grafico può essere forzato cliccando sull'apposito pulsante e non richiede il refresh dell'intera pagina.
Subito in basso è presente invece il grafico dedicato all'analisi storica del titolo, controllabile dall'apposito box
in basso a destra nella pagina, che permette di selezionare il periodo da analizzare, il tipo di visualizzazione,
e gli indicatori da visualizzare, fino ad un massimo di 3 contemporaneamente. A scopo illustrativo, si
presentano tutte le voci di menù disponibili:
E' possibile così visualizzare grafici complessi completi di indicatori finanziari per soddisfare le esigenze dei
traders professionisti:
Tipi di visualizzazione: candlestick, a barre, lineare
Grafici di tipo candlestick con indicatori:
6 Installazione del sistema
6.1 Requisiti minimi
● Hardware
• CPU: Pentium III 800 Mhz
• Memoria: 512 MB RAM
• Hard disk: 10 GB
● Software
• OS: cross platform
• Apache Tomcat 6.0.16 with SSL support
• JDK 1.6
• MySQL Server 5.0
• Backbase 4.2.1
• Librerie: MySQL Connector/J 5.1.6
6.2 Procedura d'installazione
● Installazione di tomcat
Esempio di installazione versione più recente di Tomcat:
~$ wget
http://www.apache.org/dist/tomcat/tomcat-6/v6.0.16/bin/apache-
tomcat-6.0.16.tar.gz
~$ tar xzf apache-tomcat-6.0.16.tar.gz
~$ export CATALINA_HOME=~/apache-tomcat-6.0.16
● Configurazione Tomcat (utente, certificati per SSL/HTTPS)
Aggiungere in $CATALINA_HOME/conf/tomcatusers.xml:
<role rolename="manager"/>
<user username="admin" password="admin" roles="manager"/>
● Installazione libreria mysqlconnectorjava
~$ wget http://dev.mysql.com/get/Downloads/Connector-J/mysql-
connector-java-5.1.6.tar.gz
~$ cd $CATALINA_HOME/lib
~/apache-tomcat-6.0.16/lib$ tar xzf ~/mysql-connector-
java-5.1.6.tar.gz
● Deployment di Backbase_4.2.1.war e Trading.war
● Procedura 1 Autodeployment
~$ cp Backbase_4.2.1.war $CATALINA_HOME/webapps
~$ cp Trading.war $CATALINA_HOME/
~$ $CATALINA_HOME/bin/shutdown.sh
~$ $CATALINA_HOME/bin/startup.sh
● Procedura 2 Manager
Connettersi a http://localhost:8080/manager/html, accedere con username e password
admin/admin.
Selezionare i file in "Select WAR file to upload", poi click su Deploy.
● Configurazione connessione HTTPS
● Creazione certificato per Tomcat
~$ cd $JAVA_HOME/bin
~$ keytool -genkey -alias alpha -keyalg RSA -keystore alpha.bin
~$ cp alpha.bin /var/lib/tomcat-6/webapps/
● Configurare Tomcat affinchè usi il certificato
~$ sudo vim <CATALINA_HOME>/conf/server.xml
Inserire il seguente testo:
<Connector port="8443" maxHttpHeaderSize="8192" maxThreads="150"

minSpareThreads="25" maxSpareThreads="75" SSLEnabled="true"
enableLookups="false" disableUploadTimeout="true" scheme="https"
secure="true" clientAuth="false" sslProtocol="TLS"
keystoreFile="/var/lib/tomcat-6/webapps/alpha.bin
keystorePass="alphaserver" />
● Creazione certificato per Tomcat
Nel file web.xml dell'applicazione, aggiungere all'interno del tag <webapp> il seguente
testo:
<security-constraint>
<web-resource-collection>
<web-resource-name>Trading</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
● Installazione MySQL Server (se non già installato)
E' conveniente usare il sistema di pacchettizzazione della propria distribuzione linux. Ad
esempio, in distro debianbased:
# apt-get install mysql-server
● Importazione database alphadb
~$ mysql -u root -p < alphadb_DDL.sql
Password:
~$ mysql -u root -p < alphadb_DATA.sql
Password:
● Creazione utente alphadb:alphadb
~$ mysql -u root -p
Password:
mysql> CREATE USER alphadb IDENTIFIED BY PASSWORD 'alphadb';
Query OK, 0 rows affected
mysql> GRANT ALL PRIVILEGES ON 'alphadb'.* TO 'alphadb'@%
● Configurazione router
In presenza di un router con NAT, verificare che la porta 8080 (8443) abbia l'opportuno
forwarding verso l'IP della rete locale.

AlphaTrading - Relazione Su Implementazione e Test

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AlphaTrading - Relazione Su Implementazione e Test

Uploaded by

Copyright:

Available Formats

Documento di Implementazione

L'ordine verrà preso quindi in consegna dal sistema (che segnalerà la correttezza dell'inserimento in un

<Connector port="8443" maxHttpHeaderSize="8192" maxThreads="150"

mysql> GRANT ALL PRIVILEGES ON 'alphadb'.* TO 'alphadb'@%

You might also like