Altra Tesina - Progettoatena.It

Università degli Studi di Modena e Reggio Emilia
Facoltà di Ingegneria
Corso di Laurea in Ingegneria Informatica
Tesina di Ingegneria del Software
Gestione di una
rosticceria
di
Fabio Zanella
Matr. 1598

Capitolo 1.............................................................................................................................................3
SRS: Specifiche del Problema .........................................................................................................3
Capitolo 2.............................................................................................................................................6
Activity Diagram..............................................................................................................................6
2.1 Commesso..............................................................................................................................6
2.2 Ordinazione............................................................................................................................7
Capitolo 3.............................................................................................................................................8
Use case diagram .............................................................................................................................8
3.1 Diagramma degli attori ..........................................................................................................8
3.2 Utente Generico .....................................................................................................................9
3.3 Direttore .................................................................................................................................9
3.4 Commesso............................................................................................................................10
3.5 Ordinazione..........................................................................................................................11
3.6 Scorte ...................................................................................................................................11
3.7 Diagramma delle interfacce .................................................................................................12
Capitolo 4...........................................................................................................................................13
Class diagram.................................................................................................................................13
4.1 Package diagram ..................................................................................................................13
4.2 Varie.....................................................................................................................................13
4.3 Persone.................................................................................................................................14
4.4 Prodotti.................................................................................................................................15
4.5 Ordinazioni ..........................................................................................................................16
Capitolo 5...........................................................................................................................................17
Sequence diagram ..........................................................................................................................17
5.1 Registrazione Utente Generico ............................................................................................17
5.2 Accesso al sistema informativo............................................................................................18
5.3 Gestione Cliente...................................................................................................................19
5.4 Consulta Menù .....................................................................................................................20
Capitolo 6...........................................................................................................................................21
State diagram .................................................................................................................................21
6.1 Ordinazione..........................................................................................................................21
Capitolo 7...........................................................................................................................................23
Data Flow diagram.........................................................................................................................23
7.1 Ricerca .................................................................................................................................23
Capitolo 8 Bibliografia.......................................................................................................................24
2

Capitolo 1
SRS: Specifiche del Problema
Per la raccolta delle specifiche del problema è stato adottato lo standard IEEE Std 830-1998.
Tale standard si propone di fornire delle linee guida per la specifica dei requisiti del software che
deve essere sviluppato.
1. Introduzione
1.1. Scopo. Si vuole progettare un sistema informativo di ausilio nella gestione di una
rosticceria.
1.2. Campo di validità. Il sistema si deve occupare di mantenere un archivio degli utenti che
possono accedervi (compresi i relativi privilegi), di gestire le ordinazioni dei pasti e la loro
relativa consegna a domicilio.
1.3. Definizioni e abbreviazioni.
Utenti del sistema informativo: sono tutti coloro che possono accedervi (naturalmente ve ne
sono diverse categorie con diritti differenti).
Clienti della rosticceria: sono tutte le persone che usufruiscono dei servizi della rosticceria.
Utenti registrati: sono utenti che sono già stati precedentemente registrati nell’archivio della
rosticceria e che quindi sono possessori di un account che li identifica in modo univoco.
L’account è descritto da due abbreviazioni (UserId, Pwd) che verranno spesso utilizzate per
indicare rispettivamente user identifier e password di un utente registrato (o comunque
quelli che vengono utilizzati per la registrazione).
Utenti generici: sono utenti che, non essendo mai stati registrati, non possono essere
oggetto di controllo da parte della direzione della rosticceria, quindi è loro consentito un
tipo di accesso molto ristretto che consente di ottenere soltanto informazioni sui prodotti
venduti dalla rosticceria, ma non consente loro di effettuare ordinazioni.
Prodotto: In questo documento, con questo termine si fa riferimento a qualsiasi articolo
messo in vendita, quindi sia a prodotti alimentari come pastasciutta, pollo fritto e bevande.
Commesso: Persona col compito di ricevere le ordinazioni dei clienti venuti al locale e dei
clienti che telefonano. Dovrà, inoltre, essere in grado di fornire tutte le informazioni
relative ai prodotti.
1.4. Referenze. Il software è completamente nuovo quindi non vi sono referenze degne di nota.
2. Descrizione generale.
2.1. Funzioni. Il software fornirà le seguenti funzioni:
• Archivio dei clienti. Tale archivio conterrà le informazioni necessarie per la consegna a
domicilio dei pasti.
• Accesso al sistema informativo: si deve fare in modo che l’accesso al sistema sia
consentito a chiunque (registrato o meno), quindi il sistema deve essere di facile accesso,
allo stesso tempo però si deve fare in modo che ciascun utente possa compiere solo le
operazioni che gli sono consentite, quindi deve esserci anche un accesso sicuro al
sistema. Nel momento in cui un utente necessiterà di maggiori informazioni e/o di dover
compiere determinate operazioni non consentite a tutti, questi dovrà registrarsi.
• Archivio dei pasti e delle loro caratteristiche: questo tipo di archivio serve per soddisfare
al meglio le richieste dei clienti. Di ogni pasto devono essere descritti gli ingredienti al
fine di evitare un’intolleranza alimentare da parte da parte del consumatore (glutine,
latticini, uova, …).
• Ricerca su ogni tipo di informazione: deve essere data la possibilità di effettuare ricerche
su tutti i prodotti e offerte disponibili, a partire da qualsiasi informazione disponibile per
un qualsiasi prodotto.
3

