Download
1 / 32
320 likes | 530 Views
Ingegneria del software L-A. ASTErix. Introduzione. Si richiede di realizzare il client di un sistema per la gestione della compravendita di oggetti all’asta.
E N D
Ingegneria del software L-A ASTErix
Introduzione • Si richiede di realizzare il client di un sistema per la gestione della compravendita di oggetti all’asta. • Collegandosi ad un server remoto, il client deve permettere ad un utente autenticato di visualizzare le aste inserite da altri utenti, creare nuove aste e proporre offerte al rialzo sulle aste in corso. • Il server notificherà in tempo reale le modifiche avvenute sulle aste, in modo che tutti i client collegati possano mostrare le attività degli altri utenti che usufruiscono contemporaneamente del servizio.
Documento dei requisiti • Gli utenti che intendono usufruire dei servizi offerti dal sistema devono essere registrati. Per ciascun utente il sistema conserva il nome, il cognome, l’indirizzo e-mail e la password scelta; l’indirizzo e-mail e la password verranno richiesti all’utente ogni volta che egli intende autenticarsi nel sistema. • L’autenticazione, la registrazione e le modifiche effettuale dall’utente autenticato sulle aste presenti nel client, verranno inviate dal client stesso ad un Data Base remoto. Un server remoto osserverà le modifiche al Data Base remoto e notificherà tutti i client in tempo reale.
Documento dei requisiti • L’utente può creare un’asta specificando una data e ora di inizio e fine e l’ammontare dei singoli rialzi. Ogni asta mantiene inoltre il prezzo attuale di vendita raggiunto. Per ogni asta l’utente può vendere un solo oggetto, costituito da un nome, una sola categoria di appartenenza, una descrizione dettagliata, un valore stimato ed eventualmente una immagine. • Le immagini degli oggetti vengono inserite nel sistema dall’utente che ha definito l’oggetto. Se all’oggetto non è stata assegnata una immagine il sistema provvede ad associare all’asta un’immagine di default. • Le categorie (caratterizzate da un nome) raggruppano oggetti con caratteristiche comuni. Sono predefinite nel sistema. • Gli utenti possono proporre un’offerta per un’asta solo dopo che l’asta è iniziata e solo se non hanno già fatto l’ultima offerta per l’asta. Il prezzo attuale dell’asta, quando questa inizia, coincide con il valore stimato dell’oggetto in vendita.
Documento dei requisiti • L’utente che intende proporre un’offerta per un’asta deve dichiarare un importo pari o superiore al prezzo attuale più il rialzo specificato dal venditore. L’utente può altrimenti dichiarare un importo pari al prezzo iniziale dell’oggetto associato solamente se è il primo utente ad effettuare offerte per quell’asta. • Alla fine dell’asta si aggiudica il relativo oggetto l’utente che ha fatto l’ultima offerta: sarà il server a notificare all’utente venditore l’esito dell’asta e l’eventuale nominativo dell’utente compratore che si è aggiudicato l’oggetto. In questo modo l’utente venditore potrà contattare personalmente l’utente compratore per il pagamento e la spedizione dell’oggetto. • Se un utente compratore si è aggiudicato l’asta, l’oggetto risulta venduto, quindi l’asta e l’oggetto relativo vengono automaticamente rimossi dal Data Base remoto; in caso contrario il venditore potrà scegliere se rimuovere l’asta o se riproporre l’asta reimpostando la data e l’ora di inizio e fine.
Documento dei requisiti • Ogni utente può vedere le aste inserite nel sistema filtrandole in base alla categoria in cui l’oggetto è stato inserito dal venditore. • Gli utenti venditori hanno a disposizione un elenco vendite, che mostra l’andamento delle aste sui suoi oggetti (evidenziando per tutte le aste iniziate il prezzo attuale di vendita). • L’utente compratore che ha proposto una o più offerte per almeno un oggetto in vendita all’asta, ha a disposizione un registro offerte, che mostra il prezzo attuale per gli oggetti a cui è interessato.
Seconda parte Diagramma delle classi di analisiDiagramma di sequenza
Diagramma delle classi di analisi Note: • La classe Asta contiene le informazioni inerenti all’asta che possono variare nel tempo (ad esempio il prezzo attuale). • La classe Periodo contiene la data e ora di inizio e fine dell’asta e permette di ricavare la durata complessiva dell’asta e il tempo rimanente in base alla data e ora attuali. • L’Oggetto è associato univocamente ad un’asta e non può essere modificato. L’immagine in esso contenuta, a seconda di cosa è stato scelto dall’utente, può essere ImmagineDaUrl o ImmagineDefault. • L’ImmagineDaUrl contiene un link ad un’immagine esterna. • L’ImmagineDefault viene utilizzata nel caso in cui l’URL non sia stato indicato dall’utente o se l’URL non corrisponde ad un’immagine valida. • La classe Categoria è un aggregato di oggetti ed è usata per raggrupparli quando devono essere visualizzati. • La classe Utente mantiene le informazioni relative ad un utente del sistema. • La classe Offerta associa un’asta ad un Utente che ha proposto un’offerta.
Diagramma di sequenza Invio di una offerta al server:
Diagramma di sequenza Ricezione di una offerta dal server:
Terza parte Fase di progettazioneDesign pattern e principi di progettazione
Il server (che non fa parte del progetto) mantiene le informazioni relative ad aste e offerte all’interno di un Data Base e si occupa di inviare notifiche ai client in seguito a modifiche avvenute sulla base di dati. Il client riceve le notifiche del server attraverso un Controller, che a sua volta invoca le funzioni necessarie all’aggiornamento del Model. Il Model scatena degli eventi a cui le View sono registrate, in modo da mostrare le variazioni in tempo reale. I Gestori sono componenti ausiliari usati dal client per inviare i dati sul Data Base del server. Fase di progettazione
Pattern Singleton Il pattern singleton ha permesso di evitare che le classi ElencoOfferte, ElencoAste ed ElencoCategorie venissero istanziate più di una volta, generando inconsistenze nel modello e difficoltà di aggiornamento.
Pattern Flyweight e Factory • In base alle specifiche di progetto, l’oggetto in vendita all’asta può non avere un’immagine associata. In tal caso il sistema deve associare all’asta un’immagine di default. • Pattern factory: la classe Oggetto mantiene un riferimento all’interfaccia IImmagine, implementata dalle due sottoclassi ImmagineDaUrl e ImmagineDefault. ImmagineFactorycrea una delle due sottoclassi di IImmagine in base al valore della stringa URL passata al metodo statico GetImmagine(). • Pattern flyweight: ImmagineDefaultviene creata una sola volta da ImmagineFactory e ne viene restituito il riferimento a tutti gli Oggetti che la richiedono. ImmagineDefaultè istanziabile soltanto da ImmagineFactory (perché annidata e privata), e viene condivisa simultaneamente da più clienti indipendenti tra loro (classi Oggetto).
Pattern MVC Per separare più facilmente le responsabilità delle varie classi del progetto si è pensato di suddividere l’applicazione seguendo un modello simile all’MVC
Pattern MVC • Il Model è composto da ElencoAste, ElencoOfferte e ElencoCategorie e contiene tutte le operazioni necessarie per aggiungere e rimuovere aste e offerte dagli elenchi. Le modifiche al modello scatenano gli eventi che possono essere intercettati dalle viste registrate. • Le classi AsteInserite, RegistroOfferte, ElencoVendite e DettagliAsta rappresentano il blocco View dello schema. Si occupano di mostrare le aste che rispondono ai requisiti di progetto e reagiscono agli eventi scatenati dalle classi del Model. • Il Controller riceve le notifiche dal server e invoca le funzioni delle classi del Model per modificarne lo stato (ad esempio aggiungendo una nuova asta ad ElencoAste). • Le classi GestioneAste, GestioneOfferte e GestioneAutenticazione fanno parte del blocco dei Gestori e si occupano di gestire la comunicazione da e per il Data Base (ad esempio, durante la fase di autenticazione, l’e-mail e la password vengono inviati al DB tramite una query, e il risultato dell’operazione determina l’accesso al programma).
Principio di inversione delle dipendenze • Per disaccoppiare il Server dal Client è stata aggiunta l’interfaccia IController, implementata da ControllerConcreto. • Questo accorgimento rende il client più flessibile e indipendente dalle modifiche eseguite sul server. • Inoltre, affiancando o sostituendo ControllerConcreto con altre classi che implementano IController, è possibile ricevere le notifiche attraverso diversi mezzi di comunicazione (via TCP/IP, usando .NET Remoting, interrogando il server in polling, ecc.).
