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

AlphaTradinghttp://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 IntroduzioneIl 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, ancheonline 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 utilizzatiDurante 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.


http://www.gliffy.com/

http://www.assembla.com/

ftp://alphaserver.selfip.org/

http://docs.google.com/RawDocContents?docID=dd7vsjdz_11f4n2zvgq&justBody=false&revision=_latest&timestamp=1215985427822&editMode=true&strip=true

http://groups.google.it/

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 BackbaseAJAX è 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).


Gru

ppo

Alp

ha

Doc

umen

to d

i Im

plem

enta

zion

e –

1.0

10

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 motorecostruisce 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 getXmlLogpublic 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 v3Nel 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 ISOTradizionalmente, 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 BackbaseTab 2. usabilità

3.1.3 Affidabilità ed efficienzaIl 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 immediatoTab 5. portabilità


3.2 MetricheUno 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.


http://www.dmst.aueb.gr/dds/sw/ckjm/doc/metric.html

http://www.kclee.de/clemens/java/javancss/


Classe Funzioni NCSS CBO (Ce) CCN MC WMC RFC LCOM Ca NPMajaxProxy 4 28 0 10 5 2,50 21 10 0 2AnalisiTecnica 14 204 1 77 14 5,50 37 1 1 13Andamento 30 109 2 36 30 1,20 50 0 1 29Borsa 11 37 8 15 11 1,36 27 27 5 11BorsaDAO 14 134 4 40 14 2,86 38 0 3 13Conto 38 172 7 70 37 1,84 76 402 8 37ContoDAO 24 269 4 83 24 3,46 60 0 3 23DAO 4 4 0 4 4 1,00 4 6 11 4DAOconCodice 1 1 1 1 1 1,00 1 0 9 1DBConnector 2 10 0 5 3 2,50 9 1 13 3Demone 10 97 1 30 12 3,00 47 28 5 10ElementoConCodice 5 9 0 5 6 1,00 8 9 11 6Elenchi 10 22 4 11 11 1,10 16 31 6 11ElencoBorse 2 5 5 2 2 1,00 6 1 1 2ElencoCompleto 8 24 2 11 8 1,38 19 2 4 8ElencoIndici 2 5 5 2 2 1,00 6 1 2 2ElencoSegmenti 2 5 5 2 2 1,00 6 1 2 2ElencoTitoli 5 51 6 14 5 2,80 36 10 6 5FornitoreDati 9 171 5 58 9 6,44 81 36 1 6getMovimentiXml 4 24 2 5 5 1,25 28 10 0 2getXmlLog 4 27 1 5 5 1,25 22 10 0 2Indice 12 32 7 13 12 1,08 22 46 3 12IndiceDAO 10 57 3 22 10 2,20 31 19 2 9ListaTitoli 1 1 0 1 1 1,00 1 0 1 1Login 7 24 1 13 7 1,86 12 0 1 7Movimento 15 34 1 15 15 1,00 19 83 3 15MovimentoDAO 8 47 3 13 8 1,63 40 6 2 7ordina 4 50 13 10 5 2,50 44 10 0 2Ordine 26 59 9 27 26 1,04 34 289 5 26OrdineDAO 9 84 7 18 9 2,00 60 0 3 8Quotazione 12 23 1 12 13 1,00 15 64 6 13QuotazioneAzione 20 45 3 21 21 1,05 24 184 7 21QuotazioneAzioneDAO 9 92 4 23 9 2,56 65 14 2 8QuotazioneValuta 6 17 3 7 7 1,17 10 9 5 7QuotazioneValutaDAO 9 70 4 24 9 2,67 53 14 2 8Searcher 5 14 3 6 5 1,20 13 2 0 5Segmento 10 27 5 11 10 1,10 21 21 5 10SegmentoDAO 12 84 3 30 12 2,50 34 14 3 11Titolo 13 38 7 17 13 1,31 24 54 7 13TitoloDAO 12 136 7 38 12 3,17 71 28 2 11TitoloPosseduto 20 44 1 20 20 1,00 25 158 4 20TitoloPossedutoDAO 11 106 3 26 11 2,36 55 0 2 9Updater 10 190 22 64 10 6,40 114 33 2 6Utente 17 39 3 17 17 1,00 24 106 4 17UtenteDAO 11 88 4 26 11 2,36 42 5 2 10Valori medi 10,49 62,42 4 21,33 10,73 1,99 32,24 38,78 3,67 9,96

3.3 Unit TestL'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 AlphaTradingNel 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 AlphaTradingimport 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); } } } catch (FailingHttpStatusCodeException e) { assertTrue(false); } } } catch (FailingHttpStatusCodeException e) { 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 testUn 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 softwareI 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 sistemaIn 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 AmministratoreLa 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 GuestPer 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 baseLe 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 avanzatoQuesta 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 tomcatEsempio 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.sqlPassword:~$ mysql -u root -p < alphadb_DATA.sqlPassword:

● Creazione utente alphadb:alphadb~$ mysql -u root -pPassword:mysql> CREATE USER alphadb IDENTIFIED BY PASSWORD 'alphadb';Query OK, 0 rows affected

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

● Configurazione routerIn presenza di un router con NAT, verificare che la porta 8080 (8443) abbia l'opportuno forwarding verso l'IP della rete locale.


http://techtracer.com/2007/09/12/setting-up-ssl-on-tomcat-in-3-easy-steps/#

AlphaTrading - Relazione su Implementazione e test

Documents

Transcript of AlphaTrading - Relazione su Implementazione e test