• Gestione delle ordinazioni: ogni ordinazione può essere richiesta da utenti locali o
remoti (solo se registrati) tramite web o tramite telefono contattando il commesso della
rosticceria.
• Gestione reclami sui prodotti venduti.
• Gestione delle scorte dei prodotti in vendita.
2.2. Utenti.
• Utente Generico: al fine di garantire l’integrità e la protezione dei dati l’accesso
dell’utente generico è particolarmente ristretto. È consentita soltanto la consultazione del
menù. Nel caso in cui l’utente voglia effettuare una ordinazione deve registrarsi e
compilare il form relativo alla richiesta del pasto oppure rivolgersi al commesso
personalmente o per telefono.
• Pubblico: una volta che l’utente generico si registra ottenendo un account diviene un
utente pubblico. Grazie alla registrazione l’utente ottiene privilegi superiori rispetto a
quelli di un utente generico, infatti oltre a poter fare tutto ciò che può fare l’utente
generico può in più eseguire ordinazioni.
• Commessi: vengono registrati come utenti del sistema informativo all’atto
dell’assunzione. Questa registrazione consente loro di avere particolari privilegi nei
confronti del sistema informativo e quindi di poter compiere tutte quelle operazioni che
rientrano nelle loro mansioni quali l’inserimento/cancellazione delle ordinazioni dei
pasti, calcolo dei conti.
• Direttore: possiede tutti i privilegi dei dipendenti precedenti in più gode di privilegi
supplementari quali quelli di poter aggiornare il listino prezzi, di gestire il personale
(assunzioni, licenziamenti) e revocare gli account.
3. Requisiti del software.
3.1. Requisiti funzionali.
3.1.1. Requisito #1
3.1.1.1.Introduzione. Inserimento di un cliente nel database.
3.1.1.2. Input. Dati anagrafici del cliente:
3.1.1.2.1. Nome e cognome
3.1.1.2.2. Un account (UserId, Pwd) che li identifica in modo univoco
3.1.1.2.3. Domicilio (per le consegne)
3.1.1.2.4. Numero di telefono
3.1.1.2.5. Acquisti effettuati (per eventuali statistiche).
3.1.1.3. Processing. Il sistema controlla che la persona non sia già stata inserita fra i
clienti della rosticceria, nel qual caso inserisce tutti i dati.
3.1.1.4. Output. Messaggio di conferma dell’avvenuto inserimento oppure messaggio
d’errore.
3.1.2. Requisito #2
3.1.2.1.Introduzione. Consultazione Menù.
3.1.2.2. Input. account (UserId, Pwd)
3.1.2.3.Processing. Il menù contenente i prodotti in vendita e le offerte disponibili deve
essere visualizzabile come elenco con le principali informazioni per ogni voce:
codice, nome, disponibilità, prezzo.
3.1.2.4.Output. Di ogni voce del menù deve essere possibile visualizzare le informazioni
dettagliate selezionandola dall'elenco.
3.1.3. Requisito #3
3.1.3.1. Introduzione. Funzioni di ricerca.
3.1.3.2. Input: termini della ricerca.
3.1.3.3. Processing. Deve essere data la possibilità di effettuare ricerche su tutti i prodotti
e offerte, a partire da qualsiasi informazione disponibile per un qualsiasi prodotto.
I termini di ricerca sono forniti tramite una stringa (lista di parole) contenente
4

