Sei sulla pagina 1di 47

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 on­line.......................................................................................................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 client­server...................................................................................................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

Gruppo Alpha ­ Documento di Implementazione – 1.0 2 
 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 on­line 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
on­line 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. 

Gruppo Alpha ­ Documento di Implementazione – 1.0 3 
 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 on­line
• 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 multi­thread open­source.
• 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.

Gruppo Alpha ­ Documento di Implementazione – 1.0 4 
 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

Gruppo Alpha ­ Documento di Implementazione – 1.0 5 
 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 client­server, 
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 look­and­feel 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 back­end 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 ­ Multi­Page 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. 

Gruppo Alpha ­ Documento di Implementazione – 1.0 6 
Fig 3. aggiornamento delle pagine in applicazioni web “tradizionali”

Fig 4. aggiornamento delle pagine in ambiente AJAX/Backbase

Gruppo Alpha ­ Documento di Implementazione – 1.0 7 
 2.3.1  Architettura client­server
Quella client­server è 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  
drag­and­drop, 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.

Gruppo Alpha ­ Documento di Implementazione – 1.0 8 
 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).

Gruppo Alpha ­ Documento di Implementazione – 1.0 9 
Gruppo Alpha ­ Documento di Implementazione – 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   Modello­Vista­Controllore   (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. 

Gruppo Alpha ­ Documento di Implementazione – 1.0 11 
 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

Gruppo Alpha ­ Documento di Implementazione – 1.0 12 
 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.

Gruppo Alpha ­ Documento di Implementazione – 1.0 13 
 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à

Gruppo Alpha ­ Documento di Implementazione – 1.0 14 
 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.

Gruppo Alpha ­ Documento di Implementazione – 1.0 15 
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(); 
    }

Gruppo Alpha ­ Documento di Implementazione – 1.0 16 
 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

Gruppo Alpha ­ Documento di Implementazione – 1.0 17 
 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

Gruppo Alpha ­ Documento di Implementazione – 1.0 18 
 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 desktop­like 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 desktop­like
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 web­application.

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

Gruppo Alpha ­ Documento di Implementazione – 1.0 19 
 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   tag­library,   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 (Web­application Archive).
Anche   Backbase   contribuisce   alla   portabilità,   rendendo   l'applicazione   cross­browser   (come   più   volte 
evidenziato).

Riassumendo:
Adattabilità alla macchina Vasta grazie all'utilizzo dell'architettura Java
Adattabilità al software La web­application è cross­browser, 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à

Gruppo Alpha ­ Documento di Implementazione – 1.0 20 
 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.

Gruppo Alpha ­ Documento di Implementazione – 1.0 21 
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

Gruppo Alpha ­ Documento di Implementazione – 1.0 22 
 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   web­application,   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 web­application.

 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";

Gruppo Alpha ­ Documento di Implementazione – 1.0 23 
        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   user­agent   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 web­application. E' dunque in 
parte stata utile ad effettuare uno sviluppo guidato dai test (test­driven 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.

Gruppo Alpha ­ Documento di Implementazione – 1.0 24 
 3.4  Stress test
Un altro test effettuato sulla web­application 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   web­applications.   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 ramp­up 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

Gruppo Alpha ­ Documento di Implementazione – 1.0 25 
 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

Gruppo Alpha ­ Documento di Implementazione – 1.0 26 
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 (uomini­mese) 
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 

Gruppo Alpha ­ Documento di Implementazione – 1.0 27 
 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:

Gruppo Alpha ­ Documento di Implementazione – 1.0 28 
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.

Gruppo Alpha ­ Documento di Implementazione – 1.0 29 
 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ì:

Gruppo Alpha ­ Documento di Implementazione – 1.0 30 
Si può notare che la barra del menu principale è context­aware, 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.

Gruppo Alpha ­ Documento di Implementazione – 1.0 31 
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:

Gruppo Alpha ­ Documento di Implementazione – 1.0 32 
Gruppo Alpha ­ Documento di Implementazione – 1.0 33 
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.

Gruppo Alpha ­ Documento di Implementazione – 1.0 34 
Oltre a ciò, ovviamente un utente Guest ha due possibilità principali: effettuare il login o registrarsi al sistema 
aprendo un nuovo conto.

Gruppo Alpha ­ Documento di Implementazione – 1.0 35 
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.

Gruppo Alpha ­ Documento di Implementazione – 1.0 36 
 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.

Gruppo Alpha ­ Documento di Implementazione – 1.0 37 
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.

Gruppo Alpha ­ Documento di Implementazione – 1.0 38 
Gruppo Alpha ­ Documento di Implementazione – 1.0 39 
Gruppo Alpha ­ Documento di Implementazione – 1.0 40 
 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.

Gruppo Alpha ­ Documento di Implementazione – 1.0 41 
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.

Gruppo Alpha ­ Documento di Implementazione – 1.0 42 
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

Gruppo Alpha ­ Documento di Implementazione – 1.0 43 
Grafici di tipo candlestick con indicatori:

Gruppo Alpha ­ Documento di Implementazione – 1.0 44 
Gruppo Alpha ­ Documento di Implementazione – 1.0 45 
 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/tomcat­users.xml:
<role rolename="manager"/>
<user username="admin" password="admin" roles="manager"/>

● Installazione libreria mysql­connector­java
~$ 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.

Gruppo Alpha ­ Documento di Implementazione – 1.0 46 
● 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  <web­app> 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 debian­based:
# 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.

Gruppo Alpha ­ Documento di Implementazione – 1.0 47