AlphaTrading - Planning & Design Document

Documento di Progetto
Gruppo Alpha
Andrea Martelli
Emanuele Mottola
Roberto Paolillo
Corso di laurea in Ingegneria Informatica Specialistica
Anno Accademico 2007/2008
Indice
1 Introduzione......................................................................................................................................2
1.1 Principi di progettazione...........................................................................................................2
1.1.1 Principio di apertura e chiusura.........................................................................................2
1.1.2 Principio dell'inversione delle dipendenze........................................................................2
1.1.3 Principio di segregazione delle interfacce.........................................................................2
1.1.4 Principio di singola responsabilità.....................................................................................3
1.1.5 Principio di sostituzione di Liskov....................................................................................3
1.2 Ipotesi semplificative di progetto..............................................................................................3
2 Descrizione statica del sistema.........................................................................................................4
2.1 Diagramma delle classi.............................................................................................................4
2.2 Pattern di progetto.....................................................................................................................9
2.2.1 Pattern DAO......................................................................................................................9
2.2.2 Pattern Strategy...............................................................................................................12
2.2.3 Pattern Singleton.............................................................................................................13
2.2.4 Pattern Flyweight.............................................................................................................16
2.2.5 Pattern Factory Method...................................................................................................17
3 Modellazione dei dati....................................................................................................................17
3.1 Diagramma EntitàRelazione..................................................................................................19
3.2 Schema relazionale.................................................................................................................19
4 Comportamento dinamico del sistema...........................................................................................24
4.1 Casi d'uso principali................................................................................................................24
4.1.1 Ottenimento dei segmenti di una borsa............................................................................27
4.1.2 Esecuzione di un ordine...................................................................................................29
4.2 Schema dellae pagine..............................................................................................................29
5 Componenti.....................................................................................................................................31
5.1 Diagramma dei componenti....................................................................................................31
5.2 Il demone................................................................................................................................33
5.3 Graph applet............................................................................................................................34
6 Deployment....................................................................................................................................34
6.1 Diagramma di deployment......................................................................................................34
6.2 Pattern MVC...........................................................................................................................36
6.3 Considerazioni sulla sicurezza................................................................................................37
6.4 Ottenimento dati borsa............................................................................................................37
Gruppo Alpha Documento di Progetto 1.0 1
1 Introduzione
Il presente documento descrive il progetto del sistema, sia nella parte statica che in quella dinamica.
Il diagramma delle classi, che nel precedente documento di analisi conteneva solo le classi entity, è stato ora
esteso e completato delle altre classi, elencandone i metodi principali.
Al fine di illustrare in maniera trasparente la filosofia e le modalità di progettazione del sistema, si descrivono
e dettagliano tutti i pattern utilizzati, spiegando i motivi che hanno portato alla scelta degli stessi.
Viene inoltre descritta la modellazione dei dati, dal progetto del diagramma EntitàRelazioni allo schema
relazionale.
Per descrivere il comportamento dinamico del sistema se ne sono dettagliati 2 casi d'uso fondamentali, ed è
stato inoltre realizzato un diagramma delle pagine per rendere immediatamente comprensibile lo schema di
navigazione in cui si può muovere l'utente.
Completano la descrizione progettuale del sistema il diagramma delle componenti e il diagramma di
deployment, con il dettaglio del fulcro centrale dell'intero sistema: l'ottenimento dei dati reali delle borse.
1.1 Principi di progettazione
Nello sviluppo del progetto è stata posta sempre grande attenzione sugli aspetti legati alla flessibilità, alla
riusabilità e alla manutenibilità, caratteristiche irrinunciabili in un buon progetto software OO.
In questo i benefici maggiori sono derivati dall'applicazione dei pattern, lo studio e l'analisi di principi generici
di buona progettazione, infine da un notevole sforzo di astrazione. In particolare è stata molto utile la
consultazione del libro "Agile Software Development: Principles, Patterns, and Practices" di Robert Martin,
dal quale si è tratto spunto per discutere brevemente di queste "good practices".
1.1.1 Principio di apertura e chiusura
"Le entità software, come classi, moduli e funzioni devono essere aperte all'estensione ma chiuse alle
modifiche"
È un principio generico da considerare quando ci si vuole assicurare che per estendere il comportamento di
una classe non ci sia bisogno di modificarla internamente, ma sia sufficiente estenderla. Lo stesso principio
può essere applicato a librerie, moduli e package. Così facendo è possibile mantenere la retrocompatibilità
del codice e delle applicazioni, ed è possibile inoltre effettuare test in maniera regressiva. Il principio può
essere applicato utilizzando classi astratte e interfacce. Esempi concreti sono il Template Pattern e lo
Strategy Pattern (da noi utilizzato per la connessione al DB).
1.1.2 Principio dell'inversione delle dipendenze
"I moduli di alto livello non devono dipendere da quelli di basso livello. Entrambi devono dipendere dalle
astrazioni"
"Le astrazioni non devono dipendere dai dettagli, ma dovrebbe avvenire il contrario"
È necessario disaccoppiare i moduli di alto livello da quelli di livello più basso, introducendo un livello di
astrazione tra le classi di alto e basso livello. Inoltre le astrazioni fatte in fase di progetto non devono
dipendere dai dettagli implementativi o di dominio, ma deve avvenire esattamente il contrario. Grazie a
questa separazione, i moduli o le classi diventano intercambiabili, un pò come avviene con le Factories o le
Abstract Factories.
1.1.3 Principio di segregazione delle interfacce
"I clients non devono essere forzati a dipendere da interfacce che non usano"
Le interfacce devono essere autocontenute. Non è corretto inserire metodi inappropriati all'interno di
un'interfaccia, anche perché questo costringerà a implementarli in seguito. La presenza di questi denota una
errata modellazione e individuazione dei compiti delle classi. Interfacce con metodi errati sono dette
"inquinate" o "fat interfaces", e dev'essere quindi buona cura del progettista evitarle.
1.1.4 Principio di singola responsabilità
"Una classe deve avere solo una ragione per cambiare"
In questo contesto una responsabilità è considerata un motivo per cambiare. In pratica se abbiamo due
motivi che possono indurre a modificare una classe, questa dev'essere suddivisa in due classi distinte. In
questo modo ogni singola classe avrà un solo motivo per cambiare, e se si renderà necessario un
cambiamento basterà intervenire sulla classe interessata. Con questa tecnica si realizza quindi una
suddivisione di compiti tra classi, sempre a favore dei principi ispiratori di modularità e manutenibilità.
1.1.5 Principio di sostituzione di Liskov
"I tipi derivati devono essere completamente sostituibili dai loro tipi base"
È un'estensione dell'Open Close principle, e implica il fatto che dobbiamo esser certi che le nuove classi
derivate estendano le classi base senza cambiarne il comportamento. Le nuove classi derivate dovrebbero
quindi essere in grado di sostituire le classi base senza alcun cambiamento nel codice e questo è senz'altro
favorito nel linguaggio Java.
1.2 Ipotesi semplificative di progetto
Rispetto a quanto documentato nelle fasi precedenti del progetto, lo stesso ha subito dei leggeri
cambiamenti dovuti ad una migliorata percezione del dominio di interesse, dei vincoli progettuali e temporali,
e delle previsioni inerenti la fase implementativa.
Sono state quindi assunte alcune ipotesi semplificative, analizzate di seguito:
1) Effetto dell'inserimento di ordini
Quando un utente inserisce un ordine di acquisto o vendita, nel mercato reale, questo ha un effetto
diretto sul valore del titolo azionario in questione, secondo le leggi della domanda e dell'offerta. Oltre
al valore del titolo in sé vi è un altra componente, di interesse più pratico per l'utente, che cambia: il
book del titolo. Questo contiene di solito le cinque migliori offerte di acquisto e vendita, ordinate
rispettivamente in ordine decrescente e crescente, corredate dalla quantità offerta.
Non potendo disporre di questo set di informazioni, difficili da reperire e che implicherebbero
complicazioni troppo pesanti, ci si è limitati a considerare denaro e lettera (che coincidono con i primi
valori del book), e a valutare l'eseguibilità degli ordini solo rispetto a questi.
Inoltre, dal momento che considerare gli effetti dell'inserimento di un ordine solo parzialmente
sarebbe una forzatura, consideriamo i valori di denaro e lettera non influenzabili dagli ordini inseriti
dagli utenti del nostro sistema.
2) Modalità di evasione degli ordini
La seconda questione è legata strettamente alla prima: non avendo a disposizione il book dei titoli,
non è possibile gestire le quantità disponibili per ogni titolo, e di conseguenza considerare la
possibilità di un'esecuzione parziale degli ordini (es.: richiesta di 100 azioni Fiat, ma solo 80
disponibili). In virtù di questo, gli ordini saranno da considerare sempre evasi completamente.
3) Valuta dei conti
Normalmente, a seconda del Paese di appartenenza di un utente, il conto dovrebbe essere gestito
ed espresso nella valuta propria dell'utente stesso. Si considerano, però, tutti i conti espressi in
Euro, che è la valuta di default. Quando l'utente effettua compravendite di titoli non europei, il
sistema consider l'appropriato tasso di cambio per effettuare le transazioni in Euro.
4) Valuta di riferimento
Per evitare ridondanza, il sistema considera e immagazzina soli e tutti i tassi di cambio tra l'Euro e le
altre valute. Avendo a disposizione questi dati, i tassi di cambio tra due generiche valute possono
essere ricavati semplicemente.
2 Descrizione statica del sistema
2.1 Diagramma delle classi
2.2 Pattern di progetto
2.2.1 Pattern DAO
Per garantire la persistenza degli oggetti è stato necessario introdurre delle classi boundary che
consentissero di mappare le classi con le entità del modello relazionale. Per questo compito si è ricorsi ad un
pattern di dettaglio, non facente parte dei pattern della "Gang of Four" ma ampiamente testato e
riconosciuto, al punto da rientrare tra i Core J2EE Patterns. Questi pattern sono specifici per applicazioni
multitier e pensati appositamente per adattarsi ad un ambiente di sviluppo come J2EE. Ciò è infatti possibile
perchè J2EE ha tra le sue prerogative, oltre ovviamente al rispetto del modello MVC, scalabilità,
performance e riutilizzabilità. Proprio in ossequio al modello MVC, questi patterns sono suddivisi tra
Presentation Tier, Businness Tier e Integration Tier Patterns (tra questi ultimi rientra il DAO).
Si è scelto, al fine di garantire in modo efficiente la persistenza degli oggetti entity, il pattern Data Access
Object in modo da gestire in maniera centralizzata sia il recupero dei dati dal database che l'aggiornamento,
la creazione e la cancellazione.
L'interfaccia DAO infatti espone quattro metodi fondamentali:
● Create, per l'inserimento nel database di un oggetto appena creato
● Retrieve, per l'ottenimento di un oggetto memorizzato nel DB
● Update, per l'aggiornamento dei dati di un oggetto esistente
● Delete, per la cancellazione dal DB di un oggetto esistente
Questi quattro metodi sono meglio noti in letteratura come "interfaccia CRUD" e rappresentano un modo
semplificato per gestire la persistenza degli oggetti nel DB.
Ogni altra query che è necessario porre al DB, relativamente ad un dato oggetto entity, è inoltre eseguita da
un metodo nell'oggetto DAO. Per questo motivo gli oggetti DAO rappresentano il singolo punto d'accesso del
sistema al database, garantendo una maggiore modularità e manutenibilità, nonché una perfetta
applicazione del modello MVC.
In particolare si è posto, come vincolo progettuale, che le query che è necessario porre al DB restituiscano
un solo campo, restituito in forma di array come valore di ritorno del metodo. Ciò è accettabile considerato
che le uniche query di tale tipo sono quelle necessarie a ricostruire le relazioni tra gli oggetti mappati nel DB
in memoria: saranno dunque necessari solo metodi che restituiscano i valori delle chiavi esterne di ogni
entità, in modo da stabilire come costruire le composizioni di oggetti.
Ognuno di questi metodi utilizza un oggetto JDBC di tipo PreparedStatement che, rispetto al classico
Statement, garantisce tempi di esecuzione nettamente minori.
Il DAO, se applicato in contemporanea ad un pattern Abstract Factory, permette inoltre di rendere
trasparente al sistema la scelta del database utilizzato (relazionale, ad oggetti, flat files ecc.). È possibile
anche l'utilizzo congiunto con i Transfer Objects che consentirebbero, in caso di oggetti DAO localizzati in
un ambiente distribuito, di ridurre il numero di chiamate ai metodi accessors (getters e setters) per
valorizzare gli attributi.
2.2.2 Pattern Strategy
Il pattern Strategy definisce una famiglia di algoritmi, incapsulando ciascuno di essi in una classe, e li rende
intercambiabili. Questo pattern consente ad un client di utilizzare un dato servizio indipendentemente
dall'algoritmo con cui esso è realizzato. Inoltre il pattern trova applicazione nel definire un metodo di
connessione al database. Esso consente di utilizzare dei differenti approcci di connessione, mediante stringa
JDBC o risorsa JNDI (Java Naming and Directory Interface), con unica connessione condivisa o con un pool
di connessioni disponibili.
2.2.3 Pattern Singleton
Per alcune delle strategies implementate per l'oggetto DBConnector è necessario garantire che venga
restituita una singola istanza dell'oggetto JDBC Connection. A questo scopo viene realizzato il pattern
Singleton, il quale garantisce che un oggetto abbia una singola istanza esistente.
Il pattern prevede l'utilizzo di un attributo di tipo static (per l'oggetto Connection) e un metodo anch'esso
static che restituisca l'oggetto se questo è stato già istanziato, mentre lo istanzi se questo non è ancora stato
creato.
È da notare che una versione assai simile a questa è utilizzata dal pattern Flyweight nel suo metodo
getElemento di FlyweightFactory, allo scopo di verificare se un oggetto Flyweight è già stato istanziato.
2.2.4 Pattern Flyweight
Come illustrato precedentemente, quando viene richiamato il getter relativo ad un oggetto facente parte di
una composizione, come ad esempio Segmento.getTitoli(), gli oggetti Titolo vengono istanziati e inseriti nella
lista che implementa la composizione (Segmento.titoli).
Nel realizzare queste composizioni molto spesso si vengono a creare delle gerarchie cicliche: ad esempio gli
Indici sono composti da serie di Titoli, e questi fanno riferimento ad una Borsa.
Per le esigenze di progetto si è chiaramente reso necessario che queste relazioni siano verso istanze
univoche di oggetti, in modo tale da evitare così la ridondanza dei dati e contestualmente garantendo che
questi siano sempre consistenti e aggiornati, senza necessità alcuna di implementare complessi (in questo
caso) meccanismi come quello del pattern Observer.
A giustificare ulteriormente questa scelta vi è il fatto che gli oggetti di tipo Titolo sono molto numerosi nel
sistema, nell'ordine delle seimila unità, considerando l'elenco titoli delle tre borse implementate. Risulterebbe
quindi assai dispendioso ipotizzare che questi oggetti vengano duplicati quando inseriti in composizioni
differenti, come Segmento e Indice.
È chiaro come in questa circostanza il pattern Flyweight è di grande aiuto. Esso implementa infatti un
meccanismo di condivisione degli oggetti, in modo da gestirne efficientemente un gran numero a granularità
fine. In questo caso gli oggetti sono quelli facenti parte delle composizioni (Titoli, soprattuto).

