Ingegneria del software l a
This presentation is the property of its rightful owner.
Sponsored Links
1 / 32

ASTErix PowerPoint PPT Presentation


  • 79 Views
  • Uploaded on
  • Presentation posted in: General

Ingegneria del software L-A. ASTErix. 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.

Download Presentation

ASTErix

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Ingegneria del software l a

Ingegneria del software L-A

ASTErix

Luca Bettelli

Sara Cristoni

Matteo Pozza


Introduzione

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

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 requisiti1

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 requisiti2

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 requisiti3

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.


Casi d uso gestione aste

Casi d’uso: Gestione Aste


Casi d uso elenco aste

Casi d’uso: Elenco Aste


Scenario 1 crea asta

Scenario 1: Crea Asta


Scenario 2 rimuove asta

Scenario 2: Rimuove Asta


Scenario 3 propone offerta

Scenario 3: Propone Offerta


Scenario 4 visualizza aste inserite

Scenario 4: Visualizza Aste Inserite


Diagramma delle classi di analisi diagramma di sequenza

Seconda parte

Diagramma delle classi di analisiDiagramma di sequenza


Diagramma delle classi di analisi

Diagramma delle classi di analisi


Diagramma delle classi di analisi1

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

Diagramma di sequenza

Invio di una offerta al server:


Diagramma di sequenza1

Diagramma di sequenza

Ricezione di una offerta dal server:


Fase di progettazione design pattern e principi di progettazione

Terza parte

Fase di progettazioneDesign pattern e principi di progettazione


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.

Fase di progettazione


Diagramma classe asta

Diagramma classe Asta


Diagramma classe oggetto

Diagramma classe Oggetto


Diagramma classe categoria

Diagramma classe Categoria


Diagramma classe offerta

Diagramma classe Offerta


Diagramma viste

Diagramma Viste


Diagramma controller

Diagramma Controller


Servizi aggiornamento db

Servizi Aggiornamento DB


Diagramma classe program

Diagramma classe Program


Pattern singleton

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

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


Pattern mvc

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 mvc1

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

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


  • Login