tutte le parole che devono essere cercate. Ciascuna parola viene cercata in tutti i
campi descrittivi di un prodotto e un prodotto corrisponde nella ricerca se sono
presenti tutte le parole cercate.
3.1.3.4. Output: codice, nome, disponibilità, prezzo di ogni prodotto risultante dalla
funzione di ricerca.
3.1.4. Requisito #4
3.1.4.1. Introduzione. Operazione di ordinazione.
3.1.4.2. Input. Tipo di pasto, numero di pasti.
3.1.4.3. Processing. Selezionando gli articoli durante la consultazione del menù, o dei
risultati di una ricerca, deve essere possibile registrare una ordinazione di un
cliente che sia stato già registrato nell'anagrafe clienti. In ogni momento,
dell'ordinazione devono essere visualizzabili il prezzo totale e i prodotti che la
compongono con i rispettivi prezzi.
3.1.4.4. Output. Il prezzo totale deve essere calcolato tenendo automaticamente conto di
eventuali offerte riguardanti il cliente che sta facendo l'ordinazione o riguardanti i
prodotti che compongono l'ordinazione. Quindi deve essere garantito che il costo
totale calcolato sia il più basso possibile per quel cliente e quell'insieme di
prodotti ordinati, senza la necessità di selezionare esplicitamente le offerte
disponibili per quei prodotti.
3.1.5. Requisito #5
3.1.5.1. Introduzione. Gestione delle scorte dei prodotti in vendita.
3.1.5.2.Processing. Il software dovrà fornire gli strumenti per il mantenimento delle
informazioni sulle scorte dei prodotti in vendita.
3.1.6. Requisito #6
3.1.6.1. Introduzione. Inserimento Reclamo.
3.1.6.2.Input: Ordinazione già avvenuta, descrizione reclamo.
3.1.6.3.Processing. Il software dovrà permettere la registrazione dei reclami, riferiti a
ordinazioni esistenti, da parte dei clienti.
3.1.7. Requisito #7
3.1.7.1. Introduzione. Gestione Reclami.
3.1.7.2.Input: Prodotto.
3.1.7.3.Processing. Il software dovrà permettere la gestione dei reclami consentendo di
consultarli e cancellarli.
3.1.7.4.Output. Reclami associati al prodotto.
3.1.8. Requisito #8
3.1.8.1. Introduzione. Statistiche varie.
3.1.8.2. Input.
3.1.8.3. Processing. Il software dovrà fornire gli strumenti per il mantenimento delle
informazioni riguardanti:
• Prodotti con più reclami.
• Consegne effettuate da ciascun fattorino
• Clienti serviti da ciascun commesso.
5

Capitolo 2
Activity Diagram
2.1 Commesso
Il commesso usa il software per caricare le informazioni fornite dal cliente, effettuare
ricerche per rispondere alle richieste e registrare le ordinazioni. Queste sono tutte attività
indipendenti l'una dall'altra, ed è possibile eseguirle in qualsiasi ordine ed eventualmente passare da
una all'altra in ogni momento.
Commesso
Ricevi informazioni sul cliente
Registra ordinazione
[richiede informazioni]
[nuovo cliente]
Consulta esito ordinazione
Consulta informazioni
Registra cliente
[conferma ordinazione]
[rifiuta ordinazione]
Accetta ordinazione
Cancella ordinazione
Figura 2-1 Activity Diagram: Commesso
6