Citando la GoF:
“The Flyweight pattern is often combined with the Composite pattern to implement a logically hierarchical
structure in terms of a directedacyclic graph with shared leaf nodes.”
La scelta progettuale adottata è dunque quella di realizzare una struttura gerarchica avente i nodi foglia
condivisi. In pratica vengono definiti degli oggetti di tipo Elenco, che mantengono la lista degli oggetti già
istanziati e ne consentono sia l'accesso che la creazione in modo unitario e centralizzato.
Un nuovo Titolo nel sistema viene istanziato solo mediante chiamata al metodo ElencoTitoli.getTitolo che,
prima di istanziare un nuovo oggetto e recuperare il suo contenuto dal DB mediante TitoloDAO, verifica nella
sua lista che non ci sia già lo stesso oggetto e nel qual caso lo restituisce.
Questo meccanismo permette di avere a disposizione in ogni pagina JSP la rappresentazione del suo
"mondo", ovvero tutte le entità interessate, e di poter ottenere in caso di necessità tutte le informazioni
correlate ad esse, seguendo semplicemente le gerarchie o le associazioni tra classi.
2.2.5 Pattern Factory Method
Gli oggetti di tipo Elenco sono creati a partire da una superclasse comune: ElencoCompleto.
L'implementazione dei loro metodi è comune in tutto a parte che nel tipo di oggetto da creare e restituire, nel
caso in cui l'oggetto richiesto non è presente nella lista di quelli già istanziati; ed è proprio per questo motivo
viene utilizzato il pattern Factory Method.
Esso è realizzato rendendo ElencoCompleto una classe astratta che implementa tutti i metodi a parte proprio
il factory method.
Quest'ultimo viene dunque implementato nelle classi derivate da ElencoCompleto (ElencoTitoli,
ElencoBorse, ElencoSegmenti e ElencoIndici), e non fa altro che istanziare un oggetto del tipo
corrispondente e restituirlo.
Così facendo si è garantito il massimo riuso del codice, realizzando quattro classi con la stessa
implementazione che fungono da factory per oggetti di tipo differente.
Bisogna sottolineare che non sarebbe stato possibile ottenere lo stesso risultato utilizzando i costrutti
generics di Java (templates per C++), in quanto non è possibile istanziare un oggetto avente un tipo
indeterminato individuabile solo a runtime.
Inoltre è da evidenziare come il metodo getElemento utilizza in parte il pattern Template Method, che è
usato spesso in congiunzione con il Factory Method.
3 Modellazione dei dati
3.1 Diagramma EntitàRelazioni
Come si può osservare comparando il diagramma delle classi “precedente” inserito nel documento di analisi
con il modello ER, lo schema del database rispecchia abbastanza fedelmente l’impostazione strutturale data
in quella fase. É evidente che il lavoro di analisi del dominio e di progettazione svolto nelle due distinte fasi si
è quindi rivelato coerente ed efficace, portando senza particolari difficoltà al modello finale del sistema.
La struttura del DB ricalca inoltre la suddivisione effettuata nella descrizione degli attori del sistema, dove è
stata fatta una distinzione (a scopo puramente semplificativo) tra DB Titoli e DB Utenti. Si possono infatti
individuare due macro aree all’interno del diagramma ER, l’una interessante i titoli, le borse e tutte le
informazioni “statiche” ad essi collegate, l’altra interessante gli utenti con i loro conti e ordini.
Inoltre è rilevante notare il parallelismo tra entità/tabelle del DB ed Entities del diagramma delle classi, che
sono in buona parte sovrapponibili.
La gestione dei dati persistenti e il collegamento tra classi e database sono realizzati utilizzando il pattern
DAO, approfondito nell’apposita sezione.
Sono necessarie alcune precisazioni sullo schema del DB:
● Titolo: rappresenta non solo i titoli azionari, ma anche i tassi di cambio tra le valute (la valuta di
riferimento è l’Euro) e i valori riassuntivi degli indici. Considerazione analoga va fatta ovviamente per
Quotazione.
● Titolo posseduto: rappresenta i portafogli dell’utente (Azioni, Valute, Virtuale). La distinzione tra
azioni e valute viene fatta sulla base dell’associazione a Titolo, ed inoltre il flag virtuale indica se il
titolo è presente nel portafoglio virtuale o in quello reale. Questi vengono gestiti in modo molto simile
pur con alcune differenze sulla gestione e l’esecuzione degli ordini.
● Conto: per ragioni di coerenza dei dati e di ridondanza, il conto di ogni utente non contiene
direttamente l’informazione sul credito disponibile, ma viene ricavata quando richiesta analizzando
tutti i movimenti precedenti relativi a quel conto realizzati in passato (incluso un eventuale
versamento iniziale).
Il DBMS utilizzato per l'applicazione è MySQL della Sun Microsystem, Open Source, multipiattaforma e
dotato di buone prestazioni.
Le connessioni al DB possono essere effettuate usando diverse strategie (Standard, Pooled e mediante
Jdni), con differenti tradeoff tra semplicità di realizzazione e prestazioni.
3.2 Schema relazionale
Il presente schema fornisce una visione più "concreta" di come appare il DB progettato, descritto dal
precedente schema. Sono visibili in particolare le tabelle associative per le relazioni nm e i vincoli di chiave
esterna che implementano le relazioni 1n.
4 Comportamento dinamico del sistema
4.1 Casi d'uso principali
4.1.1 Ottenimento dei segmenti di una borsa
Il diagramma successivo schematizza un caso tipico di interazione tra classi all'interno del sistema.
Osservando anche il diagramma delle classi si può notare la presenza di un motivo ricorrente: la richiesta di
un Elenco che gestisce l'ottenimento dei suoi componenti tramite il loro Data Access Object in maniera
ottimizzata. Entrando più nel dettaglio, nella fattispecie l'utente richiede la visualizzazione di tutti i segmenti
di una Borsa contraddistinta da un codice. Viene quindi richiesto l'elenco delle Borse all'oggetto Elenchi (che
è un pool di flyweight), e tramite questo viene ottenuto l'oggetto della Borsa in questione; qualora questo non
fosse stato precedentemente instanziato, viene caricato dal DB utilizzando BorsaDAO). Di seguito vengono
quindi ottenuti tutti i segmenti della borsa in questione e inseriti nell'altro flyweight, ElencoSegmenti. Ora
quindi gli oggetti sono disponibili per l'elaborazione o la visualizzazione mediante pagina JSP.
Schemi analoghi vanno considerati per altre azioni tipiche che coinvolgono oggetti di tipo
ElementoConCodice ed Elenco, come la richiesta di tutte le Borse, degli indici tipici di un mercato, dei titoli di
un segmento o di quelli facenti parte di un dato indice. La modellazione delle classi ha permesso quindi la
creazione di un ambiente uniforme che permette, una volta appreso lo schema base di funzionamento, di
sfruttare in maniera semplice, e anche abbastanza ripetitiva, la maggior parte delle funzioni del sistema.
4.1.2 Esecuzione di un ordine
Questo rappresenta senza dubbio il processo più importante e più complesso dell'intero sistema. Essendo
un'operazione di routine, e che necessita di tutti i privilegi possibili, è svolta dal Demone ad intervalli di
tempo regolari, come descritto in seguito.
Quando un utente inserisce un ordine di acquisto o vendita di un generico titolo, questo non viene eseguito
immediatamente neanche nel caso in cui ciò sarebbe teoricamente possibile, ma viene inserito nel database
come ordine pendente. È quindi il demone a verificare periodicamente la soddisfacibilità degli ordini e ad
eseguirli quando possibile.
Il flusso delle operazioni prevede l'ottenimento di tutti i Conti degli utenti, e la loro interrogazione per ottenere
gli Ordini di ognuno. Quindi il demone verifica l'eseguibilità di ogni ordine controllando l'ultima quotazione del
titolo interessato, l'apertura o la chiusura del segmento di riferimento, l'eventuale avvenuta scadenza
dell'ordine. Se tutti i controlli vanno a buon fine, l'ordine viene eseguito restituendo il TitoloPosseduto e
generando un opportuno Movimento che influenza il valore del Conto.
4.2 Schema delle pagine
Il diagramma seguente fornisce una visione completa dei possibili cammini di navigazione effettuabili dagli
utenti, in base alle loro credenziali (base, avanzato, amministratore) e alle condizioni che si verificano di volta
in volta, in modo da evidenziare rapidamente e in maniera visivamente efficace le principali funzionalità
offerte.
5 Componenti
5.1 Diagramma dei componenti
Il diagramma dei componenti può essere rappresentato con diversi livelli di dettaglio.
L'approccio scelto è stato di suddividere le classi entity e control in componenti aggregati e successivamente
esplicitare le relazioni tra questi componenti e quelli esterni al sistema, quali:
● librerie software, marcate con lo stereotipo <<library>>;
● sistemi esterni autonomi, come applicazioni client o server; per questi si è usato lo stereotipo
<<external system>> ;
● file, linkati o elaborati a runtime, che contengono parte della logica (come il layer di presentazione e
l'interfaccia grafica): lo stereotipo utilizzato è <<file>> .
5.2 Il demone
Il componente che racchiude al suo interno la maggior parte della business logic del sistema è quello che
abbiamo chiamato Demone. Il nome deriva proprio dalla funzione che esso ricopre, in analogia a quanto
accade in generale nei sistemi di tipo Unix. Questo è, infatti, un thread eseguito in background e non sotto il
diretto controllo dell'utente. Nella fattispecie, l'ambiente in cui il demone viene eseguito è il web server
Apache, e l'unico utente che può interagire con esso è l'amministratore del sistema, il quale ha a
disposizione un pannello di controllo (realizzato con apposita interfaccia web) accessibile dall'interno del sito
di TOL e che gli consente una serie di operazioni, tra le quali: avviare, fermare, controllare lo stato del
demone, leggerne il file di log, etc.
Le due operazioni fondamentali che il processo esegue ad intervalli di tempo regolari e prefissati (ma
modificabili dall'amministratore) saranno:
● Aggiornamento delle quotazioni intraday
Il demone ottiene l'elenco dei segmenti aperti nel momento dell'esecuzione e per ognuno di essi
l'elenco dei titoli. Quindi si interfaccia al fornitore dei dati di borsa (Yahoo Finance) ed effettua il
download delle quotazioni a blocchi, in modo da ottimizzare il numero di connessioni e richieste
HTTP necessarie al completamento. Contestualmente, inserisce i dati ottenuti all'interno del
database, che contiene quindi lo storico intraday delle quotazioni. Un meccanismo analogo, ma
differente solo in alcuni piccoli dettagli implementativi, viene utilizzato per aggiornare i tassi di
cambio delle valute internazionali.
● Verifica ed esecuzione degli ordini
Subito dopo aver aggiornato le quotazioni, il demone prende in esame gli ordini pendenti inseriti
dagli utenti. Questo perché le compravendite non sono immediate, ma vengono effettuate solo
quando determinate condizioni sono verificate. Iil demone consulta quindi il DB per ottenere la lista
di ordini, per ognuno di essi verifica l'eseguibilità (mercato aperto, disponibilità economica
dell'utente, valutazione di denaro o lettera, ecc..) e, in caso affermativo, esegue le seguenti azioni:
1. inserimento del record opportuno nel portafoglio dell'utente interessato
2. aggiornamento del conto dell'utente tramite la generazione di un movimento, che tiene conto della
quantità acquistata e dell'eventuale tasso di cambio
3. rimozione dell'ordine pendente dal database
Il meccanismo di gestione degli ordini riguardanti titoli azionari e valute è identico, in quanto queste ultime si
possono gestire in tutto e per tutto come normali azioni.
È chiaro quindi che le funzioni svolte dal demone sono quelle su cui si basa l'intero sistema. Proprio per
questa ragione, questo componente è sviluppato in modo da essere il più possibile ottimizzato e tollerante
agli errori, gestendo in maniera adeguata tutte le eccezioni per evitare che il processo si interrompa.
5.3 Graph applet
Per la visualizzazione dei grafici di analisi tecnica si utilizza un Applet Java al posto di semplici immagini
statiche. In questo modo si evita di dover gestire la generazione e la cancellazione delle immagini
temporanee, si offre inoltre all'utente un'interfaccia molto più interattiva che non risente dei problemi di
refresh tipici delle pagine HTML.
I grafici permettono all'utente di selezionare gli indicatori e le elaborazioni da visualizzare e sfruttano come
fonte dati il servizio storico di Yahoo Finance. La comunicazione tra l'applet, residente sul client, e il server, a
cui è demandato il compito di ottenere gli andamenti delle quotazioni, è realizzata col sistema RMI (Remote
Method Invocation) di Java. Questa tecnica consente di realizzare applicazioni distribuite invocando metodi
di oggetti remoti, referenziati tramite un registry, in maniera trasparente all'utente.
La applet è realizzata mediante JFreeChart, una libreria Java Open Source che consente di generare una
grande quantità di grafici, sia in 2D che in 3D, partendo da una fonte di dati.
6 Deployment
6.1 Diagramma di deployment
6.2 Pattern MVC
Il ModelViewController, tradotto in italiano ModelloVistaControllore, è un pattern architetturale molto
diffuso in sistemi software objectoriented che si sovrappone all'architettura a livelli threetier.
Si è scelto di modellare il sistema mediante lo schema MVC perché l'intento di questo pattern è di
disaccoppiare il più possibile tra loro le parti dell'applicazione adibite al controllo, all'accesso ai dati e alla
presentazione.
Aver utilizzato rigidamente questo approccio ha portato ad innegabili vantaggi come:
• indipendenza tra i business data (model) la logica di presentazione (view) e quella di controllo
(controller);
• separazione dei ruoli e delle relative interfacce
• viste diverse per il medesimo model
• il semplice supporto per nuove tipologie di client: bisogna scrivere la vista ed il controller appropriati
riutilizzando il model esistente.
Il pattern è quindi basato sulla separazione dei componenti software che interpretano i ruoli principali.
Di seguito vengono elencati nello specifico quelli adottati in questo progetto:
● model: classi entity, JavaBean;
● presentazione dati (view): classi JSP, JSTL, HTML con CSS, AJAX per le quotazioni, Applet e RMI;
● control: core logic implementata dal demone, servlets per inserimento ordini
6.3 Considerazioni sulla sicurezza
In un sistema di trading on line, in cui sono coinvolte transazioni finanziarie e dati riservati degli utenti, la
sicurezza riveste certamente un ruolo fondamentale. Per ottemperare a queste necessità, nell'ambito di
questo progetto sono stati considerati alcuni sistemi per migliorare la sicurezza delle comunicazioni.
In primo luogo, le password degli utenti vengono inviate al server e memorizzate non in chiaro, cosa che
esporrebbe il sistema ad attacchi del tipo "man in the middle" e ad un'elevata criticità dell'accesso al DB da
parte di utenti non autorizzati, ma cifrate mediante l'algoritmo di hashing MD5.
Al login, quindi, l'hash della password immessa viene confrontato con quello in possesso del database. In
questo modo, inoltre, anche l'estrema ipotesi di un accesso non autorizzato al database non
comprometterebbe l'usabilità delle password, dal momento che gli hash sono irreversibili.
Inoltre, tutte le comunicazioni tra client, e quindi browser, e server, sfruttano un canale di comunicazione
sicuro creato grazie al protocollo HTTPS (Hypertext Transfer Protocol over Secure Socket Layer). Questo è in
buona sostanza un URI sintatticamente identico allo schema http:// ma con la differenza che gli accessi
vengono effettuati sulla porta 443 e che tra il protocollo TCP e HTTP si interpone un livello di
crittografia/autenticazione (SSL o TLS). È
Il web server dispone quindi di un certificato che permette l'autenticazione e la cifratura delle comunicazioni,
e grazie ai due accorgimenti appena descritti il rischio di violare l'integrità e la riservatezza dei dati sensibili è
drasticamente ridotto.
6.4 Ottenimento dati borsa
La caratteristica di maggior pregio, nonché il pilastro dell'intero sistema oggetto del progetto, è l'utilizzo di
dati reali di borsa.
Sono stati presi in considerazione tre mercati azionari fra i più importanti al Mondo: la Borsa Italiana, il
London Stock Exchange e il Nasdaq, oltre al mercato delle valute. Per ognuno di essi è stato realizzato
l'elenco reale dei titoli quotati, la loro reale suddivisione in segmenti e indici, gli orari di apertura e le festività.
Una volta completato l'inserimento nel DB di queste informazioni che vengono considerate statiche dal
momento che cambiano a intervalli di tempo relativamente lunghi, è stata effettuata un'attenta analisi del
servizio Yahoo Finance. Qui si è scoperta la possibilità di interrogare direttamente il database di Yahoo
tramite query string passate al server tramite URL (quindi su protocollo HTTP).
In questo modo è possibile ottenere le quotazioni intraday ritardate di 20 minuti. I dati restituiti sono in forma
di file di testo in formato ".csv" (Comma Separated Values) e per questo molto leggeri, il che ha permesso di
ottimizzare molto le procedure di download dei dati, basti pensare che le quotazioni dei circa 7000 titoli
presenti nel DB vengono ottenute in un tempo mediamente inferiore ai 10 secondi utilizzando una comune
linea ADSL. L'alternativa a questa modalità di ottenimento dei dati sarebbe stato un ben più impegnativo e
lento parsing delle pagine web.
È ora opportuno evidenziare un cambiamento di strategia rispetto a quanto delineato in fase di analisi.
Inizialmente infatti era stata prevista la realizzazione dello storico delle quotazioni per poter disporre di una
base dati sulla quale effettuare l'analisi tecnica, altrimenti impossibile.
Questa idea è stata abbandonata successivamente alla scoperta del fatto che il servizio Yahoo Finance
mette a disposizione, in modo simile a quanto descritto per le quotazioni intraday, anche i dati storici dei titoli,
risalenti a periodi molto antecedenti la data di questo progetto, il che è certamente un grosso vantaggio.
È evidente quindi che non è necessaria la realizzazione del database storico, ma è possibile reperire i dati,
quando necessari, direttamente da Yahoo Finance, soluzione a nostro avviso assai conveniente sotto molti
punti di vista.

AlphaTrading - Planning & Design Document

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AlphaTrading - Planning & Design Document

Uploaded by

Copyright:

Available Formats

Documento di Progetto

You might also like

AlphaTrading - Planning &amp; Design Document

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AlphaTrading - Planning &amp; Design Document

Uploaded by

Copyright:

Available Formats

Documento di Progetto

You might also like

AlphaTrading - Planning & Design Document

AlphaTrading - Planning & Design Document