Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

32
ASTErix Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza

Transcript of Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

Page 1: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

ASTErixIngegneria del software L-A

Luca BettelliSara Cristoni

Matteo Pozza

Page 2: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

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.

Page 3: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

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.

Page 4: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

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.

Page 5: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

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.

Page 6: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

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.

Page 7: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

Casi d’uso: Gestione Aste

Page 8: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

Casi d’uso: Elenco Aste

Page 9: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

Scenario 1: Crea AstaDescrizione Un utente venditore vuole creare un’asta per vendere un oggetto.

Relazioni Autenticazione, Gestione Aste, Carica immagine

Attori Utente

Precondizioni L’utente deve essersi autenticato nel sistema

Scenario principale

1.1. L’utente specifica i dati dell’oggetto che vuole vendere fornendo il nome, la descrizione, il valore stimato, scegliendo una categoria tra quelle presenti nel sistema e può caricare una immagine.1.2. Il sistema verifica che tutti i dati siano stati forniti e che il valore stimato sia un numero valido.1.3. L’utente specifica la data e ora di inizio e fine dell’asta e l’ammontare dei rialzi.1.4. Il sistema verifica che le date e ore fornite siano valide e successive alla data e ora attuale e che il valore stimato sia un numero valido.1.5. Il sistema invia al Data Base remoto i dati dell’oggetto e i parametri dell’asta.

Scenari alternativi

1.2.a. L’utente non ha inserito tutti i dati Il sistema comunica all’utente che servono tutti i dati per proseguire.1.4.a. L’utente non ha inserito una data successiva a quella attuale o la data di fine asta precede la data di inizio Il sistema comunica all’utente di inserire una data corretta.1.4.b. L’utente ha inserito un valore stimato minore di 0 o non numerico Il sistema comunica all’utente che ha inserito un numero errato.1.5.a. Il Data Base remoto non è raggiungibile Il sistema comunica all’utente che l’operazione non può essere portata a termine.

Page 10: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

Scenario 2: Rimuove Asta

Descrizione Un utente venditore vuole eliminare un’asta.

Relazioni Gestione Aste, Autenticazione

Attori Utente

Precondizioni L’utente deve essersi autenticato nel sistema

Scenario principale

2.1. L’utente seleziona un’asta da rimuovere.2.2. Il sistema chiede conferma all’utente.2.3. La richiesta di rimozione viene eseguita sul Data Base remoto, quindi l’asta e i relativi dati vengono rimossi.

Scenari alternativi

2.1.a. L’asta che l’utente vuole rimuovere è in corso Il sistema comunica all’utente che non è possibile rimuovere un’asta in corso.2.2.a. L’utente non conferma la rimozione L’asta non viene rimossa.2.3.a. Il Data Base remoto non è raggiungibile Il sistema comunica all’utente che l’operazione non può essere portata a termine.

Page 11: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

Scenario 3: Propone Offerta

Descrizione L’utente stabilisce un importo per un’asta in corso.

Relazioni Gestione Aste, Autenticazione

Attori Utente

PrecondizioniL’utente deve essersi autenticato nel sistema.L’asta deve essere in corso.L’asta non deve essere stata creata dall’utente stesso.

Scenario principale

3.1. L’utente inserisce l’importo desiderato.3.2. Il sistema chiede conferma all’utente.3.3. Il sistema controlla che l’offerta sia superiore alla massima offerta finora proposta più il rialzo e che l’asta non sia conclusa.3.4. La nuova offerta viene salvata sul Data Base remoto.

Scenari alternativi

3.2.a. L’utente non conferma l’inserimento dell’importo L’importo non viene inserito.3.3.a. L’utente ha inserito un importo non numerico o inferiore alla massima offerta finora proposta più il rialzo Il sistema comunica all’utente di inserire un importo superiore all’importo attuale più il rialzo.3.3.b. L’asta è conclusa Il sistema comunica all’utente che l’asta si è conclusa e che non vengono accettate ulteriori offerte.3.4.a. Il Data Base remoto non è raggiungibile Il sistema comunica all’utente che l’operazione non può essere portata a termine.

Page 12: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

Scenario 4: Visualizza Aste InseriteDescrizione Il sistema mostra le categorie disponibili e le aste presenti nella categoria selezionata

Relazioni Autenticazione, Elenco Aste

Attori Utente

Precondizioni L’utente deve essersi autenticato nel sistema

Scenario principale

4.1. Il sistema mostra le categorie disponibili leggendole dal Data Base remoto.4.2. L’utente seleziona la categoria di suo interesse.4.3. Il sistema mostra le aste disponibili all’interno della categoria selezionata.4.4. L’utente seleziona un’asta tra quelle disponibili.

Scenari alternativi

4.1.a. Il Data Base remoto non è raggiungibile o l’operazione non viene terminata completamente Il caricamento delle aste non può essere eseguito: l’applicazione viene terminata per evitare che vengano eseguite operazioni su un elenco di aste inconsistente.4.3.a. All’interno della categoria non sono presenti aste Il sistema segnala all’utente che non ci sono aste presenti nella categoria.4.4.a. Al momento della selezione l’asta non è più disponibile Il sistema comunica all’utente che l’asta non è più disponibile.

Page 13: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

Diagramma delle classi di analisiDiagramma di sequenza

Seconda parte

Page 14: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

Diagramma delle classi di analisi

Page 15: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

Diagramma delle classi di analisiNote: 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.

Page 16: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

Diagramma di sequenzaInvio di una offerta al server:

Page 17: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

Diagramma di sequenzaRicezione di una offerta dal server:

Page 18: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

Fase di progettazioneDesign pattern e principi di progettazione

Terza parte

Page 19: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

Fase 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.

Page 20: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

Diagramma classe Asta

Page 21: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

Diagramma classe Oggetto

Page 22: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

Diagramma classe Categoria

Page 23: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

Diagramma classe Offerta

Page 24: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

Diagramma Viste

Page 25: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

Diagramma Controller

Page 26: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

Servizi Aggiornamento DB

Page 27: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

Diagramma classe Program

Page 28: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

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.

Page 29: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

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. ImmagineFactory crea una delle due sottoclassi di IImmagine in base al valore della stringa URL passata al metodo statico GetImmagine().

Pattern flyweight: ImmagineDefault viene 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).

Page 30: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

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

Page 31: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

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

Page 32: Ingegneria del software L-A Luca Bettelli Sara Cristoni Matteo Pozza.

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