2.2 Ordinazione
In Figura 2-2, si rappresentano le attività che vengono svolte per soddisfare una nuova ordinazione
di un cliente.
Le colonne nella figura (dette corsie), identificano le aree di azione del software:
• Gestione Ordinazioni: l'ordinazione può essere presa in considerazione se il prodotto è
disponibile. Quando l'ordinazione è confermata, viene presa da un cuoco (per la
preparazione).
• Gestione Amministrativa: mentre viene preparato il pasto viene preparata anche la fattura.
• Gestione Scorte: riguarda la gestione delle scorte dei prodotti, ovvero il controllo del loro
stato con l’eventuale richiesta di nuove scorte nel caso di bassa disponibilità delle stesse.
• Gestione Consegne: le consegne vengono effettuate da un fattorino.
Gestione Ordinazioni
Gestione
Consegne
Gestione
Amministrativa
Gestione
Scorte
Ricevi Ordine
Verifica Ordine
[non valida]
[confermata]
Cancella Ordine
Prepara Ordine
Prepara Scontrino
Aggiorna Scorte
[Scorte Scarse]
Rinnova Scorte
Consegna
Incasso
Figura 2-2 Activity Diagram: Ordinazione
7

Capitolo 3
Use case diagram
3.1 Diagramma degli attori
Il diagramma degli attori ci permette di poter meglio identificare tutti i possibili utenti del
sistema.
Attore
Operatore Esterno
Utente Generico
Fornitore
Utente Registrato
Tutti coloro che
accedono al sistema
da client remoti.
Pubblico
Dipendente
Direttore
Cuoco
Commesso
Cassiere
Fattorino
Addetto Scorte
Figura 3-1 Diagramma degli attori
8

3.2 Utente Generico
Si tratta delle principali situazioni d'uso che coinvolgono un Utente Generico (Figura 3-2). Non
essendo ancora registrato un utente generico può solamente consultare la lista dei prodotti venduti,
effettuare il Login per diventare un utente registrato o compiere una richiesta di registrazione
diventando un utente Pubblico. Un utente generico può diventare un dipendente solo tramite
l’intervento diretto e quindi la registrazione da parte del Direttore.
Consulta menù
Login
Utente Generico
Richiesta di
registrazione
"Actor" Sistema di
accounting
Figura 3-2 Use Case Utente Generico
3.3 Direttore
Si tratta delle principali situazioni d'uso che coinvolgono un direttore (Figura 3-3).
Gestione
Dipendenti
DBMS
Listino prezzi
DBMS
Direttore
Revoca account
"Actor" Sistema di
accounting
Figura 3-3 Use Case Direttore
9

3.4 Commesso
Si tratta delle principali situazioni d'uso che coinvolgono un commesso (Figura 3-4). La
consultazione delle informazioni si riferisce sia alla ricerca dei prodotti nel menù, sia alla
consultazione dei dati dei clienti.
«extends»
Registra Cliente
Identifica Cliente
«extends»
Aggiorna Cliente
Registra Reclamo
Commesso
Ricevi ordinazione
«extends»
Consulta
informazioni
Cancella
ordinazione
Ordinazione
non valida
Verifica
ordinazione
«extends»
Figura 3-4 Use case: Commesso
10

3.5 Ordinazione
Si tratta delle principali situazioni d'uso per la gestione di una ordinazione (Figura 3-5).
Registra incasso
Fattorino
Consegna
ordinazione
Prepara scontrino
Cassiere
Cuoco
Prendi ordinazione
Figura 3-5 Use case: Ordinazione
3.6 Scorte
Si tratta delle principali situazioni d'uso per la gestione delle scorte (Figura 3-6). L'addetto al
mantenimento delle scorte controlla periodicamente se queste sono sufficienti e, in caso contrario,
contatta un fornitore per ordinarne di nuove. All'arrivo delle nuove scorte aggiorna i dati sulla loro
disponibilità.
Aggiorna Scorte
«extends»
Scorte
Insufficienti
Addetto Scorte
Controlla Scorte
Fornitore
Figura 3-6 Use case: Scorte
11

