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 retro­compatibilità  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   auto­contenute.   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.

Gruppo Alpha ­ Documento di Progetto ­ 1.0

2 

 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 Gruppo Alpha ­ Documento di Progetto ­ 1.0

3 

Gruppo Alpha ­ Documento di Progetto ­ 1.0

4 

Gruppo Alpha ­ Documento di Progetto ­ 1.0

5 

Gruppo Alpha ­ Documento di Progetto ­ 1.0

6 

 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  multi­tier 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).

Gruppo Alpha ­ Documento di Progetto ­ 1.0

7 

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.

Gruppo Alpha ­ Documento di Progetto ­ 1.0

8 

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. Gruppo Alpha ­ Documento di Progetto ­ 1.0

9 

 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 directed­acyclic graph with shared leaf nodes.” La scelta progettuale adottata è dunque quella di realizzare una struttura gerarchica avente i nodi foglia  Gruppo Alpha ­ Documento di Progetto ­ 1.0

10 

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   super­classe   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 run­time. 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

Gruppo Alpha ­ Documento di Progetto ­ 1.0

11 

Gruppo Alpha ­ Documento di Progetto ­ 1.0

12 

 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   trade­off   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 n­m e i vincoli di chiave  esterna che implementano le relazioni 1­n.

Gruppo Alpha ­ Documento di Progetto ­ 1.0

13 

Gruppo Alpha ­ Documento di Progetto ­ 1.0

14 

 4  Comportamento dinamico del sistema  4.1  Casi d'uso principali

Gruppo Alpha ­ Documento di Progetto ­ 1.0

15 

Gruppo Alpha ­ Documento di Progetto ­ 1.0

16 

 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.

Gruppo Alpha ­ Documento di Progetto ­ 1.0

17 

Gruppo Alpha ­ Documento di Progetto ­ 1.0

18 

 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.

Gruppo Alpha ­ Documento di Progetto ­ 1.0

19 

Gruppo Alpha ­ Documento di Progetto ­ 1.0

20 

 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 <>; ● 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 è <> .

Gruppo Alpha ­ Documento di Progetto ­ 1.0

21 

Gruppo Alpha ­ Documento di Progetto ­ 1.0

22 

 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 intra­day 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 intra­day 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.

Gruppo Alpha ­ Documento di Progetto ­ 1.0

23 

 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

Gruppo Alpha ­ Documento di Progetto ­ 1.0

24 

Gruppo Alpha ­ Documento di Progetto ­ 1.0

25 

 6.2  Pattern MVC Il   Model­View­Controller,   tradotto   in   italiano   Modello­Vista­Controllore,   è   un   pattern   architetturale   molto  diffuso   in   sistemi   software   object­oriented   che   si   sovrappone   all'architettura   a   livelli   three­tier. 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

Gruppo Alpha ­ Documento di Progetto ­ 1.0

26 

 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.

Gruppo Alpha ­ Documento di Progetto ­ 1.0

27