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.
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 email 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.
Casi d’uso: Gestione Aste
Casi d’uso: Elenco Aste
Scenario 1: Crea Asta
Descrizione
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
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.
Scenario principale 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.
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
2.1. L’utente seleziona un’asta da rimuovere.
2.2. Il sistema chiede conferma all’utente.
Scenario principale
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.
Scenario 3: Propone Offerta
Descrizione
L’utente stabilisce un importo per un’asta in corso.
Relazioni
Gestione Aste, Autenticazione
Attori
Utente
Precondizioni
L’utente deve essersi autenticato nel sistema.
L’asta deve essere in corso.
L’asta non deve essere stata creata dall’utente stesso.
3.1. L’utente inserisce l’importo desiderato.
3.2. Il sistema chiede conferma all’utente.
Scenario principale 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.
Scenario 4: Visualizza Aste Inserite
Descrizione
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
4.1. Il sistema mostra le categorie disponibili leggendole dal Data Base remoto.
4.2. L’utente seleziona la categoria di suo interesse.
Scenario principale
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.
Seconda parte
Diagramma delle classi di analisi
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 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.
Diagramma classe Asta
Diagramma classe Oggetto
Diagramma classe Categoria
Diagramma classe Offerta
Diagramma Viste
Diagramma Controller
Servizi Aggiornamento DB
Diagramma classe Program
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. 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
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.).
