Altra Tesina - Progettoatena.It
Altra Tesina - Progettoatena.It
Altra Tesina - Progettoatena.It
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Università degli Studi di Modena e Reggio Emilia<br />
Facoltà di Ingegneria<br />
Corso di Laurea in Ingegneria Informatica<br />
<strong>Tesina</strong> di Ingegneria del Software<br />
Gestione di una<br />
rosticceria<br />
di<br />
Fabio Zanella<br />
Matr. 1598
Capitolo 1.............................................................................................................................................3<br />
SRS: Specifiche del Problema .........................................................................................................3<br />
Capitolo 2.............................................................................................................................................6<br />
Activity Diagram..............................................................................................................................6<br />
2.1 Commesso..............................................................................................................................6<br />
2.2 Ordinazione............................................................................................................................7<br />
Capitolo 3.............................................................................................................................................8<br />
Use case diagram .............................................................................................................................8<br />
3.1 Diagramma degli attori ..........................................................................................................8<br />
3.2 Utente Generico .....................................................................................................................9<br />
3.3 Direttore .................................................................................................................................9<br />
3.4 Commesso............................................................................................................................10<br />
3.5 Ordinazione..........................................................................................................................11<br />
3.6 Scorte ...................................................................................................................................11<br />
3.7 Diagramma delle interfacce .................................................................................................12<br />
Capitolo 4...........................................................................................................................................13<br />
Class diagram.................................................................................................................................13<br />
4.1 Package diagram ..................................................................................................................13<br />
4.2 Varie.....................................................................................................................................13<br />
4.3 Persone.................................................................................................................................14<br />
4.4 Prodotti.................................................................................................................................15<br />
4.5 Ordinazioni ..........................................................................................................................16<br />
Capitolo 5...........................................................................................................................................17<br />
Sequence diagram ..........................................................................................................................17<br />
5.1 Registrazione Utente Generico ............................................................................................17<br />
5.2 Accesso al sistema informativo............................................................................................18<br />
5.3 Gestione Cliente...................................................................................................................19<br />
5.4 Consulta Menù .....................................................................................................................20<br />
Capitolo 6...........................................................................................................................................21<br />
State diagram .................................................................................................................................21<br />
6.1 Ordinazione..........................................................................................................................21<br />
Capitolo 7...........................................................................................................................................23<br />
Data Flow diagram.........................................................................................................................23<br />
7.1 Ricerca .................................................................................................................................23<br />
Capitolo 8 Bibliografia.......................................................................................................................24<br />
2
Capitolo 1<br />
SRS: Specifiche del Problema<br />
Per la raccolta delle specifiche del problema è stato adottato lo standard IEEE Std 830-1998.<br />
Tale standard si propone di fornire delle linee guida per la specifica dei requisiti del software che<br />
deve essere sviluppato.<br />
1. Introduzione<br />
1.1. Scopo. Si vuole progettare un sistema informativo di ausilio nella gestione di una<br />
rosticceria.<br />
1.2. Campo di validità. Il sistema si deve occupare di mantenere un archivio degli utenti che<br />
possono accedervi (compresi i relativi privilegi), di gestire le ordinazioni dei pasti e la loro<br />
relativa consegna a domicilio.<br />
1.3. Definizioni e abbreviazioni.<br />
Utenti del sistema informativo: sono tutti coloro che possono accedervi (naturalmente ve ne<br />
sono diverse categorie con diritti differenti).<br />
Clienti della rosticceria: sono tutte le persone che usufruiscono dei servizi della rosticceria.<br />
Utenti registrati: sono utenti che sono già stati precedentemente registrati nell’archivio della<br />
rosticceria e che quindi sono possessori di un account che li identifica in modo univoco.<br />
L’account è descritto da due abbreviazioni (UserId, Pwd) che verranno spesso utilizzate per<br />
indicare rispettivamente user identifier e password di un utente registrato (o comunque<br />
quelli che vengono utilizzati per la registrazione).<br />
Utenti generici: sono utenti che, non essendo mai stati registrati, non possono essere<br />
oggetto di controllo da parte della direzione della rosticceria, quindi è loro consentito un<br />
tipo di accesso molto ristretto che consente di ottenere soltanto informazioni sui prodotti<br />
venduti dalla rosticceria, ma non consente loro di effettuare ordinazioni.<br />
Prodotto: In questo documento, con questo termine si fa riferimento a qualsiasi articolo<br />
messo in vendita, quindi sia a prodotti alimentari come pastasciutta, pollo fritto e bevande.<br />
Commesso: Persona col compito di ricevere le ordinazioni dei clienti venuti al locale e dei<br />
clienti che telefonano. Dovrà, inoltre, essere in grado di fornire tutte le informazioni<br />
relative ai prodotti.<br />
1.4. Referenze. Il software è completamente nuovo quindi non vi sono referenze degne di nota.<br />
2. Descrizione generale.<br />
2.1. Funzioni. Il software fornirà le seguenti funzioni:<br />
• Archivio dei clienti. Tale archivio conterrà le informazioni necessarie per la consegna a<br />
domicilio dei pasti.<br />
• Accesso al sistema informativo: si deve fare in modo che l’accesso al sistema sia<br />
consentito a chiunque (registrato o meno), quindi il sistema deve essere di facile accesso,<br />
allo stesso tempo però si deve fare in modo che ciascun utente possa compiere solo le<br />
operazioni che gli sono consentite, quindi deve esserci anche un accesso sicuro al<br />
sistema. Nel momento in cui un utente necessiterà di maggiori informazioni e/o di dover<br />
compiere determinate operazioni non consentite a tutti, questi dovrà registrarsi.<br />
• Archivio dei pasti e delle loro caratteristiche: questo tipo di archivio serve per soddisfare<br />
al meglio le richieste dei clienti. Di ogni pasto devono essere descritti gli ingredienti al<br />
fine di evitare un’intolleranza alimentare da parte da parte del consumatore (glutine,<br />
latticini, uova, …).<br />
• Ricerca su ogni tipo di informazione: deve essere data la possibilità di effettuare ricerche<br />
su tutti i prodotti e offerte disponibili, a partire da qualsiasi informazione disponibile per<br />
un qualsiasi prodotto.<br />
3
• Gestione delle ordinazioni: ogni ordinazione può essere richiesta da utenti locali o<br />
remoti (solo se registrati) tramite web o tramite telefono contattando il commesso della<br />
rosticceria.<br />
• Gestione reclami sui prodotti venduti.<br />
• Gestione delle scorte dei prodotti in vendita.<br />
2.2. Utenti.<br />
• Utente Generico: al fine di garantire l’integrità e la protezione dei dati l’accesso<br />
dell’utente generico è particolarmente ristretto. È consentita soltanto la consultazione del<br />
menù. Nel caso in cui l’utente voglia effettuare una ordinazione deve registrarsi e<br />
compilare il form relativo alla richiesta del pasto oppure rivolgersi al commesso<br />
personalmente o per telefono.<br />
• Pubblico: una volta che l’utente generico si registra ottenendo un account diviene un<br />
utente pubblico. Grazie alla registrazione l’utente ottiene privilegi superiori rispetto a<br />
quelli di un utente generico, infatti oltre a poter fare tutto ciò che può fare l’utente<br />
generico può in più eseguire ordinazioni.<br />
• Commessi: vengono registrati come utenti del sistema informativo all’atto<br />
dell’assunzione. Questa registrazione consente loro di avere particolari privilegi nei<br />
confronti del sistema informativo e quindi di poter compiere tutte quelle operazioni che<br />
rientrano nelle loro mansioni quali l’inserimento/cancellazione delle ordinazioni dei<br />
pasti, calcolo dei conti.<br />
• Direttore: possiede tutti i privilegi dei dipendenti precedenti in più gode di privilegi<br />
supplementari quali quelli di poter aggiornare il listino prezzi, di gestire il personale<br />
(assunzioni, licenziamenti) e revocare gli account.<br />
3. Requisiti del software.<br />
3.1. Requisiti funzionali.<br />
3.1.1. Requisito #1<br />
3.1.1.1.Introduzione. Inserimento di un cliente nel database.<br />
3.1.1.2. Input. Dati anagrafici del cliente:<br />
3.1.1.2.1. Nome e cognome<br />
3.1.1.2.2. Un account (UserId, Pwd) che li identifica in modo univoco<br />
3.1.1.2.3. Domicilio (per le consegne)<br />
3.1.1.2.4. Numero di telefono<br />
3.1.1.2.5. Acquisti effettuati (per eventuali statistiche).<br />
3.1.1.3. Processing. Il sistema controlla che la persona non sia già stata inserita fra i<br />
clienti della rosticceria, nel qual caso inserisce tutti i dati.<br />
3.1.1.4. Output. Messaggio di conferma dell’avvenuto inserimento oppure messaggio<br />
d’errore.<br />
3.1.2. Requisito #2<br />
3.1.2.1.Introduzione. Consultazione Menù.<br />
3.1.2.2. Input. account (UserId, Pwd)<br />
3.1.2.3.Processing. Il menù contenente i prodotti in vendita e le offerte disponibili deve<br />
essere visualizzabile come elenco con le principali informazioni per ogni voce:<br />
codice, nome, disponibilità, prezzo.<br />
3.1.2.4.Output. Di ogni voce del menù deve essere possibile visualizzare le informazioni<br />
dettagliate selezionandola dall'elenco.<br />
3.1.3. Requisito #3<br />
3.1.3.1. Introduzione. Funzioni di ricerca.<br />
3.1.3.2. Input: termini della ricerca.<br />
3.1.3.3. Processing. Deve essere data la possibilità di effettuare ricerche su tutti i prodotti<br />
e offerte, a partire da qualsiasi informazione disponibile per un qualsiasi prodotto.<br />
I termini di ricerca sono forniti tramite una stringa (lista di parole) contenente<br />
4
tutte le parole che devono essere cercate. Ciascuna parola viene cercata in tutti i<br />
campi descrittivi di un prodotto e un prodotto corrisponde nella ricerca se sono<br />
presenti tutte le parole cercate.<br />
3.1.3.4. Output: codice, nome, disponibilità, prezzo di ogni prodotto risultante dalla<br />
funzione di ricerca.<br />
3.1.4. Requisito #4<br />
3.1.4.1. Introduzione. Operazione di ordinazione.<br />
3.1.4.2. Input. Tipo di pasto, numero di pasti.<br />
3.1.4.3. Processing. Selezionando gli articoli durante la consultazione del menù, o dei<br />
risultati di una ricerca, deve essere possibile registrare una ordinazione di un<br />
cliente che sia stato già registrato nell'anagrafe clienti. In ogni momento,<br />
dell'ordinazione devono essere visualizzabili il prezzo totale e i prodotti che la<br />
compongono con i rispettivi prezzi.<br />
3.1.4.4. Output. Il prezzo totale deve essere calcolato tenendo automaticamente conto di<br />
eventuali offerte riguardanti il cliente che sta facendo l'ordinazione o riguardanti i<br />
prodotti che compongono l'ordinazione. Quindi deve essere garantito che il costo<br />
totale calcolato sia il più basso possibile per quel cliente e quell'insieme di<br />
prodotti ordinati, senza la necessità di selezionare esplicitamente le offerte<br />
disponibili per quei prodotti.<br />
3.1.5. Requisito #5<br />
3.1.5.1. Introduzione. Gestione delle scorte dei prodotti in vendita.<br />
3.1.5.2.Processing. Il software dovrà fornire gli strumenti per il mantenimento delle<br />
informazioni sulle scorte dei prodotti in vendita.<br />
3.1.6. Requisito #6<br />
3.1.6.1. Introduzione. Inserimento Reclamo.<br />
3.1.6.2.Input: Ordinazione già avvenuta, descrizione reclamo.<br />
3.1.6.3.Processing. Il software dovrà permettere la registrazione dei reclami, riferiti a<br />
ordinazioni esistenti, da parte dei clienti.<br />
3.1.7. Requisito #7<br />
3.1.7.1. Introduzione. Gestione Reclami.<br />
3.1.7.2.Input: Prodotto.<br />
3.1.7.3.Processing. Il software dovrà permettere la gestione dei reclami consentendo di<br />
consultarli e cancellarli.<br />
3.1.7.4.Output. Reclami associati al prodotto.<br />
3.1.8. Requisito #8<br />
3.1.8.1. Introduzione. Statistiche varie.<br />
3.1.8.2. Input.<br />
3.1.8.3. Processing. Il software dovrà fornire gli strumenti per il mantenimento delle<br />
informazioni riguardanti:<br />
• Prodotti con più reclami.<br />
• Consegne effettuate da ciascun fattorino<br />
• Clienti serviti da ciascun commesso.<br />
5
Capitolo 2<br />
Activity Diagram<br />
2.1 Commesso<br />
Il commesso usa il software per caricare le informazioni fornite dal cliente, effettuare<br />
ricerche per rispondere alle richieste e registrare le ordinazioni. Queste sono tutte attività<br />
indipendenti l'una dall'altra, ed è possibile eseguirle in qualsiasi ordine ed eventualmente passare da<br />
una all'altra in ogni momento.<br />
Commesso<br />
Ricevi informazioni sul cliente<br />
Registra ordinazione<br />
[richiede informazioni]<br />
[nuovo cliente]<br />
Consulta esito ordinazione<br />
Consulta informazioni<br />
Registra cliente<br />
[conferma ordinazione]<br />
[rifiuta ordinazione]<br />
Accetta ordinazione<br />
Cancella ordinazione<br />
Figura 2-1 Activity Diagram: Commesso<br />
6
2.2 Ordinazione<br />
In Figura 2-2, si rappresentano le attività che vengono svolte per soddisfare una nuova ordinazione<br />
di un cliente.<br />
Le colonne nella figura (dette corsie), identificano le aree di azione del software:<br />
• Gestione Ordinazioni: l'ordinazione può essere presa in considerazione se il prodotto è<br />
disponibile. Quando l'ordinazione è confermata, viene presa da un cuoco (per la<br />
preparazione).<br />
• Gestione Amministrativa: mentre viene preparato il pasto viene preparata anche la fattura.<br />
• Gestione Scorte: riguarda la gestione delle scorte dei prodotti, ovvero il controllo del loro<br />
stato con l’eventuale richiesta di nuove scorte nel caso di bassa disponibilità delle stesse.<br />
• Gestione Consegne: le consegne vengono effettuate da un fattorino.<br />
Gestione Ordinazioni<br />
Gestione<br />
Consegne<br />
Gestione<br />
Amministrativa<br />
Gestione<br />
Scorte<br />
Ricevi Ordine<br />
Verifica Ordine<br />
[non valida]<br />
[confermata]<br />
Cancella Ordine<br />
Prepara Ordine<br />
Prepara Scontrino<br />
Aggiorna Scorte<br />
[Scorte Scarse]<br />
Rinnova Scorte<br />
Consegna<br />
Incasso<br />
Figura 2-2 Activity Diagram: Ordinazione<br />
7
Capitolo 3<br />
Use case diagram<br />
3.1 Diagramma degli attori<br />
Il diagramma degli attori ci permette di poter meglio identificare tutti i possibili utenti del<br />
sistema.<br />
Attore<br />
Operatore Esterno<br />
Utente Generico<br />
Fornitore<br />
Utente Registrato<br />
Tutti coloro che<br />
accedono al sistema<br />
da client remoti.<br />
Pubblico<br />
Dipendente<br />
Direttore<br />
Cuoco<br />
Commesso<br />
Cassiere<br />
Fattorino<br />
Addetto Scorte<br />
Figura 3-1 Diagramma degli attori<br />
8
3.2 Utente Generico<br />
Si tratta delle principali situazioni d'uso che coinvolgono un Utente Generico (Figura 3-2). Non<br />
essendo ancora registrato un utente generico può solamente consultare la lista dei prodotti venduti,<br />
effettuare il Login per diventare un utente registrato o compiere una richiesta di registrazione<br />
diventando un utente Pubblico. Un utente generico può diventare un dipendente solo tramite<br />
l’intervento diretto e quindi la registrazione da parte del Direttore.<br />
Consulta menù<br />
Login<br />
Utente Generico<br />
Richiesta di<br />
registrazione<br />
"Actor" Sistema di<br />
accounting<br />
Figura 3-2 Use Case Utente Generico<br />
3.3 Direttore<br />
Si tratta delle principali situazioni d'uso che coinvolgono un direttore (Figura 3-3).<br />
Gestione<br />
Dipendenti<br />
DBMS<br />
Listino prezzi<br />
DBMS<br />
Direttore<br />
Revoca account<br />
"Actor" Sistema di<br />
accounting<br />
Figura 3-3 Use Case Direttore<br />
9
3.4 Commesso<br />
Si tratta delle principali situazioni d'uso che coinvolgono un commesso (Figura 3-4). La<br />
consultazione delle informazioni si riferisce sia alla ricerca dei prodotti nel menù, sia alla<br />
consultazione dei dati dei clienti.<br />
«extends»<br />
Registra Cliente<br />
Identifica Cliente<br />
«extends»<br />
Aggiorna Cliente<br />
Registra Reclamo<br />
Commesso<br />
Ricevi ordinazione<br />
«extends»<br />
<br />
Consulta<br />
informazioni<br />
<br />
Cancella<br />
ordinazione<br />
<br />
Ordinazione<br />
non valida<br />
Verifica<br />
ordinazione<br />
«extends»<br />
Figura 3-4 Use case: Commesso<br />
10
3.5 Ordinazione<br />
Si tratta delle principali situazioni d'uso per la gestione di una ordinazione (Figura 3-5).<br />
Registra incasso<br />
Fattorino<br />
Consegna<br />
ordinazione<br />
<br />
Prepara scontrino<br />
Cassiere<br />
Cuoco<br />
Prendi ordinazione<br />
Figura 3-5 Use case: Ordinazione<br />
3.6 Scorte<br />
Si tratta delle principali situazioni d'uso per la gestione delle scorte (Figura 3-6). L'addetto al<br />
mantenimento delle scorte controlla periodicamente se queste sono sufficienti e, in caso contrario,<br />
contatta un fornitore per ordinarne di nuove. All'arrivo delle nuove scorte aggiorna i dati sulla loro<br />
disponibilità.<br />
Aggiorna Scorte<br />
«extends»<br />
Scorte<br />
Insufficienti<br />
Addetto Scorte<br />
Controlla Scorte<br />
Fornitore<br />
Figura 3-6 Use case: Scorte<br />
11
3.7 Diagramma delle interfacce<br />
Ad ognuno degli utenti, che utilizza il software di gestione della rosticceria, viene assegnata<br />
una interfaccia distinta.<br />
Interfaccia<br />
direttore<br />
Interfaccia<br />
sistema<br />
Interfaccia<br />
Utente<br />
Generico<br />
Interfaccia<br />
Utente<br />
Pubblico<br />
Interfaccia<br />
Commesso<br />
Figura 3-7 Diagramma delle interfacce<br />
12
Capitolo 4<br />
Class diagram<br />
4.1 Package diagram<br />
Sono stati utilizzati quattro package per descrivere questo software.<br />
Nel package Varie non è stata indicata alcuna dipendenza; questo perché, in genere, tutti i package<br />
hanno una dipendenza da questo package.<br />
Ordinazioni<br />
Varie<br />
Prodotti<br />
Persone<br />
Figura 4-1 Package Diagram<br />
4.2 Varie<br />
Le classi di questo package (Figura 4-2), descrivono tipi fondamentali usati in tutti gli altri<br />
package.<br />
Viene definita anche l'interfaccia List: il metodo cerca() richiede una stringa (lista di parole)<br />
contenente tutte le parole che devono essere cercate e ritorna a sua volta una lista che è poi<br />
visualizzabile chiamando il metodo visualizza(). Ciascuna parola viene cercata in tutti i campi<br />
descrittivi di un prodotto e un prodotto corrisponde nella ricerca se sono presenti tutte le parole<br />
cercate. Tramite l'interfaccia List si è stabilito un modo comune per effettuare ogni tipo di ricerca<br />
sia nell'anagrafe dei clienti, sia nel menù dei prodotti, sia nella lista dei reclami.<br />
<br />
List<br />
+cerca(cosa:String) : List()<br />
+visualizza()<br />
Unit<br />
+nome : String<br />
+sigla : String<br />
Quantity<br />
-ammontare : unsigned int<br />
-unità : Unit<br />
Money<br />
Figura 4-2 Class Diagram Varie<br />
13
4.3 Persone<br />
Le classi di questo package (Figura 4-3), gestiscono i dati personali dei clienti e dei<br />
dipendenti.<br />
La seconda e terza statistica indicate nell’SRS dal Requisito #8 sono mantenute come attributi<br />
derivati nelle classi dei rispettivi dipendenti. Queste informazioni sono infatti ricavabili consultando<br />
le ordinazioni (Figura 4-5), tuttavia tale ricerca sarebbe molto lunga per cui si è preferito aggiungere<br />
dei campi opportuni per mantenere questi valori.<br />
Le 2 composizioni con indirizzo non vanno bene. Sostituire con associaz.<br />
Anche l’associazione con Anagrafe Cli. non va bene.<br />
Utente Generico<br />
Utente Registrato<br />
-Nome : String<br />
-Cognome : String<br />
-codicefiscale : String<br />
-telefono : String<br />
-UserId : String<br />
-Pwd : String<br />
+crea()<br />
+elimina()<br />
+visualizzaDati()<br />
+modificaDati()<br />
+RichiestaRegistrazione()<br />
+NuovoAccount()<br />
+Login()<br />
+Logout()<br />
1<br />
domicilio<br />
Indirizzo<br />
-via : String<br />
-numero : String<br />
-CAP : Integer<br />
-comune : String<br />
-provincia : String<br />
+modificadati()<br />
domicilio<br />
1<br />
Fornitore<br />
-RagioneSociale : String<br />
-PIVA : String<br />
+crea()<br />
+elimina()<br />
+visualizzaDati()<br />
<br />
posizione<br />
Cliente<br />
-punteggio : Integer<br />
1..1<br />
Dipendente<br />
-dataNascita : : Date<br />
-stipendio : Money<br />
0..1<br />
<br />
Ruolo<br />
Direttore<br />
Cuoco<br />
Commesso<br />
Cassiere<br />
Fattorino<br />
Addetto Scorte<br />
-/nClienti : Integer<br />
-/nConsegne : Integer<br />
0..*<br />
Carta di credito<br />
-istituto di emissione : String<br />
-NConto : Variant<br />
-NCarta : Variant<br />
-CIN : Variant<br />
-CAB : Variant<br />
-ABI : Variant<br />
+NuovaCarta()<br />
+EliminaCarta()<br />
Anagrafe Clienti<br />
-numeroClienti : Integer<br />
+VisualizzaClientiMigliori()<br />
<br />
List<br />
Figura 4-3 Class Diagram Persone<br />
14
4.4 Prodotti<br />
Le classi di questo package (Figura 4-4), gestiscono i dati relativi ai prodotti in vendita. La<br />
prima statistica indicata nell’SRS dal Requisito #8 è mantenuta come attributo derivato nella classe<br />
Prodotto. Questa informazione è ricavabile consultando le ordinazioni (Figura 4-5), tuttavia tale<br />
ricerca sarebbe molto lunga per cui si è preferito aggiungere il campo nReclami per memorizzare il<br />
numero di reclami fatto per ogni prodotto. La disponibilità di ogni prodotto, sarà in generale<br />
verificata in modo diverso per ciascun tipo di prodotto. La disponibilità di un'offerta dipende da<br />
quella dei prodotti che ne fanno parte e dal fatto che non sia passata la data di scadenza indicata. La<br />
disponibilità di un prodotto in scorta è verificata se la quantità in scorta è non nulla. Per ogni pasto<br />
devono essere sufficienti, invece, le quantità disponibili dei componenti (come indicato dal<br />
commento in Figura).<br />
Prodotto {abstract}<br />
-codice : String<br />
-nome : String<br />
-prezzo: Money<br />
-descrizione : String<br />
+disponibile : bool<br />
-nReclami : Integer<br />
voci<br />
1..*<br />
Menù<br />
-validità: Range<br />
1..*<br />
<br />
List<br />
Pasto<br />
Prodotto in scorta<br />
Offerta<br />
-nome : String<br />
-scorta: Quantity<br />
-scadenza : Date<br />
Componente<br />
-qta: Quantity<br />
componenti<br />
1..*<br />
Ingrediente<br />
-nome : String<br />
Bibita<br />
-contenitore: Contenitore<br />
-quantità: Quantity<br />
disponibile se per ogni componente,<br />
(componente.qta
4.5 Ordinazioni<br />
Le classi di questo package (Figura 4-5) gestiscono i dati relativi alle ordinazioni dei clienti.<br />
Da notare come per ogni ordinazione si tenga traccia di tutti i dipendenti che l’hanno gestita:<br />
l’eventuale commesso che l’ha registrata, nel caso non sia stata fatta tramite web; i cuochi che<br />
l’hanno preparata; il fattorino che l’ha consegnata. Questo serve per ricavare le statistiche richieste<br />
dal Requisito #8 dell’SRS.<br />
Pagamento<br />
-modalità: modoPagamento<br />
<br />
Commesso<br />
<br />
Cuoco<br />
<br />
Fattorino<br />
0..1<br />
*<br />
0..1<br />
ricevuto da<br />
presa da<br />
consegnata da<br />
1<br />
*<br />
*<br />
*<br />
Ordinazione<br />
-stato: OrderState<br />
-data : Date<br />
-/importo: Money<br />
+CalcolaImporto()<br />
numeroVoce<br />
*<br />
*<br />
fatta da<br />
/luogo consegna<br />
1<br />
1<br />
<br />
Cliente<br />
<br />
Indirizzo<br />
1<br />
*<br />
Reclamo<br />
-descrizione : String<br />
*<br />
*<br />
1<br />
<br />
Prodotto<br />
LineaOrdinazione<br />
-qtà : Quantity<br />
ListaReclami<br />
-reclami : Integer<br />
<br />
List<br />
Figura 4-5 Class Diagram Ordinazioni<br />
16
Capitolo 5<br />
Sequence diagram<br />
5.1 Registrazione Utente Generico<br />
La registrazione di un utente, per diventare un Cliente e quindi per poter effettuare<br />
ordinazioni, può essere fatta sia da parte di un Commesso sia tramite il sito web. Consideriamo il<br />
Sequence Diagram di quest’ultimo caso.<br />
Interfaccia Utente Generico<br />
Sistema di Accounting<br />
Cliente<br />
Utente Generico<br />
Accede al sito web<br />
RichiestaRegistrazione()<br />
Unico = cerca()<br />
[Not Unico]<br />
Unico<br />
[Not Unico]<br />
Account non unico<br />
[Unico] NuovoAccount()<br />
Conferma la Registrazione<br />
Conferma la Registrazione<br />
Conferma la Registrazione<br />
Figura 5-1 Sequence diagram Registrazione Utente Generico<br />
17
5.2 Accesso al sistema informativo<br />
Per accedere al sistema informativo un utente generico deve effettuare il Login. Tale<br />
operazione permetterà di cambiare l’interfaccia dell’utente in modo che possa eseguire tutte le<br />
operazioni per le quali è abilitato. Al termine della sessione di lavoro si fa il Logout per<br />
disconnettere l’utente dal sistema. Consideriamo il sequence diagram di un Cliente:<br />
Interfaccia Utente Generico<br />
Interfaccia Cliente<br />
Utente Registrato<br />
Pubblico<br />
Accede al sito web<br />
Login(UserId, Pwd)<br />
Ok = cerca(UserId, Pwd)<br />
[Ok]<br />
Cambio di Interfaccia<br />
[Ok] Conferma Ingresso<br />
Logout()<br />
Cambio di Interfaccia<br />
Conferma<br />
Disconnessione<br />
Figura 5-2 Sequence diagram Accesso al sistema informativo<br />
18
5.3 Gestione Cliente<br />
In Figura 5-3 sono mostrate le procedure di gestione delle informazioni dei clienti da parte<br />
del Commesso: ricerca dei dati, modifica dei dati, registrazione nuovo cliente. Quest'ultima include<br />
un controllo per evitare il reinserimento di un cliente già registrato.<br />
Interfaccia Commesso<br />
AnagrafeClienti<br />
Cliente<br />
Commesso<br />
cercaCliente()<br />
* corrisponde = cerca()<br />
* [corrisponde] visualizzaDati()<br />
modificaDati()<br />
visualizzaDati()<br />
nuovoCliente()<br />
esiste = cercaCliente()<br />
* corrisponde = cerca()<br />
* [corrisponde] visualizzaDati()<br />
[esiste] visualizzaErrore()<br />
[non esiste] crea()<br />
[non esiste] visualizzaDati()<br />
Figura 5-3 Sequence diagram Gestione Cliente<br />
19
5.4 Consulta Menù<br />
In Figura 5-4 è mostrata la procedura di consultazione menù.<br />
Questa procedura è analoga per tutte le altre operazioni di ricerca poiché tutte vengono fatte tramite<br />
la medesima interfaccia definita nella classe List definita in Figura 4-2.<br />
Interfaccia Utente Generico<br />
Menù Prodotto Prodotto<br />
Utente Generico<br />
visualizza()<br />
* visualizzaDati()<br />
visualizzaScheda()<br />
* visualizzaScheda()<br />
cerca()<br />
* corrisponde = cerca()<br />
* [corrisponde] visualizzaDati()<br />
Figura 5-4 Sequence diagram Consulta Menù<br />
20
Capitolo 6<br />
State diagram<br />
6.1 Ordinazione<br />
In Figura 6-1, è mostrato lo state diagram per le istanze della classe Ordinazione.<br />
Questo è strettamente correlato con il diagramma degli stati di LineaOrdine (Figura 6-2): una<br />
ordinazione, per essere valida, deve avere disponibili tutti i prodotti con essa ordinati, quindi ogni<br />
LineaOrdine deve controllare la disponibilità del prodotto prima di poter essere inserita<br />
nell'ordinazione. Se il prodotto è disponibile, la quantità ordinata viene bloccata nelle scorte (per<br />
evitare che un'altra ordinazione fatta contemporaneamente rovini l'ordinazione in corso) e viene<br />
rilasciata nel caso l'ordinazione sia annullata.<br />
Aggiungi<br />
prodotto<br />
Verificata<br />
entry/ Aggiorna scorte<br />
[cliente conferma]<br />
/approva()<br />
Preparato<br />
/pronto()<br />
Creata<br />
do/ Verifica scorte<br />
Conferma<br />
/conferma()<br />
Confermata<br />
Pronta<br />
Consegna<br />
/consegnato()<br />
Consegnata<br />
entry/ Registra pagamento<br />
[cliente non conferma]<br />
/cancella()<br />
Transizione sincrona<br />
su LineaOrdine<br />
Cancellazione<br />
/cancella()<br />
Cancellata<br />
Transizione sincrona<br />
su LineaOrdine<br />
Figura 6-1 State diagram Ordinazione<br />
21
Consegna<br />
/consegnato()<br />
Confermata<br />
Creazione<br />
/crea()<br />
Creata<br />
Verifica<br />
/verifica()<br />
In Verifica<br />
do/ Verifica Disponibilità<br />
[disponibile]<br />
/conferma()<br />
Inserita<br />
entry/ Blocca scorte<br />
Cancellazione<br />
/cancella()<br />
Annullata<br />
entry/ Rilascia scorte<br />
[non disponibile]<br />
/cancella()<br />
Cancellazione<br />
/cancella()<br />
Cancellata<br />
Figura 6-2 State diagram LineaOrdine<br />
22
Capitolo 7<br />
Data Flow diagram<br />
7.1 Ricerca<br />
In Figura 7-1, è mostrato il data flow diagram per una ricerca. Si può vedere che, per<br />
effettuare una ricerca, un commesso fornisce la stringa di ricerca (nel formato descritto nell’SRS dal<br />
Requisito #3 ) al metodo cerca() del Menù. La ricerca viene quindi effettuata su ogni prodotto nel<br />
menù e a quelli corrispondenti viene detto di visualizzare i loro dati.<br />
Uno schema analogo vale per tutte le altre operazioni di ricerca.<br />
StringaRicerca<br />
Menù::cerca()<br />
StringaRicerca<br />
Prodotto::visualizzaDati()<br />
corrisponde{Vero,Falso}<br />
Commesso<br />
Dati<br />
Prodotto::cerca()<br />
Dati<br />
Database Prodotti<br />
Figura 7-1 Data Flow diagram<br />
23
Capitolo 8 Bibliografia<br />
[1] IEEE Recommended Practice for Software Requirements Specification, The Institute of<br />
Electrical and Electronics Engineers, Inc.<br />
[2] Martin Fowler, Kendall Scott: “UML Distilled: Appling the Standard Object Modelling<br />
Language”, Addison-Wesley<br />
24