3.7 Diagramma delle interfacce
Ad ognuno degli utenti, che utilizza il software di gestione della rosticceria, viene assegnata
una interfaccia distinta.
Interfaccia
direttore
Interfaccia
sistema
Interfaccia
Utente
Generico
Interfaccia
Utente
Pubblico
Interfaccia
Commesso
Figura 3-7 Diagramma delle interfacce
12

Capitolo 4
Class diagram
4.1 Package diagram
Sono stati utilizzati quattro package per descrivere questo software.
Nel package Varie non è stata indicata alcuna dipendenza; questo perché, in genere, tutti i package
hanno una dipendenza da questo package.
Ordinazioni
Varie
Prodotti
Persone
Figura 4-1 Package Diagram
4.2 Varie
Le classi di questo package (Figura 4-2), descrivono tipi fondamentali usati in tutti gli altri
package.
Viene definita anche l'interfaccia List: il metodo cerca() richiede una stringa (lista di parole)
contenente tutte le parole che devono essere cercate e ritorna a sua volta una lista che è poi
visualizzabile chiamando il metodo visualizza(). Ciascuna parola viene cercata in tutti i campi
descrittivi di un prodotto e un prodotto corrisponde nella ricerca se sono presenti tutte le parole
cercate. Tramite l'interfaccia List si è stabilito un modo comune per effettuare ogni tipo di ricerca
sia nell'anagrafe dei clienti, sia nel menù dei prodotti, sia nella lista dei reclami.
List
+cerca(cosa:String) : List()
+visualizza()
Unit
+nome : String
+sigla : String
Quantity
-ammontare : unsigned int
-unità : Unit
Money
Figura 4-2 Class Diagram Varie
13

4.3 Persone
Le classi di questo package (Figura 4-3), gestiscono i dati personali dei clienti e dei
dipendenti.
La seconda e terza statistica indicate nell’SRS dal Requisito #8 sono mantenute come attributi
derivati nelle classi dei rispettivi dipendenti. Queste informazioni sono infatti ricavabili consultando
le ordinazioni (Figura 4-5), tuttavia tale ricerca sarebbe molto lunga per cui si è preferito aggiungere
dei campi opportuni per mantenere questi valori.
Le 2 composizioni con indirizzo non vanno bene. Sostituire con associaz.
Anche l’associazione con Anagrafe Cli. non va bene.
Utente Generico
Utente Registrato
-Nome : String
-Cognome : String
-codicefiscale : String
-telefono : String
-UserId : String
-Pwd : String
+crea()
+elimina()
+visualizzaDati()
+modificaDati()
+RichiestaRegistrazione()
+NuovoAccount()
+Login()
+Logout()
1
domicilio
Indirizzo
-via : String
-numero : String
-CAP : Integer
-comune : String
-provincia : String
+modificadati()
domicilio
1
Fornitore
-RagioneSociale : String
-PIVA : String
+crea()
+elimina()
+visualizzaDati()
posizione
Cliente
-punteggio : Integer
1..1
Dipendente
-dataNascita : : Date
-stipendio : Money
0..1
Ruolo
Direttore
Cuoco
Commesso
Cassiere
Fattorino
Addetto Scorte
-/nClienti : Integer
-/nConsegne : Integer
0..*
Carta di credito
-istituto di emissione : String
-NConto : Variant
-NCarta : Variant
-CIN : Variant
-CAB : Variant
-ABI : Variant
+NuovaCarta()
+EliminaCarta()
Anagrafe Clienti
-numeroClienti : Integer
+VisualizzaClientiMigliori()
List
Figura 4-3 Class Diagram Persone
14

4.4 Prodotti
Le classi di questo package (Figura 4-4), gestiscono i dati relativi ai prodotti in vendita. La
prima statistica indicata nell’SRS dal Requisito #8 è mantenuta come attributo derivato nella classe
Prodotto. Questa informazione è ricavabile consultando le ordinazioni (Figura 4-5), tuttavia tale
ricerca sarebbe molto lunga per cui si è preferito aggiungere il campo nReclami per memorizzare il
numero di reclami fatto per ogni prodotto. La disponibilità di ogni prodotto, sarà in generale
verificata in modo diverso per ciascun tipo di prodotto. La disponibilità di un'offerta dipende da
quella dei prodotti che ne fanno parte e dal fatto che non sia passata la data di scadenza indicata. La
disponibilità di un prodotto in scorta è verificata se la quantità in scorta è non nulla. Per ogni pasto
devono essere sufficienti, invece, le quantità disponibili dei componenti (come indicato dal
commento in Figura).
Prodotto {abstract}
-codice : String
-nome : String
-prezzo: Money
-descrizione : String
+disponibile : bool
-nReclami : Integer
voci
1..*
Menù
-validità: Range
1..*
List
Pasto
Prodotto in scorta
Offerta
-nome : String
-scorta: Quantity
-scadenza : Date
Componente
-qta: Quantity
componenti
1..*
Ingrediente
-nome : String
Bibita
-contenitore: Contenitore
-quantità: Quantity
disponibile se per ogni componente,
(componente.qta

4.5 Ordinazioni
Le classi di questo package (Figura 4-5) gestiscono i dati relativi alle ordinazioni dei clienti.
Da notare come per ogni ordinazione si tenga traccia di tutti i dipendenti che l’hanno gestita:
l’eventuale commesso che l’ha registrata, nel caso non sia stata fatta tramite web; i cuochi che
l’hanno preparata; il fattorino che l’ha consegnata. Questo serve per ricavare le statistiche richieste
dal Requisito #8 dell’SRS.
Pagamento
-modalità: modoPagamento
Commesso
Cuoco
Fattorino
0..1
*
0..1
ricevuto da
presa da
consegnata da
1
*
*
*
Ordinazione
-stato: OrderState
-data : Date
-/importo: Money
+CalcolaImporto()
numeroVoce
*
*
fatta da
/luogo consegna
1
1
Cliente
Indirizzo
1
*
Reclamo
-descrizione : String
*
*
1
Prodotto
LineaOrdinazione
-qtà : Quantity
ListaReclami
-reclami : Integer
List
Figura 4-5 Class Diagram Ordinazioni
16

Capitolo 5
Sequence diagram
5.1 Registrazione Utente Generico
La registrazione di un utente, per diventare un Cliente e quindi per poter effettuare
ordinazioni, può essere fatta sia da parte di un Commesso sia tramite il sito web. Consideriamo il
Sequence Diagram di quest’ultimo caso.
Interfaccia Utente Generico
Sistema di Accounting
Cliente
Utente Generico
Accede al sito web
RichiestaRegistrazione()
Unico = cerca()
[Not Unico]
Unico
[Not Unico]
Account non unico
[Unico] NuovoAccount()
Conferma la Registrazione
Conferma la Registrazione
Conferma la Registrazione
Figura 5-1 Sequence diagram Registrazione Utente Generico
17

5.2 Accesso al sistema informativo
Per accedere al sistema informativo un utente generico deve effettuare il Login. Tale
operazione permetterà di cambiare l’interfaccia dell’utente in modo che possa eseguire tutte le
operazioni per le quali è abilitato. Al termine della sessione di lavoro si fa il Logout per
disconnettere l’utente dal sistema. Consideriamo il sequence diagram di un Cliente:
Interfaccia Utente Generico
Interfaccia Cliente
Utente Registrato
Pubblico
Accede al sito web
Login(UserId, Pwd)
Ok = cerca(UserId, Pwd)
[Ok]
Cambio di Interfaccia
[Ok] Conferma Ingresso
Logout()
Cambio di Interfaccia
Conferma
Disconnessione
Figura 5-2 Sequence diagram Accesso al sistema informativo
18

5.3 Gestione Cliente
In Figura 5-3 sono mostrate le procedure di gestione delle informazioni dei clienti da parte
del Commesso: ricerca dei dati, modifica dei dati, registrazione nuovo cliente. Quest'ultima include
un controllo per evitare il reinserimento di un cliente già registrato.
Interfaccia Commesso
AnagrafeClienti
Cliente
Commesso
cercaCliente()
* corrisponde = cerca()
* [corrisponde] visualizzaDati()
modificaDati()
visualizzaDati()
nuovoCliente()
esiste = cercaCliente()
* corrisponde = cerca()
* [corrisponde] visualizzaDati()
[esiste] visualizzaErrore()
[non esiste] crea()
[non esiste] visualizzaDati()
Figura 5-3 Sequence diagram Gestione Cliente
19

5.4 Consulta Menù
In Figura 5-4 è mostrata la procedura di consultazione menù.
Questa procedura è analoga per tutte le altre operazioni di ricerca poiché tutte vengono fatte tramite
la medesima interfaccia definita nella classe List definita in Figura 4-2.
Interfaccia Utente Generico
Menù Prodotto Prodotto
Utente Generico
visualizza()
* visualizzaDati()
visualizzaScheda()
* visualizzaScheda()
cerca()
* corrisponde = cerca()
* [corrisponde] visualizzaDati()
Figura 5-4 Sequence diagram Consulta Menù
20

Capitolo 6
State diagram
6.1 Ordinazione
In Figura 6-1, è mostrato lo state diagram per le istanze della classe Ordinazione.
Questo è strettamente correlato con il diagramma degli stati di LineaOrdine (Figura 6-2): una
ordinazione, per essere valida, deve avere disponibili tutti i prodotti con essa ordinati, quindi ogni
LineaOrdine deve controllare la disponibilità del prodotto prima di poter essere inserita
nell'ordinazione. Se il prodotto è disponibile, la quantità ordinata viene bloccata nelle scorte (per
evitare che un'altra ordinazione fatta contemporaneamente rovini l'ordinazione in corso) e viene
rilasciata nel caso l'ordinazione sia annullata.
Aggiungi
prodotto
Verificata
entry/ Aggiorna scorte
[cliente conferma]
/approva()
Preparato
/pronto()
Creata
do/ Verifica scorte
Conferma
/conferma()
Confermata
Pronta
Consegna
/consegnato()
Consegnata
entry/ Registra pagamento
[cliente non conferma]
/cancella()
Transizione sincrona
su LineaOrdine
Cancellazione
/cancella()
Cancellata
Transizione sincrona
su LineaOrdine
Figura 6-1 State diagram Ordinazione
21

Consegna
/consegnato()
Confermata
Creazione
/crea()
Creata
Verifica
/verifica()
In Verifica
do/ Verifica Disponibilità
[disponibile]
/conferma()
Inserita
entry/ Blocca scorte
Cancellazione
/cancella()
Annullata
entry/ Rilascia scorte
[non disponibile]
/cancella()
Cancellazione
/cancella()
Cancellata
Figura 6-2 State diagram LineaOrdine
22

Capitolo 7
Data Flow diagram
7.1 Ricerca
In Figura 7-1, è mostrato il data flow diagram per una ricerca. Si può vedere che, per
effettuare una ricerca, un commesso fornisce la stringa di ricerca (nel formato descritto nell’SRS dal
Requisito #3 ) al metodo cerca() del Menù. La ricerca viene quindi effettuata su ogni prodotto nel
menù e a quelli corrispondenti viene detto di visualizzare i loro dati.
Uno schema analogo vale per tutte le altre operazioni di ricerca.
StringaRicerca
Menù::cerca()
StringaRicerca
Prodotto::visualizzaDati()
corrisponde{Vero,Falso}
Commesso
Dati
Prodotto::cerca()
Dati
Database Prodotti
Figura 7-1 Data Flow diagram
23

Capitolo 8 Bibliografia
[1] IEEE Recommended Practice for Software Requirements Specification, The Institute of
Electrical and Electronics Engineers, Inc.
[2] Martin Fowler, Kendall Scott: “UML Distilled: Appling the Standard Object Modelling
Language”, Addison-Wesley
24