Progetto Di Ingegneria Del Software

POLITECNICO DI BARI
FACOLTA’ DI INGEGNERIA
CORSO DI LAUREA SPECIALISTICA IN
INGEGNERIA INFORMATICA
PROGETTO DI INGEGNERIA DEL SOFTWARE
GESTIONE DI UNA RETE DI VENDITA PER LA GRANDE

DISTRIBUZIONE ALIMENTARE
Docente
Chiar.ma Prof.ssa Marina Mongiello
Gianvito Bavaro
Vito Conversano
Giuseppe Gaeta
Daniele Gallitelli
Maria Francesca Saponieri
Anno accademico 2009-2010

INDICE
Capitolo 1. Fase preliminare

Tema d’anno ……..………………………………………………………………………. 1
Studio di fattibilità ……………………………………………………………………….. 2
Funzionalità generali del sistema …………………………………………….………….. 5
Parti interessate …………………………………………………….…………………...... 8
Capitolo 2. Analisi
Introduzione ……………………………………………………………………...………. 9
Specifiche dei requisiti
1. Gestione punto vendita ……………………………………………….……….. 11
2. Gestione fornitore ………………………………………..……...…………...... 14
3. Gestione prodotto …………………………………………………………….... 16
4. Gestione listino ……………………………………………………………...… 19
5. Gestione ordine ………………………………………………………………... 21
6. Visualizzazione stato ordine ………………………………………………...… 24
7. Valutazione ordine …………………………………………………………….. 27
8. Aggiornamento stato ordine …………………………………………………... 29
9. Storico degli ordini ……………………………………………………………. 32
10. Gestione accessi …………………………………………………………….... 34
Matrice di tracciabilità ………………………………………………………………….... 36
Casi d’uso
Diagramma degli attori ……………………………………………...…………… 37
Diagramma dei casi d’uso ……………………………………………….………. 38
Descrizione dei casi d’uso
User ………………………..………………………………...…………………… 39
Visualizzare home page ………………………………………..………….. 40
Registrare punto vendita …………………………………………………... 41
I
Login ………………………………………………………………………. 42
Recuperare password ……………………………………………………… 43
Punto vendita ………………………..………………………………...…………. 45
Visualizzare proprio listino …...………………………………..………….. 46
Gestire carrello …………...………………………………………………... 47
Ordinare prodotto ………………………………………………………….. 48
Visualizzare profilo …...........……………………………………………… 49
Modificare profilo …………………………………………………………. 50
Visualizzare storico propri ordini …………………………………………. 51
Visualizzare propri ordini …………………………………………………. 52
Valutare ordine ……………………………………………………………. 54
Amministrazione ………………………..………………………………...…….... 55
Gestire fornitori …...………………………………..……………………... 56
Visualizzare fornitore …...……………………………………………….... 57
Aggiungere fornitore ……………………………………………………… 58
Modificare fornitore …...........……………………………………………... 59
Rimuovere fornitore ……………………………………………………….. 60
Gestire punti vendita ………………………………..……………………... 61
Visualizzare punto vendita …...…………………………………………… 62
Rimuovere punto vendita ………………………………………………….. 63
Visualizzare storico ordini ………………………………………………… 64
Visualizzare ordini ………………………………………………………… 65
Marketing ………………………..………………………………...……............... 66
Gestire listini …...………………………………..……………………........ 67
Visualizzare listino …...………………………………………………........ 68
Aggiungere listino ………………………………………………………… 69
Modificare listino …...........……………………………………………....... 70
Rimuovere listino ………………………………………………………….. 71
Gestire prodotti …...………………………………..…………………….... 72
Visualizzare prodotto …...………………………………………………..... 73
Aggiungere prodotto ………………………………………………………. 74
Modificare prodotto …...........……………………………………………... 75
Rimuovere prodotto ……………………………………………………….. 76
II
Visualizzare fornitore ……………………………………………………... 77
Logistica ………………………..………………………………...……................ 78
Visualizzare ordini ……………………………..…………………….......... 79
Visualizzare stato ordine …...…………………………………………........ 80
Aggiornare stato ordine …………………………………………………… 81
Visualizzare fornitore …...........…………………………………………… 82
Visualizzare prodotto ……………………………………………………… 83
Visualizzare listino ………………………………………………………... 84
Modello E/R …………………………………………………………………................... 85
Diagramma delle classi di analisi ………………………………………………………... 86
Capitolo 3. Progettazione
Scelte progettuali ………………………………………………………………………… 87
XAMPP ……………………………………………...…………………………… 88
Web Server: Apache 2.2.14 ……………………………………………….……... 90
OpenSSL 0.9.8 …………………………………………………………………… 91
MySQL 5.1.41 …………………………………………………………………… 92
GDO come “sistema transazionale”: gestione di transazioni concorrenti ……….. 94
phpMyAdmin 3.2.4 ………………………………………………………………. 98
FileZilla FTP Server 0.9.33 ……………………………………………………… 99
PHP 5.3.1 ………………………………………………………………………… 100
CodeIgniter ………………………………………………………………………. 101
Architettura software …………………………………………………………………….. 103
Architettura client-server…………………………...…………………………….. 103
Diagramma di deployment (dispiegamento) …………………………………………….. 109
Pattern architetturale ……………………………………………………………………... 111
Model-View-Controller …………………………...……………………………............... 111
Design pattern ……………………………………………………………………………. 115
Pattern creazionali ……………………………………………………………….. 116
Singleton ……………………………..……………………......................... 116
Pattern strutturali ………………………………………………………………… 119
Proxy ……………………………..……………………............................... 119
Pattern comportamentali …………………………………………………………. 121
III
Observer ……………………………..…………………….......................... 121
Strategy ……………………………..……………………........................... 123
Diagramma delle componenti …………………………………………………………..... 126
Progettazione logica e business rule ……………………………………………………... 132
Business rule ……………………………………………………………………... 133
Classi di progetto ……………………………………………………................................ 135
Specifica delle classi di progetto ……………………………………………….... 136
Package ……………………………..……………………........................... 136
Classi ……………………………..……………………............................... 138
Diagrammi di macchina a stati …………………………………………………………... 197
Creazione ordine ……………..……………………..................................... 198
Aggiungi prodotto ……………..……………………................................... 199
Gestione ordini ……………..……………………........................................ 200
Diagrammi di sequenza ………………………………………………………….............. 201
User ………………………………………………................................................. 202
Visualizzare home page …………..…………………….............................. 202
Registrare punto vendita ………..……………………................................. 203
Recuperare password …………..…………………….................................. 204
Login ………..……………………............................................................... 205
Punto vendita …………………………………….................................................. 206
Visualizzare proprio listino ……..……………………................................. 206
Filtrare prodotti (pv) ………..……………………....................................... 207
Gestire carrello …………..……………………............................................ 208
Aggiungi al carrello ……………………...................................................... 209
Effettuare ordine ………..……………………............................................. 209
Confermare ordine …………..……………………...................................... 210
Visualizzare profilo ………..……………………........................................ 211
Modificare profilo …………..……………………....................................... 212
Visualizzare storico propri ordini ………………......................................... 213
Filtrare storico (pv) …………..……………………..................................... 214
Valutare ordine evaso ………..……………………..................................... 214
Visualizzare propri ordini …………..……………………........................... 215
Filtrare ordini (pv) ………..…………………….......................................... 216
IV
Valutare ordine pervenuto ……..…………………….................................. 217
Visualizzare ordine (pv) ………..……………………................................. 217
Amministrazione ………………………………..................................................... 218
Gestire fornitori ……..……………………................................................... 218
Filtrare fornitori ………..…………………….............................................. 219
Visualizzare fornitore ………..……………………..................................... 220
Modificare fornitore …………..…………………….................................... 220
Rimuovere fornitore ………..……………………........................................ 221
Aggiungere fornitore ………..……………………...................................... 221
Gestire punti vendita ……..……………………........................................... 222
Filtrare punti vendita ………..……………………....................................... 223
Visualizzare punto vendita ………..……………………............................. 223
Modificare insegna ………..……………………......................................... 224
Rimuovere punto vendita ………..……………………................................ 224
Visualizzare storico ordini ………..…………………….............................. 225
Filtrare storico ………..……………………................................................. 225
Visualizzare ordini (amministrazione) ……………….................................. 226
Filtrare ordini (amministrazione) .……………………................................. 226
Marketing ………………………………................................................................ 227
Gestire listini ……..……………………....................................................... 227
Filtrare listini ………..…………………….................................................. 228
Visualizzare listino ………..……………………......................................... 229
Aggiungere listino ………..…………………….......................................... 230
Modificare listino …………..……………………........................................ 231
Rimuovere listino ………..……………………............................................ 232
Gestire prodotti ……..…………………….................................................... 233
Filtrare prodotti ………..……………………............................................... 234
Visualizzare prodotto ………..……………………...................................... 235
Modificare prodotto …………..…………………….................................... 235
Rimuovere prodotto ………..……………………........................................ 236
Aggiungere prodotto ………..……………………....................................... 236
Visualizzare fornitori (marketing) ..…………………….............................. 237
Filtrare fornitori (marketing) ..……………………...................................... 237
V
Visualizzare fornitore (marketing) ..…………………….............................. 238
Logistica ………………………………................................................................. 239
Visualizzare ordini ……..…………………….............................................. 239
Filtrare ordini ………..…………………….................................................. 240
Visualizzare ordine ………..……………………......................................... 241
Aggiornare stato ordine ………………………............................................ 242
Annullare stato ordine …………..……………………................................. 243
Visualizzare fornitori (logistica) ..……………………................................. 244
Filtrare fornitori (logistica) ..……………………......................................... 244
Visualizzare fornitore (logistica) ..……………………................................ 245
Visualizzare prodotti (logistica) ..……………………................................. 245
Filtrare prodotti (logistica) ..…………………….......................................... 246
Visualizzare prodotto (logistica) ..……………………................................. 246
Visualizzare listini (logistica) ..……………………..................................... 247
Filtrare listini (logistica) ..……………………............................................. 247
Visualizzare listino (logistica) ..…………………….................................... 248
Struttura interfaccia ………………………………………………………….................... 249
Capitolo 4. Implementazione
Indice codice ………………………………………………………………....................... 251
Capitolo 5. Test di sistema

Test di sistema ……………………………………………………………........................ 499
Ispezione del software ……………………………………………………........................ 501
Check list di analisi ………………………………………………………........................ 501
Check list per l’analisi dei casi d’uso ……………................................................. 501
Check list per l’analisi orientata agli oggetti ………….......................................... 503
Check list per i requisiti ………………………….................................................. 504
Check list di progetto ………………………………………………………...................... 505
Utilizzatori del sistema ……………................................................................................... 508
Controlli di ispezione del codice …………........................................................................ 510
VI
Bavaro - Conversano - Gaeta - Gallitelli - Saponieri Fase preliminare
TEMA D’ANNO
Si vuole realizzare un portale web per la gestione della rete di vendita di un'azienda
distributrice all’ingrosso di prodotti alimentari. Il portale deve assicurare la fruizione dei
seguenti servizi:
gestione dell’anagrafica dei punti vendita;
gestione dell’anagrafica dei fornitori;
gestione dei prodotti;
creazione del listino dei prodotti: si richiede la possibilità di creare un listino per ogni
classe di punto vendita (ad es.: listino Auchan, listino Ipercoop, ecc…) con la
possibilità di poter applicare sconti differenziati per ogni singola classe;
raccolta ordini dai punti vendita mediante la visualizzazione del listino e l’aggiunta al
“carrello” dei prodotti;
tracciabilità degli ordini: possibilità di vedere lo stato dell’ordine;
valutazione, da parte del punto vendita, della qualità del servizio ricevuto
dall’azienda distributrice;
possibilità da parte dell’azienda distributrice di monitorare e aggiornare lo stato

dell’ordine;
raccolta degli ordini evasi in uno storico;
fornitura di una modalità d’accesso differenziata per quanto riguarda i punti vendita
(pv), il responsabile dei punti vendita e dei fornitori (amministrazione), l’addetto ai
prodotti e ai listini (marketing), e l’addetto alla gestione degli ordini (logistica).
Inoltre, il sistema software deve rispettare la seguente specifiche:

essere coerente con la struttura organizzativa dell’azienda, distinguendo i ruoli
dell’amministrazione dai ruoli del marketing e della logistica.
fare in modo che il sistema si occupi di fornire username e password a tutti i punti
vendita che intendono usufruire del servizio offerto dall’azienda.
1
STUDIO DI FATTIBILITÀ
Il sistema software da realizzare risulta utile sia per l'azienda distributrice che per i vari
punti vendita in quanto consente una semplice comunicazione a grande distanza tra i
diversi soggetti, riuscendo ad ottenere un notevole risparmio di tempo e denaro nell'analisi
competitiva, nella ricerca e nello sviluppo delle funzioni aziendali.
L'azienda distributrice ha il compito di registrare i prodotti che intende immettere sul

mercato e inserirli nei vari listini. In questo modo, per ogni punto vendita, risulterà essere
semplice ed immediata la visualizzare dei prodotti offerti. Il punto vendita, inoltre, può
esprimere il proprio giudizio sulla qualità del servizio tramite un meccanismo di valutazione
interna correlato alle singole ordinazioni. Tale valutazione indica il livello di soddisfazione
del cliente (punto vendita) in riferimento al servizio complessivo ricevuto.
Il sistema da implementare ha costi e tempi prevedibili, con conseguente riduzione dei

rischi, in quanto non rappresenta particolari innovazioni nel settore.
Andando ad applicare la tecnica del riuso è possibile utilizzare componenti e moduli già
esistenti, in maniera tale da poter garantire il rispetto e l’efficienza di particolari funzionalità
del sistema.
Il sistema software sarà dotato di un’interfaccia grafica di tipo user-friendly permettendo di

avere, così, una grande semplicità di utilizzo anche da parte di utenti meno esperti in
ambito informatico. Ciò consente di allargare il bacino d’utenza che usufruisce di tale
sistema. Inoltre il concetto di user-friendly permette una riduzione dei costi da parte delle
aziende, che non dovranno eseguire alcun tipo di investimento sulla formazione dei propri
dipendenti riguardo particolari sistemi informatici: sarà sufficiente che gli utenti abbiano un
minimo di nozioni basilari riguardo l’utilizzo di un web browser.
2
A garanzia del committente il software rispetterà gli standard di qualità attualmente vigenti.
Secondo la norma ISO/EIC 9126, i principi della qualità del software sono:
• funzionalità;
• affidabilità;
• usabilità;
• efficienza;
• qualità in uso;
• manutenibilità;
• portabilità.
Il progetto sarà realizzato in maniera tale da garantire il rispetto di principi fondamentali

dell’ingegneria del software quali ad esempio la riusabilità, l’information hiding, la
modularità, l’ereditarietà, ecc.
Tale progetto si articola in cinque fasi fondamentali:

◊ studio di fattibilità
◊ analisi e specifica dei requisiti
◊ progettazione
◊ implementazione
◊ test
Il team di sviluppo posto alla realizzazione di tale sistema software è costituito da un

gruppo di cinque persone.
In base alle richieste avanzate abbiamo stimato che la durata del progetto sarà di circa
venti mesi/uomo. Osservando il numero di componenti del nostro team di sviluppo, tale
progetto avrà una durata complessiva di quattro mesi e dieci giorni, considerando anche la
fase preliminare.
3
Qui di seguito riportiamo quello che è il diagramma di Gantt del piano di progetto che
indica la dislocazione temporale delle attività, dove per ognuna di esse viene
rappresentata la durata (espressa in giorni). Il diagramma di Gantt consente di mettere in
evidenza il carattere sequenziale delle attività così come il grado di parallelismo tra di
esse. Tutto ciò ci permette di confrontare le stime con i progressi.
Diagramma di Gantt
Dallo studio di fattibilità e da un’attenta analisi del diagramma sopra riportato si deducono
le seguenti scadenze:
INIZIO FINE
Studio di fattibilità 5 marzo 2010 15 marzo 2010
Analisi e specifica dei requisiti 15 marzo 2010 15 aprile 2010
Progettazione 8 aprile 2010 1 giugno 2010
Implementazione 1 giugno 2010 1 luglio 2010
Test di sistema 21 giugno 2010 15 luglio 2010
La durata complessiva dell’intero progetto è di 111 giorni lavorativi.
4
Le stime sulla durata delle singole attività, così come descritte sopra, potranno essere
garantite solo nel caso in cui non vi siano variazioni e modifiche alle specifiche stabilite dal
committente. Qualora si presentassero, le attività potrebbero subire dei cambiamenti sia
dal punto di vista dei tempi che dei costi.
FUNZIONALITÀ GENERALI DEL SISTEMA
1. GESTIONE PUNTO VENDITA

Sarà possibile descrivere il punto vendita (pv) facendo uso di quelli che sono i suoi dati
quali, ad esempio, la ragione sociale, la partita iva, la sede, l’insegna di appartenenza, i
dati del proprietario e così via. Tramite la manipolazione di questi dati, si potrà gestire in
maniera ottimale ed esaustiva l’assetto del punto vendita.
2. GESTIONE FORNITORE
Sarà possibile descrivere il fornitore facendo uso di quelli che sono i suoi dati quali, ad
esempio, la ragione sociale, la partita iva, la sede, i prodotti che fornisce e così via.
Tramite la manipolazione di questi dati, si potrà gestire in maniera ottimale ed esaustiva
l’organizzazione del fornitore.
3. GESTIONE PRODOTTO
Sarà possibile descrivere il prodotto facendo uso di quelle che sono le sue caratteristiche
principali quali, ad esempio, la sua descrizione, il prezzo, gli sconti applicati, la
disponibilità, le dimensioni o volumetria, la provenienza, il fornitore e così via. Tramite la
manipolazione di questi dati, si potrà gestire in maniera ottimale ed esaustiva il prodotto.
4. GESTIONE LISTINO
Il nostro sistema sarà in grado di gestire un listino prodotti per ogni classe di punto
vendita. I punti vendita appartenenti ad una certa classe saranno raggruppati sotto la
medesima insegna. Nel listino saranno presenti i prodotti con i relativi prezzi. Per ogni
classe sarà possibile poter applicare una variazione sul prezzo originario.
5
5. GESTIONE ORDINE
Il punto vendita potrà consultare un listino prodotti in base al quale scegliere cosa
aggiungere al proprio carrello per l'ordine. Tale listino risulterà essere personalizzato a
seconda dell’insegna di appartenenza del punto vendita.
Il sistema permetterà ai punti vendita di poter effettuare un ordine in base alle proprie
esigenze. Tale ordine sarà rappresentato da tutti i prodotti presenti nel carrello al momento
della richiesta.
6. VISUALIZZAZIONE STATO ORDINE

Il punto vendita e l’azienda distributrice devono essere in grado di poter osservare lo stato
dell’ordine. Per far ciò, viene garantita la funzione di visualizzazione dello stato dell'ordine,
grazie alla quale è possibile verificare se l’ordine è stato pervenuto, se si trova in fase di
preparazione, se è stato evaso, o se è stato annullato.
7. VALUTAZIONE ORDINE
Per i punti vendita sarà messo a disposizione un sistema di feedback in maniera tale da
poter esprimere il grado di soddisfazione per il servizio offerto dall'azienda distributrice, in
relazione ad ogni singolo ordine.
8. AGGIORNAMENTO STATO ORDINE

L’addetto alla gestione degli ordini (logistica) deve essere in grado di poter aggiornare lo
stato dell’ordine. Questa funziona rappresenta una sua particolare prerogativa. L’ordine
potrà dunque assumere i valori di stato pervenuto, stato in fase di preparazione, stato
evaso o stato annullato.
9. GESTIONE STORICO ORDINI

Sia l'azienda distributrice che il punto vendita potranno visualizzare lo storico dei relativi
ordini. Lo storico degli ordini permette di osservare in maniera sintetica ed esauriente
l’analisi di vendita, per una valutazione commerciale sia di fatturato che di tipologia e
volumi di articoli venduti.
Le ricerche sullo storico degli ordini potranno essere condotte usufruendo delle seguenti
chiavi: mese e/o anno dell’ordine, importo della fattura, codice dell’ordine, punto vendita
che ha effettuato l'ordine.
6
10. GESTIONE ACCESSI

Mediante una semplice procedura di autenticazione, il sistema garantire l'accesso alle
seguenti quattro tipologie di utente:
- punto vendita (pv);

- responsabile dei punti vendita e dei fornitori (amministrazione);
- addetto ai prodotti e ai listini (marketing);
- addetto alla gestione degli ordini (logistica);
Tale procedura consiste nell’inserimento di una username e della relativa password,

grazie alle quali è possibile identificare il tipo di utente che effettua l’accesso.
7
PARTI INTERESSATE
Punti vendita (pv): corrispondono agli utilizzatori del sistema che potranno consultare il
listino, effettuare ordini e visualizzare il proprio stato. Il loro accesso è consentito tramite
un meccanismo di riconoscimento e autenticazione mediante login.
Responsabile dei punti vendita e dei fornitori (amministrazione): corrisponde

all’utilizzatore del sistema che si occuperà della gestione dei punti vendita e dei fornitori
oltre alla visualizzazione dello storico. Il suo accesso è consentito tramite un meccanismo
di riconoscimento e autenticazione mediante login.
Addetto ai prodotti e ai listini (marketing): si occupa dell’inserimento e della gestione

dei prodotti, della creazione e dell’amministrazione dei listini. Il suo accesso è consentito
tramite un meccanismo di riconoscimento e autenticazione mediante login.
Addetto alla gestione degli ordini (logistica): si occupa dell’aggiornamento dello stato
dell’ordine e della gestione dello storico degli ordini. Il suo accesso è consentito tramite un
meccanismo di riconoscimento e autenticazione mediante login.
Utente generico (user): corrisponde a un generico navigatore del web che si collega al
portale, ma non ha accesso ad alcun tipo di area riservata. L’utente generico ha soltanto la
possibilità di visualizzare i dati dell'azienda distributrice per poterla poi eventualmente
contattare ed avviare così un rapporto di tipo commerciale con essa.
Team di sviluppo PandoraSW: è composto dai soggetti sviluppatori del sistema software
- Bavaro Gianvito
- Conversano Vito
- Gaeta Giuseppe
- Gallitelli Daniele
- Saponieri Maria Francesca
8
Bavaro - Conversano - Gaeta - Gallitelli - Saponieri Fase di analisi
ANALISI
INTRODUZIONE
Il nostro sistema software è stato pensato per favorire la vendita di prodotti alimentari su
larga scala tramite l’uso di un portale web dotato di tutte le funzionalità necessarie a
soddisfare sia l’azienda distributrice, che ci ha commissionato il progetto, sia l’utente che
si imbatte nel nostro portale. I committenti ci hanno chiesto di rispettare alcuni requisiti, dai
quali abbiamo cercato di trarre tutte le possibili conclusioni per rendere nella realtà quelle
che sono le aspettative esplicitate, senza tralasciare anche aspetti non direttamente
palesati ma indispensabili al corretto funzionamento del sistema: tutto ciò allo scopo di
rendere gradito il nostro prodotto oltre che esaustivo in ogni suo aspetto.
Le parti interessate direttamente dal nostro sistema saranno sia gli addetti ai lavori
(l’azienda distributrice in tutte le sue diverse compagini e l’utente che decide di acquistare
prodotti ed effettuare un ordine tramite il nostro portale), sia gli utenti generici che si
imbattono casualmente nel nostro sito e decidono di navigare al suo interno. Naturalmente
a questi ultimi non dovrà essere consentito di accedere a determinate aree che invece
saranno accessibili a una o più parti specifiche allo scopo di portare a buon fine delle
transazioni di tipo commerciali.
Cominciamo con l’analizzare l’organizzazione aziendale e quindi specificare, anche se in
maniera del tutto sommaria, quelle che saranno le aree di interesse di ciascuna parte in
causa in maniera tale da garantire una distribuzione armonica delle attività e una divisione
dei compiti che risulti la più equa possibile. L’azienda distributrice è articolata in maniera
tale che vi siano le seguenti tre figure che si occupano dei punti nevralgici dell’attività
commerciale alla quale fanno riferimento:
• Responsabile dei punti vendita e dei fornitori (amministrazione);

• Addetto ai prodotti e ai listini (marketing);
• Addetto alla gestione degli ordini (logistica).
9
L’amministrazione corrisponde all’utilizzatore del sistema che si occupa della gestione

dei punti vendita e dei fornitori oltre che della visualizzazione dello storico. Il suo accesso
è consentito tramite un meccanismo di riconoscimento e autenticazione mediante login. È
questa la compagine che si occupa della gestione vera e propria sia degli utenti abilitati ad
interagire con il sistema (i punti vendita come vedremo), sia dei fornitori che devono
godere della più totale fiducia e su cui deve essere eseguita un’opportuna analisi atta a
garantire che vengano distribuiti prodotti di prima qualità: l’amministrazione deve eseguire
operazioni necessarie a garantire la serietà dei partecipanti alla compravendita sia dal
punto di vista economico (punti vendita che, ad esempio, devono rispettare le scadenze di
pagamento) sia dal punto di vista del prodotto fornito.
Il marketing si occupa della gestione dei prodotti e dei listini. Il suo accesso è consentito
tramite un meccanismo di riconoscimento e autenticazione mediante login. È la
compagine aziendale che si occupa di fare ricerche di mercato e valutazioni atte a stilare
listini appropriati per ciascuna classe di punto vendita che decide di acquistare prodotti
tramite il nostro portale web.
La logistica si occupa dell’aggiornamento dello stato dell’ordine e della gestione dello
storico degli ordini. Il suo accesso è consentito tramite un meccanismo di riconoscimento e
autenticazione mediante login. È la parte interessata alla gestione degli ordini: si occupa di
capire quello che è l’effettivo stato di avanzamento del processo che parte dalla creazione,
consegna, liquidazione dell’ordine e mira ad individuare eventuali azioni correttive per far
fronte a possibili situazioni anomale che sarebbero di intralcio all’attività della nostra
azienda.
Dopo aver parlato dell’azienda distributrice possiamo passare ad analizzare gli altri attori
principali del nostro sistema: i Punti vendita. Essi corrispondono agli utilizzatori del
sistema che potranno consultare il listino, effettuare ordini e visualizzare il proprio stato. Il
loro accesso è consentito tramite un meccanismo di riconoscimento e autenticazione
mediante login.
Infine ecco che troveremo anche l’Utente generico (user) che corrisponde a un generico
navigatore del web che si collega al portale, ma non ha accesso ad alcun tipo di area
riservata. L’utente generico ha soltanto la possibilità di visualizzare i dati dell’azienda
distributrice per poterla poi eventualmente contattare ed avviare così un rapporto di tipo
commerciale con essa a seguito della registrazione.
10
SPECIFICHE DEI REQUISITI
1. GESTIONE PUNTO VENDITA
Identificativo 1. GESTIONE PUNTO VENDITA

Descrizione Il sistema dovrà fornire la possibilità di descrivere il punto vendita
attraverso le sue principali caratteristiche e consentirne la gestione.
Motivazione Tale requisito sarà necessario per permettere ai punti vendita, in quanto
utenti del sistema software, di poter accedere alla propria area riservata
in maniera tale da poter gestire tutto ciò che riguarda le loro attività
commerciali.
Fonte Riunione del team di sviluppo.
Requisiti di 1.1) Il sistema dovrà permettere la visualizzazione e la cancellazione dei
sistema punti vendita da parte del responsabile dei punti vendita e dei fornitori
(amministrazione). (requisito funzionale)
1.2) Il sistema, nel momento dell’aggiunta o della cancellazione di un

punto vendita, inoltrerà una e-mail di notifica all’indirizzo del punto vendita
al quale si riferisce. (requisito funzionale)
1.3) Il sistema dovrà essere in grado di consentire al punto vendita (pv) la

visualizzazione e la modifica dei propri dati. (requisito funzionale)
1.4) Il punto vendita potrà essere eliminato soltanto se non esistono ordini
in corso di esecuzione. (requisito non funzionale)
11
REQUISITI INFORMATIVI:
1.5) Il sistema dovrà consentire di immagazzinare come dati struttura i seguenti campi:
- nome;
- partita iva;
- insegna di appartenenza;
- indirizzo;
- telefono;
- e-mail;
- orari di apertura.
1.6) Il campo “orari di apertura” sarà strutturato come uno spazio di tipo testuale all’interno
del quale l’utente andrà ad indicare i giorni e gli orari di apertura del punto vendita.
Ad esempio "lun/mar/merc 8.00-18.00; ven/sab/dom 9.30-15.00".
PARTI INTERESSATE:
Le parti direttamente interessate in questo requisito risulteranno essere sia il responsabile
dei punti vendita e dei fornitori (amministrazione) sia il punto vendita stesso con
responsabilità e attività differenti atte alla gestione del relativo profilo. In particolare la
prima (amministrazione), oltre alla semplice e pura visualizzazione, sarà l’unica parte che
potrà procedere alla cancellazione del punto vendita a seguito di proprie valutazioni, che
riguarderanno il tipo di rapporto con il singolo cliente (insolvenza di ordini, poca chiarezza
nei rapporti, e così via), oppure a seguito di esplicita richiesta da parte dello stesso. La
seconda (punto vendita), invece, dovrà avere la possibilità di modificare i propri dati: quindi
dovrà essere in grado di visualizzare il proprio profilo ed eventualmente aggiornare i campi
personali che si desidera modificare.
Sia l’addetto ai prodotti e ai listini (marketing) sia l’addetto alla gestione degli ordini
(logistica) sia l’utente generico (user) non saranno abilitati ad effettuare alcuna delle
suddette operazioni.
12
Il punto vendita non potrà selezionare alcuna insegna di appartenenza al momento della
registrazione: questa verrà assegnata al punto vendita a discrezione dell’amministrazione
come atto della convalida dell’iscrizione al portale.
Le varie insegne saranno create dal marketing, dove per insegna di appartenenza si
sottintende il listino che verrà mostrato al punto vendita. Il marketing, quale responsabile
dei listini, si occuperà di fornire la lista delle insegne specificando, per ciascuna di esse, lo
sconto applicato sui prezzi.
13
2. GESTIONE FORNITORE
Identificativo 2. GESTIONE FORNITORE

Descrizione Il sistema dovrà fornire la possibilità di descrivere il fornitore attraverso le
sue caratteristiche principali e consentirne la gestione.
Motivazione Tale requisito sarà necessario per poter consentire una gestione dei
fornitori che sia in grado di tener traccia e memorizzare facilmente quelli
che sono, al momento dell’accesso, i principali fornitori dell’azienda
distributrice.
Requisiti di 2.1) Il sistema dovrà permettere l’inserimento, la modifica, la
sistema visualizzazione e la cancellazione dei fornitori da parte del responsabile
dei punti vendita e dei fornitori (amministrazione). (requisito funzionale)
2.2) Il sistema dovrà permettere di visualizzare l’elenco di tutti i fornitori e i

dati struttura relativi al fornitore scelto: operazione effettuabile dall’addetto
ai prodotti e ai listini (marketing) e dall’addetto alla gestione degli ordini
(logistica). (requisito funzionale)
2.3) Un fornitore potrà essere eliminato soltanto se non esistono prodotti

da lui stesso forniti (in maniera tale da poter garantire la proprietà di
consistenza del database). (requisito non funzionale)
14
− nome;
− partita iva;
− indirizzo;
− telefono;
− e-mail.
PARTI INTERESSATE:
La parte interessata direttamente in questo requisito sarà il responsabile dei punti vendita
e dei fornitori (amministrazione) in quanto risulta essere l’unico utente del sistema che
avrà la possibilità di modificare questo set di informazioni.
L’unicità risulta essere un requisito fondamentale per il sistema, in quanto evita che vi
possano essere tentativi di bypassare l’azione di mediazione commerciale tra i vari punti
vendita e i diversi fornitori garantita dal nostro sistema.
Sia l’addetto ai prodotti e ai listini (marketing) sia l’addetto alla gestione degli ordini
(logistica) potranno accedere a tali informazioni soltanto in fase di lettura.
Il punto vendita (pv) e l’utente generico (user) non saranno abilitati ad effettuare alcuna
delle suddette operazioni.
15
3. GESTIONE PRODOTTO
Identificativo 3. GESTIONE PRODOTTO

Descrizione Il sistema dovrà fornire la possibilità di descrivere il prodotto attraverso le
sue caratteristiche principali e consentirne la gestione.
Motivazione Tale requisito si rivelerà necessario per poter effettuare una gestione
completa ed esaustiva del prodotto in tutte le sue principali caratteristiche.
Ciò deve avvenire:
− dal punto di vista del soggetto che acquisterà il prodotto, ossia il
punto vendita, in quanto dovranno essere garantiti dei dati struttura
utili all’acquirente;
− dal punto di vista di chi dovrà gestire il prodotto sotto ogni aspetto
e riuscire a classificarlo (marketing).
Requisiti di 3.1) Il sistema dovrà permettere l’inserimento, la modifica, la
sistema visualizzazione e la cancellazione dei prodotti da parte dell’addetto ai
prodotti e ai listini (marketing). (requisito funzionale)
3.2) Il sistema dovrà permettere di visualizzare l’elenco di tutti i prodotti

disponibili e i dati struttura relativi al prodotto scelto: operazione
effettuabile dall’addetto alla gestione dei prodotti e dei listini (marketing),
e dall’addetto alla gestione degli ordini (logistica). (requisito funzionale)
3.3) Il sistema dovrà permettere di effettuare una visualizzazione selettiva

dei prodotti in base al genere/reparto, al fornitore, al prezzo unitario, alla
disponibilità residua: operazione consentita all’addetto ai prodotti e ai
listini (marketing) e all’addetto alla gestione degli ordini (logistica).
(requisito funzionale)
3.4) Il campo genere/reparto dovrà essere determinato mediante un

menù a tendina che prevede diversi valori predefiniti.
Il numero di tali valori potrà essere aumentato con l’introduzione di nuove
16
categorie di prodotto oppure diminuito nel caso in cui un determinato

genere/reparto non rientri più nei piani commerciali dell’azienda. Queste
modifiche potranno essere effettuate a discrezione dell’addetto ai prodotti
e ai listini (marketing) che sarà l’unico soggetto a poter accede a tali
informazioni. (requisito funzionale)
3.5) Un prodotto non può essere eliminato se ci sono ordini ancora in

esecuzione che lo contengono. (requisito non funzionale)
− codice prodotto;
− nome;
− descrizione;
− data di scadenza;
− genere/reparto;
− provenienza;
− fornitore;
− prezzo unitario;
− disponibilità residua.
3.7) Al momento della registrazione di un prodotto bisognerà definire il campo

genere/reparto, che potrà assumere uno dei seguenti valori:
− gastronomia (formaggi e salumi);
− frutta e verdura;
− macelleria;
− pescheria;
− colazione;
− bevande;
− freschi e surgelati;
− forno;
17
− pasticceria;
− dispensa;
− gelati.
PARTI INTERESSATE:
La parte interessata direttamente in questo requisito sarà l’addetto ai prodotti e ai listini

(marketing) che si incaricherà della registrazione dei prodotti, inserendoli in maniera
opportuna e funzionale all’interno del nostro sistema, ed andando a specificare per
ognuno di essi, le caratteristiche stabilite nel requisito informativo 3.6.
L’addetto alla gestione degli ordini (logistica) potrà accedere a tali informazioni soltanto in
fase di lettura: sarà quindi consentita, a quest’ultima tipologia di utente, solo ed
esclusivamente la funzione di visualizzazione del prodotto.
Sia il responsabile dei punti vendita e dei fornitori (amministrazione) sia Il punto vendita
(pv) sia l’utente generico (user) non saranno abilitati ad effettuare alcuna delle suddette
operazioni.
18
4. GESTIONE LISTINO
Identificativo 4. GESTIONE LISTINO

Descrizione Il nostro sistema dovrà essere in grado di gestire un listino prodotti per
ogni classe di punto vendita. Ciascun listino conterrà tutti i prodotti stabiliti
da quella determinata classe con l’indicazione dei relativi prezzi.
Per ogni classe sarà possibile applicare una variazione sul prezzo
originario, in maniera tale da consentire una politica economica
differenziata in base ai rapporti raggiunti.
Motivazione Tale requisito risulterà essere indispensabile al punto vendita per poter
verificare quali prodotti è possibile acquistare: consultando il listino potrà
decidere in che modo riempire il proprio carrello, individuando i prodotti di
cui necessita e visualizzandone l’indicazione del prezzo.
Fonte Richiesta esplicita del committente.
Requisiti di 4.1) Il sistema dovrà permettere la creazione, la modifica, la
sistema visualizzazione e la cancellazione di un listino che si differenzierà dagli
altri in base alla classe di appartenenza [dove per listino associato al
punto vendita si intende l’insegna cui appartiene]. (requisito funzionale)
4.2) La creazione, modifica e cancellazione di un listino sarà effettuabile

solamente da parte dell’addetto ai prodotti e ai listini (marketing).
4.3) L’addetto alla gestione degli ordini (logistica) potrà visualizzare i

listini. (requisito funzionale)
4.4) Per ogni listino l’azienda potrà definire, a sua discrezione, un tasso di
sconto da poter applicare al prezzo base di ogni prodotto. (requisito
funzionale)
4.5) Ogni punto vendita avrà la possibilità di consultare il listino relativo

alla propria insegna di appartenenza. (requisito funzionale)
19
4.6) Per ogni prodotto sarà possibile visualizzare il prezzo, le quantità

rimanenti, le dimensioni, il numero colli. (requisito funzionale)
4.7) I punti vendita avranno la possibilità di effettuare una ricerca

all’interno del listino considerando i seguenti campi: nome, prezzo,
categoria. (requisito funzionale)
4.8) Un listino non potrà essere eliminato se esiste almeno un punto

vendita appartenente all’insegna ad esso associata. (requisito non
funzionale)
PARTI INTERESSATE:
La parte interessata direttamente in questo requisito sarà l’addetto ai prodotti e ai listini

(marketing) in quanto risulterà essere l’unica in grado di modificare queste informazioni.
L’addetto ai prodotti e ai listini sarà infatti colui che si occuperà di:
- stilare la lista di tutti i prodotti che andranno a costituire il listino;
- definire un eventuale tasso di sconto variabile da applicare ad ogni specifica classe
di punto vendita.
L’addetto alla gestione degli ordini (logistica) potrà accedere a tali informazioni soltanto in
fase di lettura: quindi sarà consentita, da parte di quest’ultima tipologia di utente, soltanto
la funzione di visualizzazione del listino dei prodotti.
Il punto vendita (pv) potrà accedere a tali informazioni soltanto in fase di lettura, ma con la
possibilità di poter usufruire di determinate funzionalità aggiuntive (come ad esempio
l’aggiunta dei prodotti al carrello).
Sia il responsabile dei punti vendita e dei fornitori (amministrazione) sia l’utente generico
(user) non saranno abilitati ad effettuare alcuna delle suddette operazioni.
20
5. GESTIONE ORDINE
Identificativo 5. GESTIONE ORDINE

Descrizione Il punto vendita potrà consultare un listino prodotti in base al quale
scegliere cosa aggiungere al proprio carrello per l’ordine.
Il sistema permetterà ai punti vendita di poter effettuare un ordine in base
alle proprie esigenze. Tale ordine sarà rappresentato da tutti i prodotti
presenti nel carrello al momento della richiesta.
Motivazione Tale requisito risulterà essere indispensabile al punto vendita per poter
effettuare un ordine, oltre che all’azienda distributrice per poterne tener
traccia in maniera efficiente.
Requisiti di 5.1) L’ordine potrà essere effettuato solo da parte dei punti vendita
sistema registrati presso il portale web dell’azienda distributrice. (requisito non
funzionale)
5.2) Il punto vendita aggiungerà al carrello i diversi prodotti scelti tra quelli
a disposizione nel listino, indicando, per ognuno di essi, le quantità
richieste. (requisito funzionale)
5.3) La quantità da aggiungere al carrello non potrà essere superiore alla

quantità disponibile. (requisito non funzionale)
5.4) Il punto vendita potrà sempre modificare il proprio carrello tramite

l’aggiunta o la rimozione di prodotti, oltre alla possibilità di variarne le
quantità richieste. (requisito non funzionale)
5.5) Il sistema dovrà fornire la possibilità di scegliere tra i diversi metodi di

pagamento. Tale scelta potrà essere effettuata tra le seguenti:
“pagamento in contanti alla consegna”, “bonifico bancario”, “pagamento
tramite paypal”. (requisito funzionale)
21
5.6) Il sistema dovrà fornire un riepilogo dell’ordine richiesto, contenente

tutte le informazioni sui prodotti, le modalità di pagamento, i tempi di
consegna e il totale dell’importo da pagare. (requisito funzionale)
5.7) Il sistema dovrà garantire l’avvenuta conferma di creazione

dell’ordine attraverso una determinata procedura che consisterà nel
reinserimento della password da parte dell’utente che ha effettuato
l’ordine (ossia il punto vendita). Una volta terminata tale procedura
(password accettata e conferma dell’avvenuto ordine), questa
corrisponderà a tutti gli effetti, ai sensi legali, alla firma del contratto di
vendita (rescindibile solo nel caso in cui entrambe le parti siano
consenzienti). (requisito funzionale)
5.8) Riguardo l’ordine, il sistema dovrà mantenere informazioni sui seguenti dati:
− codice ordine (univoco tra tutti gli ordini);
− colui che effettua l’ordine (riconosciuto tramite la partita iva);
− quando è stato effettuato l’ordine;
− cosa viene richiesto con tale ordine (prodotti/quantità);
− data di consegna dei prodotti ordinati;
− metodo di pagamento scelto;
− stato dell’ordine (si veda il requisito 6 [Visualizzazione stato dell’ordine]).
22
PARTI INTERESSATE:
La parte interessata direttamente in questo requisito sarà il punto vendita (pv) in quanto
risulterà essere l’unica in grado di modificare queste informazioni. A seguito della
procedura di registrazione al sito, il punto vendita sarà in grado di creare il proprio carrello
della spesa dopo aver visualizzato il listino contenente tutti i prodotti disponibili. Una volta
creato il proprio carrello si potrà procedere al completamento dell’ordine mediante una
procedura di conferma di avvenuto ordine (che richiederà un nuovo inserimento della
propria password e che fungerà da firma digitale del contratto telematico).
Sia il responsabile dei punti vendita e dei fornitori (amministrazione) sia l’addetto alla
gestione degli ordini (logistica) potranno accedere a queste informazioni soltanto in fase di
lettura: quindi sarà consentita, da parte di tali utenti, soltanto la funzione di visualizzazione
dell’ordine.
L’utente generico (user) non sarà abilitato a effettuare alcuna delle suddette operazioni.
23
6. VISUALIZZAZIONE STATO ORDINE
Identificativo 6. VISUALIZZAZIONE STATO ORDINE

Descrizione Il punto vendita e l’azienda distributrice dovranno essere in grado di poter
osservare lo stato dell’ordine. Per far ciò, viene garantita la funzione di
visualizzazione dello stato dell’ordine, grazie alla quale è possibile
verificare se l’ordine è stato pervenuto, se si trova in fase di preparazione,
se è stato evaso, o se è stato annullato.
Motivazione Tale requisito risulterà essere molto utile per l’azienda distributrice in
quanto le consentirà di poter organizzare al meglio il suo lavoro andando
a selezionare solo ed esclusivamente gli ordini cui sarà interessata. Ad
esempio, potrebbe essere utile riuscire ad individuare tutti gli ordini
annullati, in maniera tale da poter comprendere il trend commerciale verso
il quale l’azienda si sta evolvendo e, in base a questa analisi, riuscire
magari ad individuare appropriate strategie di marketing per una pronta
reazione. Inoltre, si potrebbero visualizzare tutti gli ordini che si trovano in
fase di preparazione, così da poter organizzare al meglio la relativa
distribuzione e così via.
Per quanto riguarda il punto vendita, tale requisito risulterà essere di
grande utilità per poter conoscere lo stato di avanzamento del proprio
ordine.
Requisiti di 6.1) Lo stato dell’ordine potrà essere impiegato per tener traccia del
sistema relativo stato di avanzamento all’interno del ciclo di vita: in altre parole si
stabilisce se si trova in fase di preparazione, se l’ordine è stato pervenuto
oppure se è stato evaso, o se è stato annullato. (requisito funzionale)
6.2) Lo stato dell’ordine sarà modificabile esclusivamente dall’addetto alla

gestione degli ordini (logistica) dell’azienda distributrice. (requisito
funzionale)
24
6.3) Nel momento in cui un ordine viene ad essere confermato dal relativo
punto vendita, il sistema provvederà subito a porlo nello stato “in
preparazione”. (requisito non funzionale)
L’attributo “stato dell’ordine” potrà assumere uno dei seguenti valori:
- in preparazione: dopo aver effettuato un ordine, l’azienda distributrice avvierà

tutte le attività necessarie per poter adempiere in maniera corretta all’ordine
ricevuto. In particolare l’azienda distributrice dovrà organizzarsi per la relativa
distribuzione;
- pervenuto: in questo stato, i prodotti, precedentemente richiesti mediante l’ordine,
verranno ad essere effettivamente consegnati al punto vendita da parte
dell’azienda distributrice. Tuttavia il relativo pagamento non sarà stato ancora
perfezionato;
- evaso: con questo stato si indicherà l’avvenuto pagamento dell’ordine da parte del
punto vendita e l’avvenuta consegna dei prodotti richiesti: l’esecuzione dell’ordine
verrà così completata;
- annullato: tale stato indicherà che l’ordine effettuato è stato definitivamente
annullato: pertanto non ci sarà alcuna consegna dei prodotti richiesti dal punto
vendita né alcun tipo di pagamento nei confronti dell’azienda distributrice. Questa
operazione sarà possibile soltanto se l’ordine non si trova nello stato di “evaso”.
25
PARTI INTERESSATE:
La parte interessata direttamente in questo requisito sarà esclusivamente l’addetto alla

gestione degli ordini (logistica), in quanto risulterà essere l’unica in grado di modificare
queste informazioni: potrà visualizzare lo stato dell’ordine in maniera tale da capire come
procedono i vari ordini e quindi il loro corrispondente stato di avanzamento, allo scopo di
programmare in maniera efficiente la relativa distribuzione.
Il responsabile dei punti vendita e dei fornitori (amministrazione), l’addetto ai listini e ai

prodotti (marketing), il punto vendita (pv) e l’utente generico (user) non risulteranno essere
direttamente coinvolti in questo requisito.
26
7. VALUTAZIONE ORDINE
Identificativo 7. VALUTAZIONE ORDINE

Descrizione Il sistema dovrà mettere a disposizione, per ogni singolo punto vendita
(pv), un servizio di valutazione dell’ordine. Tale servizio rappresenterà un
vero e proprio sistema di feedback relativo alla qualità delle attività
commerciali offerte dall’azienda distributrice: ogni cliente potrà esprimere
il proprio grado di soddisfazione riguardo ciascun ordine.
Motivazione Tale requisito risulterà essere molto utile all’azienda distributrice per poter
effettuare una valutazione esaustiva del servizio fornito al cliente, allo
scopo di stilare eventuali azioni correttive riguardo le strategie aziendali
da intraprendere.
Requisiti di 7.1) Il sistema dovrà permettere ad ogni punto vendita, di poter accedere
sistema ad un’area di valutazione riservata in cui poter attribuire un voto
rappresentativo del proprio grado di soddisfazione, relativamente a
ciascun specifico ordine. (requisito funzionale)
7.2) Ogni punto vendita potrà valutare, tra i propri ordini, solo ed
esclusivamente quelli che si troveranno nello stato “pervenuto” o nello
stato “evaso”. (requisito non funzionale)
7.3) Il responsabile dei punti vendita e dei fornitori (amministrazione)

potrà consultare, nella tabella degli ordini che si troveranno nello stato
“evaso” e/o “pervenuto”, il campo relativo alla valutazione dell’ordine
stesso. (requisito non funzionale)
27
REQUISITI INFORMATIVI
7.4) Il campo “voto”, assegnato dal punto vendita, potrà assumere uno dei seguenti valori:
1: servizio insoddisfacente;
2: servizio poco soddisfacente;
3: servizio soddisfacente;
4: servizio molto soddisfacente.
PARTI INTERESSATE:
La parte direttamente interessata da questo requisito risulterà essere il punto vendita (pv)
in quanto sarà l’unico attore del nostro sistema abilitato ad esprimere un giudizio riguardo
la qualità del servizio di cui ha usufruito. Sulla base delle indicazioni del cliente, l’azienda
distributrice sarà in grado di poter approntare determinate modifiche atte al miglioramento
della qualità effettivamente percepita dagli utenti.
Per consentire all’azienda distributrice di monitorare il livello di qualità dei servizi forniti,
dovrà essere garantita la visualizzazione del campo relativo alle valutazioni ricevute,
riguardo tutti gli ordini per cui sono state inserite: tale operazione potrà essere svolta dal
responsabile dei punti vendita e dei fornitori (amministrazione).
Le restanti parti interessate non risulteranno essere direttamente coinvolte in questo

requisito.
28
8. AGGIORNAMENTO STATO ORDINE
Identificativo 8. AGGIORNAMENTO STATO ORDINE

Descrizione Il nostro sistema dovrà consentire di poter aggiornare lo stato dell’ordine.
Tale operazione rappresenterà una prerogativa dell’addetto alla gestione
degli ordini (logistica). Lo stato verrà di volta in volta aggiornato andando
a considerare l’avanzamento dell’ordine dallo stato “in preparazione” fino
a quello “evaso”, passando per lo stato “pervenuto”. Qualora richiesto, e
con il consenso di entrambe le parti, sarà possibile anche porre l’ordine
nello stato “annullato”.
Motivazione L’addetto alla gestione degli ordini (logistica) dovrà tener traccia dello
stato di avanzamento dell’ordine.
Requisiti di 8.1) Solo l’addetto alla gestione degli ordini (logistica) avrà la possibilità di
sistema modificare lo stato dell’ordine. (requisito funzionale)
8.2) Nel momento in cui il campo dello stato dell’ordine assumerà il valore
“evaso”, il sistema procederà all’eliminazione della tupla corrispondente
dalla tabella degli ordini, tenendone comunque traccia nell’archivio
relativo allo storico. (requisito non funzionale)
8.3) L’ordine passerà nello stato “in preparazione” non appena verrà
ricevuto un messaggio di conferma da parte del punto vendita. (requisito
non funzionale)
8.4) Al termine di ogni singola fase, l’addetto alla gestione degli ordini
(logistica) provvederà ad aggiornarne lo stato. In particolare le fasi si
susseguiranno nel modo seguente:
- “in preparazione”;
- “pervenuto”;
- “evaso”;
- “annullato”.
29
Il campo riguardante lo stato dell’ordine potrà assumere valore “annullato”

soltanto se l’ordine non sarà stato ancora evaso. (requisito non
funzionale)
L’attributo “stato dell’ordine” potrà assumere uno dei seguenti valori:
- in preparazione: dopo aver effettuato un ordine, l’azienda distributrice avvierà

tutte le attività necessarie per poter adempiere in maniera corretta all’ordine
ricevuto. In particolare l’azienda distributrice dovrà organizzarsi per la relativa
distribuzione;
- pervenuto: in questo stato, i prodotti, precedentemente richiesti mediante l’ordine,
verranno ad essere effettivamente consegnati al punto vendita da parte
dell’azienda distributrice. Tuttavia il relativo pagamento non sarà stato ancora
perfezionato;
- evaso: con questo stato si indicherà l’avvenuto pagamento dell’ordine da parte del
punto vendita e l’avvenuta consegna dei prodotti richiesti: l’esecuzione dell’ordine
verrà così completata;
- annullato: tale stato indicherà che l’ordine effettuato è stato definitivamente
annullato: pertanto non ci sarà alcuna consegna dei prodotti richiesti dal punto
vendita né alcun tipo di pagamento nei confronti dell’azienda distributrice. Questa
operazione sarà possibile soltanto se l’ordine non si trova nello stato di “evaso”.
30
PARTI INTERESSATE:
La parte direttamente interessata da questo requisito risulterà essere l’addetto alla

gestione degli ordini (logistica) in quanto unico rappresentante dell’azienda distributrice in
grado di modificare queste informazioni.
Oltre all’addetto alla gestione degli ordini (logistica), anche il punto vendita (pv) e il
responsabile dei punti vendita e dei fornitori (amministrazione) avranno la possibilità di
visualizzare le modifiche che verranno ad essere apportate allo stato dell’ordine.
Sia l’addetto ai prodotti e ai listini (marketing) sia l’utente generico (user) non saranno
abilitati a visualizzare in alcun modo lo stato dell’ordine poiché non risulteranno esserne
direttamente coinvolti.
31
9. STORICO DEGLI ORDINI
Identificativo 9. STORICO DEGLI ORDINI

Descrizione Il sistema dovrà consentire al responsabile dei punti vendita e dei fornitori
(amministrazione) di visualizzare lo storico degli ordini: tale storico sarà
strutturato in maniera tale da tener traccia degli ordini evasi e non più
attivi al momento di visualizzazione dello stesso.
Inoltre, ogni singolo punto vendita potrà accedere al proprio storico per la
visualizzazione dei relativi ordini effettuati in precedenza e già conclusi.
Le ricerche sullo storico degli ordini potranno essere condotte sulla base
delle seguenti chiavi: mese e/o anno dell’ordine, importo della fattura,
codice dell’ordine, punto vendita che ha effettuato l’ordine.
Motivazione Tale requisito risulterà essere utile per permettere una consultazione
rapida di tutti gli ordini che sono stati gestiti dall’azienda nell’immediato
passato, per avere l’opportunità di osservare in maniera sintetica ma
esauriente l’analisi di vendita e per stilare una valutazione commerciale in
riferimento sia al fatturato che alla tipologia e ai volumi di articoli venduti.
Infine è bene specificare che ogni punto vendita potrà visualizzare tutti i
propri ordini, gestiti e portati a termine dalla nostra azienda distributrice.
Requisiti di 9.1) Il responsabile dei punti vendita e dei fornitori (amministrazione)
sistema potrà accedere ad un’area del portale che conterrà tutti gli ordini effettuati
ed evasi fino a quel momento, allo scopo di tener traccia di quello che
sarà stato il proprio lavoro. (requisito funzionale)
9.2) Il sistema consentirà al punto vendita (pv) di poter visualizzare tutti i

propri ordini evasi al momento della richiesta di accesso allo storico degli
ordini. (requisito funzionale)
9.3) Il sistema dovrà permettere di effettuare la ricerca tra tutti gli ordini
disponibili secondo le chiavi di ricerca elencate nei requisiti informativi 9.4
e 9.5. (requisito funzionale)
32
9.4) La ricerca svolta dall’azienda distributrice potrà essere condotta sulla base delle
seguenti chiavi:
− codice ordine;
− codice punto vendita;
− data ordine (mese, anno, entrambi);
− importo fattura;
− metodo di pagamento dell’ordine.
9.5) La ricerca svolta dal punto vendita potrà essere condotta sulla base delle seguenti
chiavi:
− codice ordine (tale codice dovrà essere compreso tra tutti i codici degli ordini
effettuati da quel punto vendita che sta effettuando la ricerca: il codice del punto
vendita relativo all’ordine, o agli ordini, selezionato/i dovrà corrispondere al codice
del punto vendita che sta eseguendo la ricerca);
− data ordine (mese, anno, entrambi);
− importo fattura;
− metodo di pagamento dell’ordine.
PARTI INTERESSATE:
Sia il responsabile dei punti vendita e dei fornitori (amministrazione) sia il punto vendita
(pv) avranno accesso alla tabella dello storico degli ordini, ossia quella relativa agli ordini
evasi: il primo la vedrà completamente, il secondo vedrà solo i propri ordini.
Le restanti parti interessate non saranno influenzate da questo requisito.
33
10. GESTIONE ACCESSI
Identificativo 10. GESTIONE ACCESSI

Descrizione Il sistema dovrà garantire l’accesso (autenticato mediante username e
password) alle diverse tipologie di utente che hanno la possibilità di
usufruire dei servizi offerti dal nostro sistema software:
- punto vendita (pv):
- responsabile dei punti vendita e dei fornitori (amministrazione);
- addetto ai prodotti e ai listini (marketing);
- addetto alla gestione degli ordini (logistica).
Motivazione Tale requisito risulterà essere indispensabile all’azienda distributrice e a
tutti i soggetti che ne prenderanno parte attivamente, al fine di garantire
l’interazione del sistema con i soli utenti registrati.
Si tratterà, in pratica, di un requisito necessario a garantire la privacy e la
riservatezza dei dati trattati relativi a coloro che parteciperanno alla
definizione del contratto commerciale (sia dal lato del punto vendita, che
acquista prodotti, che dal lato dei fornitori, che li mettono a disposizione).
Solo gli utenti registrati potranno effettuare operazioni che andranno ad
apportare modifiche all’interno del nostro sistema.
Requisiti di 10.1) La richiesta di registrazione al sistema da parte dell’utente generico
sistema sarà intesa come una richiesta di creazione di un nuovo punto vendita.
10.2) Un utente generico (user) registrato potrà accedere al sistema

tramite una procedura di autenticazione, mediante username e password.
10.3) L’utente generico (user) avrà accesso alla home page del sito.
34
10.4) Ogni password sarà caratterizzata dal fatto di essere costituita da

almeno 7 cifre. (requisito non funzionale)
10.5) Il sistema dovrà garantire ai punti vendita la possibilità di poter

recuperare la propria password, qualora smarrita, specificando, come
informazione di riscontro, il proprio indirizzo e-mail. (requisito funzionale)
PARTI INTERESSATE:
L’utente generico (user) potrà registrarsi al portale web in maniera tale da poter accedere
all’area riservata relativa al punto vendita (pv). Qualora già registrato, l’utente generico
potrà accedere alla propria area riservata attraverso una procedura di login fornendo le
sue credenziali.
Le restanti parti interessate non saranno influenzate da questo requisito.
35
MATRICE DI TRACCIABILITÀ
Le informazioni di tracciabilità sono spesso rappresentate da matrici, che mettono in

relazione i requisiti con gli stakeholder, gli altri requisiti o i moduli del progetto. In una
matrice di tracciabilità ogni requisito viene inserito in una riga e in una colonna, e se
esistono dipendenze tra requisiti, queste vengono registrate nella cella di intersezione
riga/colonna.
Le matrici di tracciabilità possono essere usate per gestire un piccolo numero di requisiti,
ma diventano poco pratiche e costose da mantenere per grandi sistemi. Per tali sistemi si
dovrebbero registrare le informazioni di tracciabilità in un database dei requisiti dove ogni
requisito è esplicitamente collegato ai requisiti connessi; si può dunque valutare l’impatto
dei cambiamenti usando le funzionalità di navigazione del database che, peraltro, può
generare automaticamente le matrici di tracciabilità.
Nel nostro caso adopereremo semplicemente la matrice di tracciabilità per evidenziare,
nella maniera più chiara possibile, le informazioni che legano tra loro i vari requisiti.
Req. 1 2 3 4 5 6 7 8 9 10
ID
1 X X X X X
2 X X
3 X X X
4 X X X X
5 X X X X X X X
6 X X
7 X X X
8 X X
9 X X X
10 X X X X X X X X X
36
CASI D’USO
Un caso d’uso rappresenta una particolare funzionalità fornita da una specifica entità, e
descritta sia dalla serie di messaggi scambiati tra l’entità stessa e gli attori, sia dalla
sequenze di azioni svolte.
L’attore, invece, può essere interpretato come un ruolo o un insieme di ruoli che qualcuno
o qualcosa, esterno al sistema, svolge nell’interagire con il sistema.
DIAGRAMMA DEGLI ATTORI
37
DIAGRAMMA DEI CASI D’USO
38
DESCRIZIONE DEI CASI D’USO
USER
39
Visualizzare home page

Attore principale Utente generico (user).
L’utente generico ha la possibilità di visualizzare la home page del
Descrizione nostro portale web, in maniera tale da poter comprendere che tipo di
servizi vengono ad essere offerti da esso.
È necessario digitare il corretto indirizzo web relativo al nostro
Precondizioni
portale per potervi accedere e visualizzare la relativa home page.
Il caso d’uso viene ad essere attivato automaticamente nel momento
Trigger
in cui si accede alla home page del nostro sito web.
Scenario di base 1. Viene visualizzata la home page del nostro portale web.
1. Registrare punto vendita
Esteso dal caso
2. Login
d’uso
3. Recuperare password
1. Registrati: selezionando la voce “Registrati” si passa alla
compilazione dell’apposito modulo per poter effettuare la
registrazione. Si procede con il relativo caso d’uso.
2. Login: selezionando la voce “Login” si accede ad un’area nella
Extend point quale poter inserire username e password per poter effettuare
l’accreditamento al sito. Si procede con il relativo caso d’uso.
3. Recupera password: selezionando la voce “Recupera password”
si passa alla compilazione dell’apposito modulo per poter
recuperare la password. Si procede con il relativo caso d’uso.
40
Registrare punto vendita

Tramite una ben precisa procedura prevista dal sistema, l’utente
Descrizione generico (user) può procedere alla relativa registrazione presso il
nostro portale web.
L’utente generico deve aver precedentemente eseguito il caso d’uso
“Visualizzare home page”.
Precondizioni L’utente che usufruisce di tale funzionalità deve essere in possesso
di tutti i dati necessari ad una corretta compilazione del modulo di
registrazione previsto dal sistema.
Il caso d’uso si attiva nel momento in cui l’utente generico decide di
Trigger
cliccare sull’apposito pulsante “Registrati”.
1. Si compilano i campi obbligatori relativi ad username, password e
ripeti_password negli appositi riquadri.
2. Si procede alla compilazione del modulo contenente tutti i campi
relativi al punto vendita: nome, partita iva, indirizzo, telefono, e-
mail, orari di apertura.
3. L’utente deve obbligatoriamente spuntare la casella relativa al
Scenario di base
consenso del trattamento dei propri dati personali (Legge sulla
privacy 196/2003).
4. L’utente generico preme il pulsante di conferma “Registra il punto
vendita” dopo aver completato tutti i campi sopra citati.
5. L’utente risulta essere correttamente registrato al nostro sito come
punto vendita.
1.1. Se l’username scelto è già stato utilizzato da un altro utente,
viene visualizzato un messaggio di errore e richiesta
l’immissione di un nuovo username.
1.2. Se la password inserita presenta un numero di cifre inferiore a 7,
Scenario
viene visualizzato un messaggio di errore e richiesta
alternativo di
l’immissione di una nuova password.
insuccesso
1.3. Se il campo ripeti_password è diverso dal valore del campo
relativo alla password viene visualizzato un messaggio di errore.
2.1. Se almeno uno tra i campi relativi al nome, alla partita iva,
all’indirizzo, al telefono, all’e-mail, agli orari di apertura è errato,
41
viene visualizzato un messaggio di errore e richiesta una nuova

immissione dei dati.
3.1. Se non viene spuntata la casella relativa al consenso del
trattamento dei propri dati personali (Legge sulla privacy
196/2003), verrà visualizzato un messaggio di errore che
richiede di dover accettare tali condizioni per poter proseguire
con la registrazione.
Login
L’utente generico si autentica tramite username e password per
Descrizione
poter accedere alla propria area riservata.
L’utente deve essere già registrato al sito (caso d’uso “Registrare
Precondizioni punto vendita”) oppure deve far parte dell’azienda distributrice
(amministrazione, marketing, logistica): deve quindi essere in
possesso di username e password necessarie ad accedere alla
propria area riservata.
Trigger Il caso d’uso si attiva cliccando sull’apposito pulsante “Login”.
1. Vengono inseriti username e password negli appositi riquadri.
2. Dopo aver compilato i campi sopra citati, l’utente generico (user)
Scenario di base
preme il pulsante di conferma “Login”.
3. L’utente accede alla propria area riservata.
3.1. Se l’username e/o la password sono errati, viene visualizzato un
messaggio di errore e richiesta una nuova immissione dei dati.
Scenario 3.2. Se i dati inseriti non corrispondono a nessuna delle tipologie di
alternativo di utente previste dal nostro sistema, viene fornito un messaggio di
insuccesso errore con il quale si richiede di inserire i dati corretti per poter
accedere, o procedere alla fase di registrazione (caso d’uso
“Registrare punto vendita”).
42
Recuperare password
Grazie ad una ben precisa procedura prevista dal sistema che
consiste nell’invio di un messaggio di posta elettronica, l’utente
Descrizione
generico ha la possibilità di recuperare la propria password, qualora
smarrita o dimenticata.
L’utente che usufruisce di tale funzionalità deve essersi già
Precondizioni
precedentemente registrato, e deve essere in possesso dei dati
impiegati nella compilazione del modulo di registrazione previsto dal
sistema.
Il caso d’uso si attiva nel momento in cui l’utente generico decide di
Trigger
cliccare sull’apposito link “Recupera password”.
1. Viene visualizzato un messaggio in cui si richiede all’utente di
inserire il proprio indirizzo e-mail e il proprio username.
2. L’utente inserisce il proprio username ed il relativo indirizzo e-
mail.
3. Dopo aver compilato i campi sopra citati, l’utente generico preme
il pulsante di conferma.
Scenario di base 4. Il sistema si occupa di andare a verificare che l’utente che sta
effettuando la richiesta sia effettivamente un utente registrato:
quindi procede alla verifica della correttezza dei dati inseriti.
5. In caso affermativo, il sistema inoltra un messaggio di posta
elettronica all’indirizzo e-mail specificato, contenente la nuova
password, e ne notifica l’invio con la visualizzazione di un
messaggio a video.
2.1. Se l’utente generico compie un errore nella digitazione
dell’indirizzo e-mail e/o dello username, viene visualizzato un
Scenario messaggio di errore e richiesta una nuova immissione.
alternativo di 5.1. Il sistema non riesce a trovare nessun riscontro tra username ed
insuccesso indirizzo e-mail inseriti dall’utente e quelli riferiti agli utenti
registrati al sistema: viene quindi visualizzato un messaggio di
errore e richiesta una nuova immissione dei dati citati.
43
5.2. Qualora l’utente non sia già registrato non viene inoltrato alcun
tipo di messaggio per e-mail: viene visualizzato un messaggio in
cui si consiglia all’utente di registrarsi per poter interagire con il
sistema.
44
PUNTO VENDITA
45
Visualizzare proprio listino

Attore principale Punto vendita (pv).
Il punto vendita accede all’area del portale che mostra il listino dei
Descrizione
prodotti cui può accedere, con i relativi prezzi di vendita.
L’utente deve essersi autenticato come punto vendita (caso d’uso
Precondizioni
“Login”).
Il caso d’uso si attiva cliccando sull’apposito pulsante “Listino
Trigger
prodotti”.
1. Il sistema mostra una pagina web contenente tutti i prodotti del
listino a cui il punto vendita può accedere.
2. Il punto vendita ha la possibilità di effettuare una ricerca selettiva
all’interno del proprio listino di appartenenza sulla base di
determinati campi tra quelli a disposizione.
Scenario di base 3. Il sistema visualizza i risultati della ricerca fornendo la porzione di
database che corrisponde ai requisiti di ricerca specificati al
passo precedente.
4. Per ogni prodotto visualizzato nel listino, si ha la possibilità di
aggiungerlo al carrello indicandone la quantità.
5. Il carrello è poi gestito dall’apposito caso d’uso “Gestire carrello”.
1.1. Qualora la tabella relativa ai listini non contenga alcuna tupla,
viene visualizzato un messaggio di segnalazione con il quale si
indica che il listino relativo alla propria insegna non è presente in
archivio.
Scenario 1.2. Se il punto vendita non è stato associato ad alcuna insegna, il
alternativo di sistema lo informerà mostrando un messaggio di errore. In
insuccesso questo caso il punto vendita non avrà accesso al listino.
3.1. Se il sistema non riscontra alcun matching sul database in
riferimento ai dati inseriti come chiavi di ricerca, viene
visualizzato un messaggio di notifica con il quale si indica che
non esiste nessun prodotto che rispetti i dati inseriti.
46
Visualizzare proprio listino <<include>> Gestire carrello

Dopo aver visualizzato il listino dei prodotti relativi all’insegna di
appartenenza, il punto vendita seleziona i prodotti di interesse
Descrizione
indicandone le relative quantità, e li aggiunge al carrello per poter poi
eventualmente procedere con la conferma dell’ordine.
“Login”), e deve essere disponibile un listino prodotti relativo alla
Precondizioni propria insegna.
Il punto vendita deve aver precedentemente eseguito il caso d’uso
“Visualizzare proprio listino”.
Il caso d’uso “Gestire carrello” si attiva automaticamente al momento
Trigger della visualizzazione del listino dei prodotti in quanto è incluso nel
caso d’uso “Visualizzare listino”.
1. Visualizzando il listino, il punto vendita ha la possibilità di
selezionare i prodotti di interesse indicandone le relative quantità
Scenario di base ed aggiungerli al carrello.
2. Il contenuto del carrello può essere modificato in qualsiasi
momento, sia in termini di prodotti scelti che di quantità stabilite.
1.1. Se il campo quantità relativo anche ad uno solo dei prodotti
presenti all’interno del carrello è nullo o risulta essere superiore
alla quantità disponibile, il punto vendita non può effettuare
l’ordine e il sistema provvede a visualizzare un messaggio di
Scenario
notifica dell’errore.
alternativo di
1.2. Se il campo quantità relativo anche ad uno solo dei prodotti
insuccesso
presenti all’interno del carrello viene modificato con l’inserimento
di un valore nullo o superiore alla quantità disponibile, il punto
vendita non può effettuare l’ordine e il sistema provvede a
visualizzare un messaggio di notifica dell’errore.
Esteso dal caso
Ordinare prodotto
d’uso
Ordina prodotto: cliccando sul pulsante “Ordina” si avvia la
Extend point procedura di attivazione dell’ordine inerente tutti i prodotti presenti
nel carrello. Si procede con il relativo caso d’uso.
47
Ordinare prodotto
Il punto vendita procede con l’ordinazione dei prodotti e delle relative
Descrizione
quantità attualmente presenti nel carrello.
“Login”), e deve essere disponibile un listino prodotti relativo alla
propria insegna.
Precondizioni Il punto vendita deve aver precedentemente eseguito il caso d’uso
“Gestire carrello”.
Inoltre il carrello non deve essere vuoto, ossia deve contenere
almeno l’indicazione di un prodotto.
Il caso d’uso si attiva cliccando sul pulsante “Ordina” presente
Trigger
all’interno della pagina relativa alla gestione del carrello.
1. Il punto vendita visualizza i prodotti contenuti nel carrello con le
relative quantità e i relativi prezzi di vendita.
2. Il sistema richiede la scelta del metodo di pagamento del quale si
intende usufruire.
3. Viene visualizzato un riepilogo dell’ordine relativo a tutte le
informazioni definite fino a quel momento.
Scenario di base 4. Il sistema richiede la conferma dell’ordine che si effettua
semplicemente andando a cliccare sull’apposito pulsante
“Conferma ordine”.
5. La conferma dell’ordine richiede il reinserimento della password
da parte del punto vendita.
6. Il caso d’uso termina con la visualizzazione di un messaggio nel
quale si afferma l’avvenuta registrazione dell’ordine.
4.1. Se il punto vendita non conferma l’ordine, gli è consentito di
poter tornare alla gestione del carrello.
Scenario
5.1. Se la password inserita è errata, viene visualizzato un
alternativo di
messaggio di errore e richiesto il reinserimento della stessa.
insuccesso
L’ordine resta quindi in sospeso fino a quando non viene inserita
la password corretta.
48
Visualizzare profilo
Il punto vendita ha la possibilità di visualizzare una schermata
Descrizione riassuntiva relativa ai propri dati (utilizzati durante la fase di
registrazione al nostro portale web).
Precondizioni
“Login”).
Trigger Il caso d’uso si attiva selezionando la voce “Visualizza profilo”.
1. Il sistema mostra a video una schermata riassuntiva contenente
informazioni relative a tutti i dati del punto vendita che ha
effettuato l’accesso: nome, partita iva, insegna di appartenenza,
Scenario di base indirizzo, telefono, e-mail, orari di apertura.
2. Il punto vendita ha la possibilità di modificare il proprio profilo
selezionando la voce “Modifica” che provvederà ad attivare il
relativo caso d’uso.
Esteso dal caso
Modificare profilo
d’uso
Modifica profilo: cliccando sul pulsante “Modifica” il sistema consente
all’utente di poter accedere alla sezione di modifica dei propri dati in
Extend point
maniera tale da potervi applicare determinati cambiamenti qualora
necessario. Si procede con il relativo caso d’uso.
49
Modificare profilo
Descrizione Il punto vendita ha la possibilità di modificare i dati del proprio profilo.
Precondizioni “Login”), e deve aver già visualizzato il proprio profilo.(caso d’uso
“Visualizzare profilo”).
Il caso d’uso si attiva cliccando sull’apposito pulsante “Modifica
Trigger
profilo”.
1. Il sistema mostra a video una schermata riassuntiva contente
informazioni relative a tutti i dati del punto vendita che ha
effettuato l’accesso: nome, partita iva, insegna di appartenenza,
indirizzo, telefono, e-mail, orari di apertura.
2. Il punto vendita ha la possibilità di modificare i dati relativi ai
propri campi come desidera. Naturalmente, i nuovi dati inseriti
dovranno presentare un formato idoneo al campo di riferimento
Scenario di base (ad esempio, nell’inserire il numero di telefono non si dovranno
utilizzare caratteri alfabetici, nel digitare un nuovo indirizzo e-mail
dovrà essere presente il carattere @, ecc.).
3. Il punto vendita ha la possibilità di confermare le modifiche
effettuate semplicemente andando a cliccare sul pulsante
“Conferma modifiche”.
4. Il caso d’uso termina con la visualizzazione di un messaggio con
il quale si afferma l’avvenuto aggiornamento del profilo.
2.1. Se i nuovi dati inseriti risultano essere errati, il sistema provvede
a darne notifica mediante un messaggio di errore indicando il
Scenario tipo di problema e richiedendo una nuova immissione dei dati in
alternativo di maniera corretta.
insuccesso 3.1. Se il punto vendita non conferma le modifiche apportate al
proprio profilo, tali modifiche andranno perse mantenendo i dati
originari.
50
Visualizzare storico propri ordini

Il punto vendita ha la possibilità di visualizzare uno storico di tutti gli
ordini che ha effettuato fino a quel momento e che sono stati
Descrizione
effettivamente archiviati come conclusi. Per tale motivo riguarda solo
gli ordini che si trovino nello stato “evaso”.
Precondizioni
“Login”).
Il caso d’uso si attiva cliccando sull’apposito pulsante “Storico degli
Trigger
ordini”.
1. Viene visualizzato l’elenco di tutti gli ordini che sono stati evasi
relativi al punto vendita in questione.
2. Il punto vendita ha la possibilità di filtrare la visualizzazione dello
storico sulla base di determinati campi tra quelli a disposizione.
3. Il sistema visualizza i risultati della ricerca fornendo la porzione di
Scenario di base
passo precedente.
4. Il caso d’uso termina con la visualizzazione dei dati caratteristici
relativi all’ordine in questione nello storico.
5. Il punto vendita ha la possibilità di valutare uno o più ordini
selezionando la voce “Valuta” che provvederà ad attivare il
1.1. Qualora la tabella relativa agli ordini non contenga alcuna tupla,
il sistema visualizza un messaggio di notifica con il quale si
indica che il punto vendita non ha mai effettuato nessun ordine
Scenario oppure che nessuno degli ordini effettuati dal punto vendita si
alternativo di trova nello stato “evaso”.
insuccesso 3.1. Se il sistema non riscontra alcun matching sul database in
non esiste nessun ordine che rispetti i dati inseriti.
Esteso dal caso
Valutare ordine
d’uso
Extend point Valuta ordine: una volta selezionato l’ordine che si desidera valutare,
51
cliccando sul link “Valuta” si prosegue con l’attivazione del caso

d’uso “Valutare ordine” grazie al quale è possibile esprime un
giudizio sul tipo di servizio fornito.
Visualizzare propri ordini

Il punto vendita ha la possibilità di visualizzare una lista contenente
Descrizione tutti i propri ordini attivi, ossia tutti gli ordini che si trovano nello stato
“in preparazione” o nello stato “pervenuto”.
Precondizioni
“Login”).
Trigger Il caso d’uso si attiva cliccando sull’apposito pulsante “Ordini attivi”.
1. Viene visualizzato l’elenco di tutti gli ordini attivi relativi al punto
vendita in questione.
2. Il punto vendita ha la possibilità, ove possibile (ossia solo per gli
ordini che si trovano nello stato “pervenuto”), di valutare uno o più
ordini selezionando la voce “Valuta” che provvederà ad attivare il
3. Il punto vendita ha la possibilità di filtrare la visualizzazione dei
Scenario di base
propri ordini sulla base di determinati campi tra quelli a
disposizione.
passo precedente.
relativi all’ordine in questione.
1.1. Qualora la tabella relativa agli ordini attivi non contenga alcuna
Scenario tupla, il sistema visualizza un messaggio di notifica con il quale
alternativo di si indica che in quel dato istante il punto vendita non presenta
insuccesso alcun ordine attivo.
52

Esteso dal caso
Valutare ordine
d’uso
Valutare ordine: una volta selezionato l’ordine che si desidera
valutare, cliccando sul link “Valuta” si prosegue con l’attivazione del
Extend point
caso d’uso “Valutare ordine” grazie al quale è possibile esprime un
giudizio sul tipo di servizio fornito.
53
Valutare ordine
Il punto vendita ha la possibilità di esprimere un giudizio sull’ordine,
o meglio sul servizio ricevuto dall’azienda distributrice attraverso
Descrizione
l’ordine stesso. La valutazione consta in un numero compreso tra 1 e
4, utilizzato come indice di gradimento del servizio offerto.
La valutazione dell’ordine può essere effettuata se e solo se l’ordine
Precondizioni in questione esiste e si trova nello stato “pervenuto” o nello stato
“evaso”.
Quando un ordine si trova nello stato “pervenuto” o nello stato
“evaso”, il sistema consente al punto vendita di poter effettuare una
Trigger
valutazione su di esso tramite apposita sezione di valutazione
dell’ordine.
1. Se un ordine passa nello stato “pervenuto” o nello stato “evaso”,
può essere valutato in qualsiasi momento.
1.1.Gli ordini “pervenuti” possono essere valutati dalla schermata
che visualizza gli ordini attivi (caso d’uso “Visualizzare propri
ordini”).
Scenario di base
1.2.Gli ordini “evasi” possono essere valutati dalla schermata che
visualizza lo storico dei propri ordini (caso d’uso “Visualizzare
storico propri ordini”).
2. È necessario confermare la valutazione effettuata in quanto non
sarà possibile modificarla in seguito.
Scenario
2.1. Se la valutazione dell’ordine non viene confermata, andrà persa
alternativo di
e sarà possibile effettuarla nuovamente in seguito.
insuccesso
54
AMMINISTRAZIONE
55
Gestire fornitori
Attore principale Responsabile dei punti vendita e dei fornitori (amministrazione).
L’amministrazione gestisce tutti i fornitori dell’azienda distributrice.
Pertanto ha la possibilità di visualizzare, aggiungere, modificare e
Descrizione
rimuovere i dati relativi a tutti i fornitori con i quali intrattiene rapporti
di tipo commerciale. (*)
L’utente deve essersi loggato come amministrazione (caso d’uso
Precondizioni
“Login”).
Il caso d’uso si attiva selezionando l’apposita voce dal menù relativo
Trigger
all’amministrazione.
1. Viene visualizzato l’elenco di tutti i fornitori con i quali l’azienda
distributrice intrattiene rapporti di tipo commerciale.
2. L’amministrazione ha la possibilità di filtrare la visualizzazione dei
fornitori sulla base di determinati campi tra quelli a disposizione.
Scenario di base passo precedente.
4. Il sistema permette all’amministrazione di selezionare quattro
differenti opzioni riguardo la visualizzazione, l’aggiunta, la
modifica o la rimozione di un dato fornitore.
5. A seconda della scelta effettuata dall’amministrazione riguardo
l’attività da svolgere, il sistema provvede ad attivare il relativo
caso d’uso.
1.1. Se la tabella dei fornitori non contiene alcuna tupla, viene
visualizzato un messaggio con il quale si indica che nessun
Scenario fornitore è presente in archivio.
alternativo di 2.1. Se il sistema non riscontra alcun matching sul database in
insuccesso riferimento ai dati inseriti come chiavi di ricerca, viene
non esiste nessun fornitore che rispetti i dati inseriti.
1. Visualizzare fornitore
Esteso dal caso 2. Aggiungere fornitore
d’uso 3. Modificare fornitore
4. Rimuovere fornitore
56
1. Visualizza fornitore: l’amministrazione visualizza i dati relativi ad

un determinato fornitore. Si procede con il relativo caso d’uso.
2. Aggiungi fornitore: l’amministrazione provvede ad aggiungere un
nuovo fornitore nel database. Si procede con il relativo caso
d’uso.
Extend point 3. Modifica fornitore: l’amministrazione modifica i dati caratteristici
relativi ad un determinato fornitore. Si procede con il relativo caso
d’uso.
4. Rimuovi fornitore: l’amministrazione rimuove dal database tutti i
dati relativi ad un determinato fornitore. Si procede con il relativo
caso d’uso.
(*) Si noti che il portale web è destinato alla comunicazione tra punto vendita e azienda
distributrice, quindi, la gestione dei fornitori è molto più limitata rispetto a quella dei punti
vendita. Serve esclusivamente a garantire una tracciabilità dei prodotti.
Visualizzare fornitore
L’amministrazione ha la possibilità di visualizzare i dati caratteristici
Descrizione relativi ad ogni fornitore con il quale l’azienda distributrice intrattiene
rapporti di tipo commerciale.
L’amministrazione deve aver precedentemente eseguito il caso
Precondizioni d’uso “Gestire fornitori” e selezionato il fornitore che si intende
visualizzare.
Il caso d’uso si attiva selezionando la voce “Visualizza” presente
Trigger nell’apposito menù di gestione dei fornitori (caso d’uso “Gestire
fornitori”).
1. A partire dalla visualizzazione dell’elenco di tutti i fornitori,
l’amministrazione visualizza i dati caratteristici relativi al fornitore
Scenario di base selezionato.
relativi al fornitore in questione.
57
Aggiungere fornitore
L’amministrazione provvede ad aggiungere un nuovo fornitore nel
Descrizione
database, inserendo tutti i dati relativi ad esso.
Precondizioni
d’uso “Gestire fornitori”.
Il caso d’uso si attiva selezionando la voce “Aggiungi” presente
fornitori”).
1. L’amministrazione inserisce i dati relativi al nuovo fornitore
compilando gli appositi campi a disposizione. I dati inseriti devono
rispettare il formato relativo al campo in questione.
2. L’amministrazione ha la possibilità di confermare l’inserimento del
Scenario di base nuovo fornitore semplicemente andando a cliccare sull’apposito
pulsante “Conferma inserimento”.
3. Il caso d’uso termina con la visualizzazione di un messaggio
relativo all’avvenuto inserimento del nuovo fornitore all’interno del
database.
1.1. Se i nuovi dati inseriti non rispettano il formato relativo al campo
al quale fanno riferimento, il sistema notifica tale situazione con
un messaggio di errore e invita l’amministrazione ad apportare
le opportune modifiche.
Scenario 1.2. Se i nuovi dati inseriti fanno riferimento ad un fornitore già
alternativo di presente all’interno del database, il sistema notifica tale
insuccesso situazione con un messaggio di errore e invita l’amministrazione
ad apportare le opportune modifiche.
2.1. Se l’amministrazione non conferma l’inserimento del nuovo
fornitore, i relativi dati andranno persi e il fornitore non verrà
aggiunto al database.
58
Modificare fornitore
L’amministrazione ha la possibilità di modificare i dati relativi ad un
Descrizione
determinato fornitore presente all’interno del database.
modificare.
Il caso d’uso si attiva selezionando la voce “Modifica” presente
fornitori”).
1. L’amministrazione ha la possibilità di modificare i dati caratteristici
relativi al fornitore selezionato.
2. L’amministrazione modifica i dati relativi al fornitore in questione
Scenario di base
3. L’amministrazione ha la possibilità di confermare le modifiche
effettuate semplicemente andando a cliccare sul pulsante
riguardo l’avvenuta modifica dei dati relativi al fornitore in esame.
un messaggio di errore e invita l’amministrazione ad apportare
le opportune modifiche.
Scenario 2.2. Se i nuovi dati inseriti fanno riferimento ad un fornitore già
insuccesso situazione con un messaggio di errore e invita l’amministrazione
ad apportare le opportune modifiche.
3.1. Se l’amministrazione non conferma le modifiche apportate al
fornitore, tali modifiche andranno perse mantenendo i dati
originari.
59
Rimuovere fornitore
L’amministrazione rimuove dal database tutti i dati relativi ad un
Descrizione
determinato fornitore.
eliminare dal database.
Il caso d’uso si attiva selezionando la voce “Rimuovi” presente
fornitori”).
1. L’amministrazione ha la possibilità di eliminare tutti i dati
caratteristici relativi al fornitore selezionato.
2. L’amministrazione ha la possibilità di confermare la rimozione del
fornitore semplicemente andando a cliccare sul pulsante
Scenario di base
“Conferma eliminazione”.
riguardo l’avvenuta eliminazione di tutti i dati relativi al fornitore in
esame.
2.1. Se l’amministrazione non conferma l’eliminazione del fornitore,
verranno mantenuti nel database tutti i dati relativi al fornitore in
questione.
Scenario
3.1. Se è presente anche un solo prodotto associato al fornitore che
alternativo di
si intende eliminare, l’eliminazione fallisce e il sistema notifica
insuccesso
tale situazione con un messaggio di segnalazione indicando il
motivo per il quale il fornitore non può essere rimosso dal
database.
60
Gestire punti vendita

L’amministrazione gestisce tutti i punti vendita dell’azienda
distributrice. Pertanto ha la possibilità di visualizzare e rimuovere i
dati relativi a tutti i punti vendita con i quali intrattiene rapporti di tipo
commerciale.
Descrizione Si dovrà occupare, inoltre, dell’assegnazione di ciascun punto
vendita ad una determinata insegna: tutto ciò allo scopo di garantire
l’accesso al proprio listino e quindi consentirgli di effettuare ordini
accedendo all’apposita area. L’assegnamento dell’insegna equivale
ad una conferma della registrazione.
L’utente deve essersi loggato come amministrazione (caso d’uso
Precondizioni
“Login”).
Trigger
all’amministrazione.
1. Viene visualizzato l’elenco di tutti i punti vendita con i quali
l’azienda distributrice intrattiene rapporti di tipo commerciale.
2. L’amministrazione ha la possibilità di filtrare la visualizzazione dei
punti vendita sulla base di determinati campi tra quelli a
disposizione.
passo precedente.
Scenario di base
4. Il sistema permette all’amministrazione di selezionare due
differenti opzioni riguardo la visualizzazione o la rimozione di un
dato punto vendita.
5. A seconda della scelta effettuata dall’amministrazione riguardo
l’attività da svolgere, il sistema provvede ad attivare il relativo
caso d’uso.
6. L’amministrazione ha la possibilità di associare ad un determinato
punto vendita una insegna.
Scenario 1.1. Se la tabella dei punti vendita non contiene alcuna tupla, viene
alternativo di visualizzato un messaggio di notifica con il quale si indica che
insuccesso nessun punto vendita è presente in archivio.
61

non esiste nessun punto vendita che rispetti i dati inseriti.
Esteso dal caso 1. Visualizzare punto vendita
d’uso 2. Rimuovere punto vendita
1. Visualizza punto vendita: l’amministrazione visualizza i dati relativi
ad un determinato punto vendita. Si procede con il relativo caso
d’uso.
Extend point
2. Rimuovi punto vendita: l’amministrazione rimuove dal database
tutti i dati relativi ad un determinato punto vendita. Si procede con
il relativo caso d’uso.
Visualizzare punto vendita

L’amministrazione ha la possibilità di visualizzare i dati caratteristici
Descrizione relativi ad ogni punto vendita con il quale l’azienda distributrice
intrattiene rapporti di tipo commerciale.
Precondizioni d’uso “Gestire punti vendita” e selezionato il punto vendita che si
intende visualizzare.
Trigger nell’apposito menù di gestione dei punti vendita (caso d’uso “Gestire
punti vendita”).
1. A partire dalla visualizzazione dell’elenco di tutti i punti vendita,
l’amministrazione ha la possibilità di visualizzare i dati
Scenario di base caratteristici relativi al punto vendita selezionato.
relativi al punto vendita in questione.
62
Rimuovere punto vendita

L’amministrazione rimuove dal database tutti i dati relativi ad un
Descrizione
determinato punto vendita.
Precondizioni d’uso “Gestire punti vendita” e selezionato il punto vendita che si
intende eliminare dal database.
Il caso d’uso si attiva selezionando la voce “Rimuovi” presente
Trigger nell’apposito menù di gestione dei punti vendita (caso d’uso “Gestire
punti vendita”).
1. L’amministrazione ha la possibilità di eliminare tutti i dati
caratteristici relativi al punto vendita selezionato.
2. L’amministrazione ha la possibilità di confermare la rimozione del
punto vendita semplicemente andando a cliccare sul pulsante
Scenario di base
riguardo l’avvenuta eliminazione di tutti i dati relativi al punto
vendita in esame.
2.1. Se l’amministrazione non conferma l’eliminazione del punto
vendita, verranno mantenuti nel database tutti i dati relativi al
unto vendita in questione.
Scenario
3.1. In riferimento al punto vendita in questione, se è presente anche
alternativo di
un solo ordine che si trova in uno stato diverso da quello
insuccesso
“evaso”, l’eliminazione fallisce e il sistema notifica tale situazione
con un messaggio di segnalazione indicando il motivo per il
quale il punto vendita non può essere rimosso dal database.
63
Visualizzare storico ordini

L’amministrazione ha la possibilità di visualizzare uno storico di tutti
gli ordini effettuati dai vari punti vendita e archiviati come conclusi.
Descrizione
Per tale motivo riguarda solo gli ordini che si trovino nello stato
“evaso”.
L’utente deve essersi autenticato come amministrazione (caso d’uso
Precondizioni
“Login”).
Il caso d’uso si attiva cliccando sull’apposito pulsante “Storico degli
Trigger
ordini”.
1. Viene visualizzato l’elenco di tutti gli ordini che sono stati evasi
relativi ai diversi punti vendita ai quali l’azienda fa riferimento,
andando a fornite in tal modo una serie di informazioni di tipo
statistico.
2. L’amministrazione ha la possibilità di filtrare la visualizzazione
dello storico sulla base di determinati campi tra quelli a
Scenario di base
disposizione.
passo precedente.
relativi all’ordine in questione nello storico.
1.1. Se la tabella dello storico non contiene alcuna tupla, viene
Scenario nessun ordine si trova nello stato “evaso”.
64
Visualizzare ordini
L’amministrazione ha la possibilità di visualizzare una lista
Descrizione contenente tutti gli ordini attivi, ossia tutti gli ordini che si trovano
nello stato “in preparazione” o nello stato “pervenuto”.
L’utente deve essersi autenticato come amministrazione (caso d’uso
Precondizioni
“Login”).
Trigger Il caso d’uso si attiva cliccando sull’apposito pulsante “Ordini attivi”.
1. Viene visualizzato l’elenco di tutti gli ordini attivi relativi ai diversi
punti vendita dell’azienda distributrice.
2. L’amministrazione ha la possibilità di filtrare la visualizzazione
degli ordini attivi sulla base di determinati campi tra quelli a
disposizione.
Scenario di base
passo precedente.
tupla, il sistema visualizza un messaggio di notifica con il quale
si indica che in quel dato istante nessun punto vendita presenta
Scenario
alcun ordine attivo.
alternativo di
insuccesso
non esiste nessun ordine attivo che rispetti i dati inseriti.
65
MARKETING
66
Gestire listini
Attore principale Addetto ai prodotti e ai listini (marketing).
Il marketing gestisce tutti i listini dell’azienda distributrice. Pertanto
Descrizione ha la possibilità di visualizzare, aggiungere, modificare e rimuovere i
dati relativi a tutti i listini dei prodotti in vendita.
L’utente deve essersi autenticato come marketing (caso d’uso
Precondizioni
“Login”).
Trigger
alla sezione marketing.
1. Viene visualizzato l’elenco di tutti i listini prodotti presenti nel
database in quel dato istante.
2. Il marketing ha la possibilità di filtrare la visualizzazione dei listini
sulla base di determinati campi tra quelli a disposizione.
Scenario di base
passo precedente.
4. Il sistema permette al marketing di selezionare quattro differenti
opzioni riguardo la visualizzazione, l’aggiunta, la modifica o la
rimozione di un dato listino prodotti.
5. A seconda della scelta effettuata dal marketing riguardo l’attività
da svolgere, il sistema provvede ad attivare il relativo caso d’uso.
1.1. Se la tabella dei listini non contiene alcuna tupla, viene
Scenario listino prodotti è presente in archivio.
non esiste nessun listino prodotti che rispetti i dati inseriti.
1. Visualizzare listino
Esteso dal caso 2. Aggiungere listino
d’uso 3. Modificare listino
4. Rimuovere listino
1. Visualizza listino: il marketing visualizza i dati relativi ad un
Extend point
determinato listino prodotti. Si procede con il relativo caso d’uso.
67
2. Aggiungi listino: il marketing provvede ad aggiungere un nuovo

listino, ossia una nuova insegna, nel database. Si procede con il
3. Modifica listino: il marketing modifica i dati caratteristici relativi ad
un determinato listino prodotti. Si procede con il relativo caso
d’uso.
4. Rimuovi listino: il marketing rimuove dal database tutti i dati
relativi ad un determinato listino. Si procede con il relativo caso
d’uso.
Visualizzare listino
Il marketing ha la possibilità di visualizzare i dati relativi al listino
Descrizione
(insegna) selezionato.
Il marketing deve aver precedentemente eseguito il caso d’uso
Precondizioni “Gestire listini” e selezionato il listino prodotti che si intende
visualizzare.
Trigger nell’apposito menù di gestione delle insegne (caso d’uso “Gestire
listini”).
1. A partire dalla visualizzazione dell’elenco di tutte le insegne, il
marketing visualizza i dati caratteristici relativi al listino prodotti
relativi al listino prodotti in questione.
68
Aggiungere listino
Il marketing provvede ad aggiungere una nuova insegna
Descrizione
commerciale nel database, inserendo tutti i dati relativi ad essa.
Precondizioni
“Gestire listini”.
Il caso d’uso si attiva cliccando sulla voce “Aggiungi” presente
listini”).
1. Il marketing inserisce i dati relativi al nuovo listino prodotti
2. Il marketing ha la possibilità di confermare l’inserimento del nuovo
Scenario di base listino semplicemente andando a cliccare sull’apposito pulsante
“Conferma inserimento”.
relativo all’avvenuto inserimento del nuovo listino prodotti
all’interno del database.
un messaggio di errore e invita il marketing ad apportare le
opportune modifiche.
Scenario 1.2. Se i nuovi dati inseriti fanno riferimento ad un listino prodotti già
insuccesso situazione con un messaggio di errore e invita il marketing ad
apportare le opportune modifiche.
2.1. Se il marketing non conferma l’inserimento del nuovo listino, i
relativi dati andranno persi e il listino prodotti non verrà aggiunto
al database.
69
Modificare listino
Il marketing ha la possibilità di modificare i dati relativi ad un
Descrizione
determinato listino prodotti presente all’interno del database.
Precondizioni “Gestire listini” e selezionato il listino prodotti che si intende
modificare.
Il caso d’uso si attiva cliccando sulla voce “Modifica” presente
listini”).
1. Il marketing ha la possibilità di modificare i dati caratteristici
relativi al listino selezionato.
2. Il marketing modifica i dati relativi al listino in questione
compilando gli appositi campi a disposizione (come ad esempio
lo sconto del listino), e aggiungendo/rimuovendo prodotti al/dal
listino. I dati inseriti devono rispettare il formato relativo al campo
Scenario di base in questione.
3. Il marketing ha la possibilità di confermare le modifiche effettuate
riguardo l’avvenuta modifica dei dati relativi al listino prodotti in
esame.
Scenario
2.2. Se i nuovi dati inseriti fanno riferimento ad un listino prodotti già
alternativo di
presente all’interno del database, il sistema notifica tale
insuccesso
situazione con un messaggio di errore e invita il marketing ad
apportare le opportune modifiche.
3.1. Se il marketing non conferma le modifiche apportate al listino,
tali modifiche andranno perse mantenendo i dati originari.
70
Rimuovere listino
Il marketing rimuove dal database tutti i dati relativi ad un
Descrizione
determinato listino prodotti.
Precondizioni “Gestire listini” e selezionato il listino che si intende eliminare dal
database.
Il caso d’uso si attiva cliccando sulla voce “Rimuovi” presente
listini”).
1. Il marketing ha la possibilità di eliminare tutti i dati caratteristici
relativi al listino selezionato.
2. Il marketing ha la possibilità di confermare la rimozione del listino
semplicemente andando a cliccare sul pulsante “Conferma
Scenario di base
eliminazione”.
riguardo l’avvenuta eliminazione di tutti i dati relativi al listino
prodotti in esame.
2.1. Se il marketing non conferma l’eliminazione dell’insegna,
verranno mantenuti nel database tutti i dati relativi al listino
prodotti in questione.
Scenario
3.1. Se è presente anche un solo punto vendita associato al listino
alternativo di
che si intende eliminare, l’eliminazione fallisce e il sistema
insuccesso
notifica tale situazione con un messaggio di segnalazione
indicando il motivo per il quale il listino non può essere rimosso
dal database.
71
Gestire prodotti
Il marketing gestisce tutti i prodotti dell’azienda distributrice. Pertanto
Descrizione ha la possibilità di visualizzare, aggiungere, modificare e rimuovere i
dati relativi a tutti i prodotti in vendita.
Precondizioni
“Login”).
Trigger
alla sezione marketing.
1. Viene visualizzato l’elenco di tutti i prodotti catalogati all’interno
del database in quel dato istante.
2. Il marketing ha la possibilità di filtrare la visualizzazione dei
prodotti sulla base di determinati campi tra quelli a disposizione.
Scenario di base
passo precedente.
4. Il sistema permette al marketing di selezionare quattro differenti
opzioni riguardo la visualizzazione, l’aggiunta, la modifica o la
rimozione di un dato prodotto.
5. A seconda della scelta effettuata dal marketing riguardo l’attività
da svolgere, il sistema provvede ad attivare il relativo caso d’uso.
1.1. Se la tabella dei prodotti non contiene alcuna tupla, viene
Scenario prodotto è presente in archivio.
non esiste nessun prodotto che rispetti i dati inseriti.
1. Visualizzare prodotto
Esteso dal caso 2. Aggiungere prodotto
d’uso 3. Modificare prodotto
4. Rimuovere prodotto
1. Visualizza prodotto: il marketing visualizza i dati relativi ad un
Extend point
determinato prodotto. Si procede con il relativo caso d’uso.
72
2. Aggiungi prodotto: il marketing provvede ad aggiungere un nuovo

prodotto nel database. Si procede con il relativo caso d’uso.
3. Modifica prodotto: il marketing modifica i dati caratteristici relativi
ad un determinato prodotto. Si procede con il relativo caso d’uso.
4. Rimuovi prodotto: il marketing rimuove dal database tutti i dati
relativi ad un determinato prodotto. Si procede con il relativo caso
d’uso.
Visualizzare prodotto
Il marketing ha la possibilità di visualizzare una lista contenente tutti i
Descrizione prodotti che l’azienda distributrice mette sul mercato e, per ognuno
di essi, può visionare i relativi dati caratteristici.
Precondizioni “Gestire prodotti” e selezionato il prodotto che si intende
visualizzare.
Il caso d’uso si attiva cliccando sulla voce “Visualizza” presente
Trigger nell’apposito menù di gestione dei prodotti (caso d’uso “Gestire
prodotti”).
1. A partire dalla visualizzazione dell’elenco di tutti i prodotti, il
marketing visualizza i dati caratteristici relativi al prodotto
relativi al prodotto in questione.
73
Aggiungere prodotto
Il marketing provvede ad aggiungere un nuovo prodotto nel
Descrizione
database, inserendo tutti i dati relativi ad esso.
Precondizioni
“Gestire prodotti”.
Il caso d’uso si attiva cliccando sulla voce “Aggiungi” presente
prodotti”).
1. Il marketing inserisce i dati relativi al nuovo prodotto compilando
gli appositi campi a disposizione. I dati inseriti devono rispettare il
formato relativo al campo in questione.
2. Il marketing ha la possibilità di confermare l’inserimento del nuovo
Scenario di base prodotto semplicemente andando a cliccare sull’apposito pulsante
“Conferma inserimento”.
relativo all’avvenuto inserimento del nuovo prodotto all’interno del
database.
Scenario un messaggio di errore e invita il marketing ad apportare le
alternativo di opportune modifiche.
insuccesso 2.1. Se il marketing non conferma l’inserimento del nuovo prodotto, i
relativi dati andranno persi e il nuovo prodotto non verrà
aggiunto al database.
74
Modificare prodotto
Il marketing ha la possibilità di modificare i dati relativi ad un
Descrizione
determinato prodotto presente all’interno del database.
Precondizioni
“Gestire prodotti” e selezionato il prodotto che si intende modificare.
Il caso d’uso si attiva cliccando sulla voce “Modifica” presente
prodotti”).
1. Il marketing ha la possibilità di modificare i dati caratteristici
relativi al prodotto selezionato.
2. Il marketing modifica i dati relativi al prodotto in questione
Scenario di base
3. Il marketing ha la possibilità di confermare le modifiche effettuate
riguardo l’avvenuta modifica dei dati relativi al prodotto in esame.
Scenario
3.1. Se il marketing non conferma le modifiche apportate al prodotto,
alternativo di
tali modifiche andranno perse mantenendo i dati originari.
insuccesso
4.1. Se è presente anche un solo ordine associato al prodotto che si
intende modificare, la modifica fallisce e il sistema notifica tale
situazione con un messaggio di segnalazione indicando il motivo
per il quale il prodotto non può essere modificato.
75
Rimuovere prodotto
Il marketing rimuove dal database tutti i dati relativi ad un
Descrizione
determinato prodotto.
Precondizioni “Gestire prodotti” e selezionato il prodotto che si intende eliminare
dal database.
Il caso d’uso si attiva cliccando sulla voce “Rimuovi” presente
prodotti”).
1. Il marketing ha la possibilità di eliminare tutti i dati caratteristici
relativi al prodotto selezionato.
2. Il marketing ha la possibilità di confermare la rimozione del
prodotto semplicemente andando a cliccare sul pulsante
Scenario di base
riguardo l’avvenuta eliminazione di tutti i dati relativi al prodotto in
esame.
2.1. Se il marketing non conferma l’eliminazione del prodotto,
verranno mantenuti nel database tutti i dati relativi al prodotto in
questione.
Scenario
3.1. Se è presente anche un solo ordine (in preparazione) associato
alternativo di
al prodotto che si intende eliminare, l’eliminazione fallisce e il
insuccesso
sistema notifica tale situazione con un messaggio di
segnalazione indicando il motivo per il quale il prodotto non può
essere rimosso dal database.
76
Il marketing ha la possibilità di visualizzare i dati caratteristici relativi
Descrizione ad ogni fornitore con il quale l’azienda distributrice intrattiene rapporti
di tipo commerciale.
Precondizioni
“Login”).
Trigger Il caso d’uso si attiva selezionando la voce “Visualizza fornitori”.
1. A partire dalla visualizzazione dell’elenco di tutti i fornitori, il
marketing visualizza i dati caratteristici relativi al fornitore
77
LOGISTICA
78
Visualizzare ordini
Attore principale Addetto alla gestione degli ordini (logistica).
La logistica ha la possibilità di visualizzare una lista contenente tutti
Descrizione gli ordini attivi, ossia tutti gli ordini che si trovano nello stato “in
preparazione” o nello stato “pervenuto”.
L’utente deve essersi autenticato come logistica (caso d’uso
Precondizioni
“Login”).
Il caso d’uso si attiva selezionando la voce “Ordini attivi”
Trigger
nell’apposito menù di gestione degli ordini.
1. Viene visualizzato l’elenco di tutti gli ordini attivi relativi ai diversi
punti vendita dell’azienda distributrice.
2. La logistica ha la possibilità di filtrare la visualizzazione degli
ordini attivi sulla base di determinati campi tra quelli a
disposizione.
Scenario di base
passo precedente.
4. La logistica ha la possibilità di aggiornare lo stato di un dato
ordine richiamando il relativo caso d’uso.
tupla, il sistema visualizza un messaggio di notifica con il quale
si indica che in quel dato istante nessun punto vendita presenta
Scenario
alcun ordine attivo.
alternativo di
insuccesso
non esiste nessun ordine attivo che rispetti i dati inseriti.
Esteso dal caso
Aggiornare stato ordine
d’uso
Aggiorna stato ordine: selezionando la voce “Aggiorna stato ordine”
Extend point si procede con l’aggiornamento dello stato dell’ordine in base al suo
avanzamento. Si passa al relativo caso d’uso.
79
Visualizzare ordini <<include>> Visualizzare stato ordine

Tramite una ben precisa procedura prevista dal sistema, la logistica
ha la possibilità di visualizzare lo stato degli ordini al fine di poter
effettuare determinate valutazioni di tipo strategico, come ad
Descrizione
esempio l’organizzazione delle spedizioni. Inoltre, la logistica può
svolgere una ricerca selettiva per poter individuare gli ordini
d’interesse.
La logistica deve aver precedentemente eseguito il caso d’uso
Precondizioni
“Visualizzare ordini”.
Il caso d’uso “Visualizzare stato ordine” si attiva automaticamente al
Trigger momento della visualizzazione degli ordini in quanto è incluso nel
caso d’uso “Visualizzare ordini”.
1. Quando viene visualizzata la tabella degli ordini (caso d’uso
“Visualizzare ordini”), viene visualizzato lo stato attuale di ogni
Scenario di base ordine.
2. La logistica ha la possibilità di effettuare una ricerca selettiva sul
database in base agli ordini di cui interessa conoscere lo stato.
Scenario 2.1. Se la tabella degli ordini non contiene alcuna tupla
alternativo di corrispondente alla chiave di ricerca specificata, viene
insuccesso visualizzato un messaggio di errore.
80

ha la possibilità di modificare lo stato degli ordini in maniera tale da
Descrizione
tenerne traccia costantemente. Inoltre ha la possibilità di effettuare
una ricerca selettiva per individuare gli ordini d’interesse.
La logistica deve aver precedentemente eseguito il caso d’uso
“Visualizzare ordini”. E’ necessario garantire che tale campo sia
Precondizioni
costantemente sotto controllo e che sia rappresentativo dell’effettivo
stato in cui si trova l’ordine.
Il caso d’uso si attiva quando la logistica ha bisogno di aggiornare lo
Trigger
stato di avanzamento di uno o più ordini.
1. Il sistema mostra la tabella degli ordini (caso d’uso “Visualizzare
ordini”) sui quali è possibile modificare lo stato.
2. La logistica ha la possibilità di effettuare una ricerca selettiva sul
database in base agli ordini per i quali intende modificare lo stato.
3. Si procede alla modifica del campo.
3.1. Lo stato può contenere uno tra i seguenti valori: “in
preparazione”, “pervenuto”, “evaso”, “annullato”.
3.2. Deve essere verificato l’ordine cronologico previsto dai
Scenario di base
requisiti.
3.3. Lo stato “annullato” può essere inserito solo se l’ordine al
quale si fa riferimento in quel momento non presenta lo stato
“evaso”.
4. La logistica ha la possibilità di confermare l’aggiornamento dello
stato cliccando semplicemente sul pulsante “Conferma”.
5. Il sistema mostra un messaggio con il quale si afferma l’avvenuta
modifica.
Scenario
5.2. Se non si conferma la modifica, tutti i cambiamenti effettuati
alternativo di
vanno persi e restano i dati precedenti
insuccesso
81
Descrizione ha la possibilità di visualizzare i fornitori di tutti i prodotti
effettivamente distribuiti dal nostro sito commerciale.
Precondizioni
“Login”).
Il caso d’uso si attiva entrando nell’apposito menù e scegliendo la
Trigger
relativa voce “Visualizza fornitori”.
1. Si clicca sull’apposita opzione del menù “Visualizza fornitori” e si
apre una pagina contenente la tabella con tutti i fornitori presenti
al momento della richiesta.
2. La logistica può effettuare una ricerca selettiva sul database in
base ai dati a disposizione.
Scenario di base database che corrisponde ai requisiti di ricerca specificati al
passo precedente.
4. Cliccando sul link “Visualizza” la logistica ha la possibilità di
visualizzare tutti i dati caratteristici presenti in archivio relativi al
fornitore desiderato.
1.1. Se la tabella dei fornitori non contiene alcuna tupla, viene
visualizzato un messaggio di errore con il quale si indica che
Scenario nessun fornitore è presente in archivio.
alternativo di 3.1. Se i dati inseriti come chiave di ricerca non soddisfano alcun
insuccesso matching sul database, il sistema mostra un messaggio di
notifica con il quale si indica che non esiste nessun fornitore che
rispetti i dati inseriti.
82
Descrizione deve avere la possibilità di visualizzare tutti i prodotti a disposizione
al momento in cui viene effettuata la richiesta.
Precondizioni
“Login”).
Trigger
relativa voce “Visualizza prodotti”.
1. Si clicca sull’apposita opzione del menù “Visualizza prodotti” e si
apre una pagina contenente la tabella con tutti i prodotti presenti
al momento della richiesta.
passo precedente.
prodotto desiderato.
relativi al prodotto in questione.
1.2. Se la tabella dei prodotti non contiene alcuna tupla, viene
Scenario nessun prodotto è presente in archivio.
notifica con il quale si indica che non esiste nessun prodotto che
83
Descrizione deve avere la possibilità di visualizzare tutti i listini prodotti a
disposizione al momento in cui viene effettuata la richiesta.
Precondizioni
“Login”).
Trigger
relativa voce “Visualizza listini ”.
1. Si clicca sull’apposita opzione del menù “Visualizza listini” e si
apre una pagina contenente la tabella con tutti i listini prodotti
presenti al momento della richiesta.
passo precedente.
listino prodotti desiderato.
relativi al listino prodotti in questione.
1.2. Se la tabella dei listini non contiene alcuna tupla, viene
Scenario nessun listino è presente in archivio.
notifica con il quale si indica che non esiste nessun prodotto che
84
MODELLO E/R
Il modello entity-relationship (modello entità-relazione) è un modello per la

rappresentazione concettuale dei dati ad un alto livello di astrazione. Viene utilizzato per
tradurre le informazioni risultanti dall’analisi di un determinato dominio in uno schema
concettuale.
FORNITORE
1
N
N PRODOTTO IN N 1
PRODOTTO
LISTINO
N
N
1 N 1
LISTINO ORDINE REPARTO
1 N
1
N PUNTO
STORICO
VENDITA
85
DIAGRAMMA DELLE CLASSI DI ANALISI
86
Bavaro - Conversano - Gaeta - Gallitelli – Saponieri Fase di progettazione
PROGETTAZIONE
SCELTE PROGETTUALI
I programmi che verranno utilizzati per l’implementazione del nostro sistema software, che
realizzerà un portale web tramite il quale saranno consentire le attività di compravendita
nell’ambito della grande distribuzione, sono elencati qui di seguito. Tutto ciò allo scopo di
consentire, anche all’occhio meno esperto o comunque a tutti coloro che risultino
interessati agli ambienti di sviluppo utilizzati, di avere delle indicazioni sulle potenzialità e
sulle funzionalità principali dei programmi da noi impiegati. In particolare daremo anche
una breve descrizione esplicativa per ognuno di essi:
- XAMPP 1.7.3
- phpMyAdmin
- Mysql
- Apache
- CodeIgniter
In realtà possiamo dire che, in un certo senso, il primo degli ambienti su indicati (XAMPP)
racchiude gli altri sistemi software in maniera armonica ed esaustiva, considerando le
applicazioni cui il nostro portale sarà adibito.
Per poter creare il nostro portale web occorrerà avere a disposizione e quindi predisporre
tutto ciò che risulta essere indispensabile alla navigazione nel web: avremo bisogno,
quindi, di un web server, di un database e di un gestore dello stesso.
Per poter creare un web server sulla nostra macchina, avremmo bisogno innanzitutto di
Apache (il web server vero e proprio); poi bisognerebbe aggiungere altre applicazioni che
ci permettano di creare siti con contenuto dinamico, magari scritti in PHP (per esempio un
CMS open source), quindi occorrerebbe installare PHP e impostare Apache affinché
supporti questo linguaggio. Molto spesso, però, Apache e PHP da soli non bastano,
perché la gestione dei contenuti del sito rischia di diventare laboriosa col passare del
87
tempo: ed ecco che dovremmo ricorrere ad un database, solitamente MySQL, che

memorizzi i nostri dati e li restituisca quando servono ad Apache e PHP per visualizzarli
nella pagina web del nostro sito. Quindi dovremmo procedere anche con l’installazione di
un database configurandolo opportunamente. Magari ci farebbe comodo avere anche
qualche bella libreria grafica che ridimensioni ad hoc e visualizzi le nostre immagini:
potremmo pensare di installare anche questa. Bene, a questo punto avremmo un bel
server web, abbastanza minimale, ma funzionale. L’unico problema che potrebbe sorgere
è quello di correre il rischio di non riuscire a configurare tutto bene e con la dovuta
sicurezza. Per alleviare il problema si utilizza un pacchetto che contenga tutte queste
funzioni: XAMPP.
XAMPP
XAMPP (fino a poco tempo fa LAMPP) è un acronimo con cui si indica una piattaforma di
sviluppo web/database che prende il nome dalle iniziali dei componenti software con cui è
realizzata: è un insieme di programmi utili per la creazione di un web server ed integra, al
suo interno, Apache, MySQL, PHP, e tanti altri programmi che ci permettono di creare,
relativamente facilmente e velocemente, un server web, anche se minimale, che possa
contenere il nostro sito. La comodità sta nel fatto che invece di scaricare e installare
singolarmente tutti i programmi di cui abbiamo bisogno, con XAMPP basta scaricare un
file compresso di circa 40 MB e decomprimerlo sul nostro pc: se per qualche malaugurato
88
motivo, in futuro, non ci va più di avere quella cinquantina di MB del nostro hard disk
occupati da XAMPP, basta semplicemente cancellare la sua directory! Oltre a questo, la
comodità di XAMPP sta anche nel fatto che molte sue funzioni possono essere
intuitivamente configurate via web con un browser (alcune volte, però, è necessario
mettere mano al nostro editor di testi preferito e girovagare nei files di configurazione).
Il programma è rilasciato sotto la GNU General Public License ed è un utile web server,
gratuito e caratterizzato da un approccio user friendly: mediante XAMPP è possibile avere
un application server capace di interpretare pagine dinamiche PHP. Ottenendo un dominio
DNS, si può, se il computer è connesso, accedere alle pagine web. Attualmente, XAMPP
è disponibile per Windows, GNU/Linux, Sun Solaris e Mac OS X. Può essere installato
anche su un dispositivo esterno USB.
Esiste una versione “Lite” comprensiva dei componenti sotto indicati e una versione Basic
che comprende altre caratteristiche complementari. I componenti di base sono:
• Il Web server: Apache HTTP Server;
• Il database management system (o database server): MySQL e SQLite;
• Il server FTP: ProFTPD;
• Il Mail server: Mercury Mail Transport System (solo per Windows);
• I linguaggi di scripting: PHP e/o Python.
La versione che adopereremo è XAMPP 1.7.3 che contiene, in particolare, i seguenti
componenti:
• Apache 2.2.14 (IPv6 enabled) + OpenSSL 0.9.8l
• MySQL 5.1.41 + PBXT engine
• PHP 5.3.1
• phpMyAdmin 3.2.4
• FileZilla FTP Server 0.9.33
• Mercury Mail Transport System 4.721
1
Questo componente serve per inviare email inserendo qualsiasi tipo di contatto (msn,yahoo....).
89
WEB SERVER: APACHE 2.2.14
Apache è la piattaforma web server modulare più diffusa al mondo. Risulta in grado di
operare su sistemi operativi Unix-like e Windows. È un software che realizza le funzioni di
trasporto delle informazioni, di internet-working e di collegamento: ha il vantaggio di offrire
anche funzioni di controllo per la sicurezza come quelle che impiega il proxy.
Il Web Server Apache presenta un’architettura modulare, quindi, ad ogni richiesta del
client, vengono svolte funzioni specifiche da ogni modulo di cui è composto, come unità
indipendenti. Ciascun modulo si occupa di una funzionalità, ed il controllo è gestito dal
core.
In linea continua il flusso

dei dati reale.
Tratteggiato il flusso dei
dati astratto che forma la
pipeline.
I moduli che costituiscono la sua architettura (visibili dalla figura) sono i seguenti:
Core: programma principale composto da un ciclo sequenziale di chiamate ai
moduli
Translation: traduce la richiesta del client
Acces Control: controlla eventuali richieste dannose
90
MIME Type: verifica il tipo di contenuto

Response: invia la risposta al client e attiva eventuali procedure
Logging: tiene traccia di tutto ciò che è stato fatto
Il core suddivide la richiesta ai vari moduli in modo sequenziale, usando i parametri di
uscita di un modulo come parametri di accesso per l’altro, creando così l’illusione di una
comunicazione orizzontale fra i moduli (Pipeline software). Sopra il ciclo del core c’è un
ulteriore ciclo di polling svolto da un Demone che interroga continuamente le linee logiche
da cui possono pervenire messaggi di richiesta.
Per configurare Apache gli amministratori del server possono usare il file httpd.conf, che
su sistemi Unix solitamente è messo sotto /etc/httpd/conf, mentre su sistemi Windows è
situato nella subdirectory conf della directory di installazione di Apache. Questo file offre
tutta la libertà che fornisce il server, quindi aggiungere moduli, estensioni, nuovi mime-type
e altro ancora.
La versione che utilizzeremo per lo sviluppo sarà, per l’appunto, la 2.2.14.
Vediamo quali sono stati i motivi principali che ci hanno condotto alla scelta di Apache
come web server da utilizzare nello sviluppo del nostro portale:
o è open source, oltre che gratuito;
o è cross-platform (cioè funziona trasversalmente su molte piattaforme);
o è dotato di una knowledge di base molto vasta da utilizzare come supporto per gli
amministratori di sistema;
o è stabile e performante.
OpenSSL 0.9.8
OpenSSL è un’implementazione open source dei protocolli SSL e TLS. Le librerie di base
(scritte in linguaggio C) eseguono le funzioni crittografiche principali. Nei diversi linguaggi
di programmazione, sono disponibili procedure che permettono di accedere alle funzioni
della libreria OpenSSL. È disponibile per la maggior parte dei sistemi operativi unix-like,
91
inclusi GNU/Linux e Mac OS X, ed anche per Microsoft Windows. OpenSSL è

originariamente basato sulle librerie SSLeay di Eric Young e Tim Hudson.
OpenSSL supporta diversi algoritmi crittografici:
• Cifrari (Blowfish, Camellia, DES, RC2, RC4, RC5, IDEA, AES)

• Funzioni hash crittografate (MD5, MD2, SHA, MDC-2)
• Crittografia a chiave pubblica (RSA, DSA, Scambio di chiavi Diffie-Hellman)
OpenSSL utilizza una sistema dual-license (doppia licenza), la OpenSSL License e la

SSleay License. Normalmente in un sistema a doppia licenza è possibile scegliere quale
delle due licenze adottare; nel caso della OpenSSL occorre seguire entrambe. La licenza
risultante è simile a quella di Apache.
MySQL 5.1.41
MySQL è uno dei più diffusi Relational DataBase Management System (RDBMS),
composto da un client con interfaccia a caratteri e un server, entrambi disponibili sia per
sistemi Unix che per sistemi Windows. Esso supporta la maggior parte della sintassi
dell’SQL e possiede delle interfacce per diversi linguaggi, compreso un driver ODBC, due
driver Java e un driver per Mono e .NET. È importante sottolineare, inoltre, che MySQL
svolge il compito di DBMS principalmente nelle piattaforme LAMP [Linux – Apache –
MySQL – PHP] (le più usate ed installate su Internet per lo sviluppo di siti ed applicazioni
web dinamiche) ma anche in quelle WAMP (Windows – Apache – MySQL - PHP). Il
codice di MySQL è di proprietà dell’omonima società, viene però distribuito con la licenza
GNU GPL oltre che con una licenza commerciale.
92
Esistono diversi tipi di MySQL Manager, ovvero di strumenti per l’amministrazione di

MySQL. Uno dei programmi più popolari per amministrare i database MySQL è
phpMyAdmin: richiede un server web come Apache HTTP Server ed il supporto del
linguaggio PHP. Si può utilizzare facilmente tramite un qualsiasi browser.
La versione da noi scelta è la 5.1: venne rilasciata al pubblico, per la prima volta, il 29
novembre 2005 ed, attualmente, è la versione stabile. Le principali nuove caratteristiche
sono:
• il partizionamento delle tabelle
• un’API per scrivere nuovi parser2 per le ricerche FULLTEXT
• gli eventi
• replica basata sui dati (anziché sulle query)
• i log possono essere scritti in un database, oltre che nei file di testo
• supporto per Xpath3
• campi AUTOINCREMENT e varie ottimizzazioni per le tabelle ARCHIVE
• ClusterDB ora può scrivere i dati su disco, oltre che conservarli nella RAM;
supporta inoltre MontaVista
• ALTER TABLE, CREATE INDEX e DROP INDEX sono molto più performanti
In MySQL una tabella può essere di diversi tipi: ognuna di esse presenta proprietà e
caratteristiche differenti (transazionale o meno, migliori prestazioni, diverse strategie di
locking, funzioni particolari, ecc). Esiste poi un’API che si può utilizzare per creare in modo
relativamente facile un nuovo tipo di tabella, che poi si può installare senza dover
ricompilare o riavviare il server.
SQL (Structured Query Language) è un linguaggio di programmazione per database
progettato per leggere, modificare e gestire dati memorizzati in un sistema basato sul
modello relazionale, per creare e modificare schemi di database, per creare e gestire
2
Parser: è un analizzatore sintattico, un algoritmo di riconoscimento sintattico di un linguaggio. Il parser,
componente del compilatore, esegue l’analisi sintattica del flusso di token (ad esempio if, then, else, −, +, *,
/, variabili) ottenuti dall’analizzatore lessicale. Il parser prende ciascun token e gli assegna un significato,
verifica la coerenza delle istruzioni del programma con la sintassi del linguaggio sorgente, ovvero trova una
regola della grammatica del linguaggio che giustifichi la presenza e la posizione del token; se riscontra
incongruenze il parser genera messaggi di errore o avvertimenti.
3
XPath: è un linguaggio parte della famiglia XML che permette di individuare i nodi all’interno di un
documento XML. Le espressioni XPath, a differenza delle espressioni XML, non servono a identificare la
struttura di un documento, bensì a localizzarne con precisione i nodi.
93
strumenti di controllo ed accesso ai dati: è il più popolare linguaggio di interrogazione sui

database al mondo.
Perché lo abbiamo scelto:
• si tratta di software libero, che garantisce di un’elevata qualità a fronte di costi
irrisori (in questo caso nulli);
• è veloce;
• è stabile;
• è multi-user;
• è multi-thread;
• è semplice da utilizzare;
• è cross-platform.
GDO COME “SISTEMA TRANSAZIONALE”: GESTIONE DI TRANSAZIONI

CONCORRENTI
Esistono numerose applicazioni in cui le informazioni contenute in un database sono

elaborate da più programmi o più esecuzioni dello stesso programma: il nostro sistema
software, infatti, dovrà essere in grado di gestire situazioni in cui più utenti (che in
definitiva rappresentano più processi client) tentano di interagire contemporaneamente
con il nostro portale allo scopo di effettuare delle transazioni.
Un esempio è il caso in cui, in uno stesso momento, più punti vendita accedono al portale
web per effettuare un ordine. La creazione del nuovo ordine genera delle modifiche, ad
esempio, alla tabella degli ordini e a quella dei prodotti, a causa del fatto che a seguito
della conferma di avvenuto ordine, notificata a tutti i punti vendita contendenti, saranno
variate le quantità disponibili dei vari prodotti interessati.
Considerando questo scenario (che rappresenta una situazione altamente probabile per il
nostro sistema), se non si disciplina correttamente l’accesso ai dati si rischia di ottenere
effetti indesiderati. Ad esempio vendere uno stesso prodotto, che consideriamo sia
disponibile in un unico pezzo, a due punti vendita diversi. Quando entrambi accedono al
portale e creano il carrello per poi procedere all’ordine, vedono che quel prodotto è
disponibile e quindi sono abilitati a procedere con l’ordine. Tuttavia, in realtà solo uno dei
due utenti potrà effettivamente ricevere il prodotto ordinato, mentre l’altro avrà un
riferimento dangling a un prodotto la cui disponibilità effettiva è nulla. Dovremo quindi
94
cercare di evitare che si presenti una situazione di questo tipo, che causerebbe gravi errori
nella quantificazione dell’importo degli ordini nonché insoddisfazione nel cliente (potrebbe
rischiare di non ricevere tutto quello che ha ordinato).
Tenendo presente che una transazione è un’unità elementare di lavoro di un’applicazione
a cui si vogliono associare particolari caratteristiche di correttezza, robustezza ed
isolamento, possiamo dire che un sistema che mette a disposizione meccanismi per la
definizione e l’esecuzione di transazioni viene detto sistema transazionale.
Il nostro sistema software è un sistema transazionale in cui la creazione e cancellazione
degli ordini rappresenta un esempio di transazioni.
Per mantenere le informazioni consistenti è necessario controllare opportunamente le
sequenze di accessi e aggiornamenti ai dati, tenendo presente che gli utenti interagiscono
con la base di dati attraverso programmi applicativi i quali usano le transazioni per
garantire la correttezza del dato inserito o letto. Una transazione si può interpretare, in
pratica, come un insieme parzialmente ordinato di operazioni di lettura e scrittura; essa
costituisce l’effetto dell’esecuzione di programmi che effettuano le funzioni desiderate dagli
utenti.
Ogni transazione può essere eseguita completamente (commit), oppure per nulla (abort)
se si verifica un qualche errore (hardware o software) durante l’esecuzione:
• Dobbiamo garantire che le transazioni eseguite in concorrenza si comportino come
se fossero state eseguite in sequenza (controllo della concorrenza)
• Sono necessarie tecniche per ripristinare uno stato corrente della base di dati a
fronte di malfunzionamenti di sistema (tecniche di ripristino - recovery)
Ora, considerando il fatto che l’insieme delle operazioni che costituiscono una transazione
deve soddisfare alcune proprietà, note come proprietà ACID, dobbiamo assicurarci che
anche il nostro sistema di gestione del DB conservi e garantisca tali proprietà. Queste
garantiscono un funzionamento privo di sorprese, ribadiscono il principio del “tutto o
niente” per le operazioni che costituiscono le transazioni e fanno delle transazioni stesse
uno strumento insostituibile per la riduzione del carico gestionale in presenza di numerose
variabili. Ecco una sintetica descrizione di ciascuna delle 4 proprietà che costituiscono
l’acronimo ACID:
ATOMICITÀ
Una transazione rappresenta un’unità di lavoro in cui una serie di operazioni viene
eseguita tra le istruzioni BEGIN TRANSACTION ed END TRANSACTION di
95
un’applicazione. Le transazioni vengono eseguite un’unica volta e sono atomiche, ovvero

vengono completate o annullate interamente. Le operazioni associate a una transazione
presentano in genere un intento comune e sono interdipendenti. Se venisse eseguita solo
una parte di queste operazioni, potrebbe risultare compromesso l’intento stesso della
transazione. L’atomicità elimina la possibilità di elaborazione di una parte soltanto delle
operazioni.
COERENZA
Una transazione rappresenta un’unità di integrità perché preserva l’uniformità dei dati,
trasformando uno stato coerente di dati in un altro stato coerente di dati. Per la coerenza è
necessario che i dati collegati da una transazione vengano preservati dal punto di vista
semantico. La responsabilità del mantenimento della coerenza è in parte dello
sviluppatore dell’applicazione, che si assicura che in essa siano rispettati tutti i vincoli di
integrità noti. Nello sviluppo di un’applicazione per il trasferimento di denaro, ad esempio,
è fondamentale evitare che la virgola decimale venga spostata arbitrariamente durante il
trasferimento.
ISOLAMENTO
Una transazione rappresenta un’unità di isolamento, in quanto consente che le transazioni
simultanee abbiano luogo come se ciascuna di esse fosse l’unica transazione in
esecuzione nel sistema. Per l’isolamento è necessario che ciascuna transazione sembri
essere l’unica a manipolare l’archivio dati, anche se è possibile che altre transazioni siano
in esecuzione nello stesso momento. È importante che una transazione non capti mai le
fasi intermedie di un’altra transazione. Le transazioni raggiungono il più alto livello di
isolamento quando sono serializzabili. A questo livello, i risultati ottenuti con una serie di
transazioni contemporanee sono identici a quelli ottenuti eseguendo ciascuna transazione
in serie. Dal momento che un alto grado di isolamento può limitare il numero delle
transazioni contemporanee, alcune applicazioni riducono il livello di isolamento allo scopo
di migliorare le prestazioni.
DUREVOLEZZA (PERSISTENZA)
Una transazione rappresenta inoltre un’unità di recupero. Se una transazione ha esito
positivo, il sistema garantisce che gli aggiornamenti da essa effettuati persistano, anche
se il computer si blocca immediatamente dopo il commit. L’accesso specializzato consente
96
alla procedura di riavvio del sistema di completare eventuali operazioni non terminate,
rendendo la transazione durevole.
Atomicità e Persistenza sono garantiti dal controllo dell’affidabilità (sottosistema di

ripristino o Recovery System), mentre l’isolamento è garantito dal controllo di concorrenza.
La consistenza è invece gestita dai compilatori DDL (Data definition Language) che
introducono le opportune verifiche sui dati.
Le proprietà ACID vengono assicurate utilizzando due insiemi distinti di algoritmi o
protocolli, che assicurano:
• l’atomicità dell’esecuzione, nel senso che devono mantenere la consistenza globale
della base di dati e quindi assicurare la proprietà di consistenza delle transazioni
(anche concorrenti); in questo caso risulta necessario l’uso di protocolli di controllo
della concorrenza;
• l’atomicità del fallimento, che assicura l’atomicità, l’isolamento e la persistenza; in
questo caso risulta necessario l’uso di protocolli di ripristino.
Descriviamo, nella maniera più sintetica possibile, cosa si intende per controllo di
concorrenza: lo scopo del gioco è, da un lato, garantire l’integrità della base di dati in
presenza di accessi concorrenti da parte di più utenti (come ad esempio lo scenario
descritto in precedenza), mentre dall’altro vi è la necessità di sincronizzare le transazioni
eseguite in concorrenza.
Alcune tecniche che consentono di effettuare un controllo sulla gestione dei conflitti sono il
locking, il locking a due fasi (generale), locking a due fasi stretto, scheduler serializzabile,
e altre ancora.
97
phpMyAdmin 3.2.4
PhpMyAdmin è uno dei più popolari MySQL manager, cioè un programma per
amministrare i database MySQL attraverso un’interfaccia grafica. È facilmente utilizzabile
tramite un qualsiasi browser. È scritto in PHP, è distribuito con la licenza GNU GPL ed è
disponibile in diverse lingue.
Consente agli amministratori di effettuare agevolmente diverse operazioni sui database:
• navigare nei database e nelle tabelle;
• effettuare le operazioni di create, copy, rename, alter e drop sui database;
• effettuare le operazioni di create, copy, rename, alter e drop sulle tabelle;
• effettuare la manutenzione sulle tabelle;
• effettuare le operazioni di add, edit e drop dei campi;
• eseguire qualsiasi statement SQL, anche query multiple;
• caricare file di testo nelle tabelle;
• creare e leggere i dump delle tabelle o dei database;
• esportare i dati nei formati SQL, CSV, XML, Word, Excel, PDF e LaTeX;
• amministrare server multipli;
• gestire gli utenti MySQL e i privilegi;
• creare query complesse usando Query – by – example (QBE), connettendo
automaticamente le tabelle richieste;
• creare grafici PDF del layout del database;
• effettuare ricerche in tutto il database o in parte di esso;
• trasformare i dati immagazzinati in qualsiasi altro formato utilizzando un set di
funzioni predefinite.
Perché lo abbiamo scelto:
• si tratta di software libero, che garantisce un’elevata qualità a fronte di costi irrisori
(in questo caso nulli);
98
• permette di effettuare una moltitudine di operazioni in modo semplice ed intuitivo;

FileZilla FTP Server 0.9.33
FileZilla Server è un server FTP molto piccolo nelle dimensioni ma veloce e performante
nelle applicazioni a cui è adibito. È un server gratuito, scaricabile liberamente dal web, che
consente di ricevere tutte le funzionalità necessarie al suo corretto funzionamento, in linea
con le applicazioni richieste, in una maniera che risulta essere la più semplice possibile. In
più possiamo affermare che è molto facile da usare, nonché molto intuitivo.
Il suo punto di forza è il demone di gestione del server esterno al server stesso: così è
possibile gestire il server da qualunque postazione. Altro punto a favore è l’immediata e
potente gestione dei profili utente. Consente il resume dei file interrotti, connessioni
multiple a porte multiple e supporta FTP e FTP con crittografia SSL/TLS. Permette infine
di generare statistiche sull’uso del server stesso.
99
PHP 5.3.1
PHP (Hypertext Preprocessor) come dice l’acronimo è un preprocessore di ipertesti. Più

precisamente esso è un linguaggio di scripting interpretato, con licenza open source e
libera, originariamente concepito per la realizzazione di pagine web dinamiche.
Attualmente è utilizzato principalmente per sviluppare applicazioni web lato server ma può
essere usato anche per scrivere script a linea di comando o applicazioni stand-alone con
interfaccia grafica. PHP riprende per molti versi la sintassi del C, come peraltro fanno molti
linguaggi moderni, e del Perl: è un linguaggio a tipizzazione debole e dalla versione 5
migliora il supporto al paradigma di programmazione ad oggetti. Certi costrutti derivati dal
C, come gli operatori fra bit e la gestione di stringhe come array, permettono in alcuni casi
di agire a basso livello; tuttavia è fondamentalmente un linguaggio di alto livello,
caratteristica questa rafforzata dall’esistenza delle sue moltissime API, oltre 3000 funzioni
del nucleo base. PHP è in grado di interfacciarsi a innumerevoli database tra cui MySQL e
Oracle, solo per citarne alcuni, e supporta numerose tecnologie, come XML, IMAP, FTP.
Si integra anche con altri linguaggi/piattaforme quali Java e .NET. Da tutti questi linguaggi
di programmazione eredita molte delle funzionalità che lo hanno reso uno dei più versatili,
veloci e completi linguaggi di programmazione server-side attualmente disponibili.
PHP fornisce un’API specifica per interagire con Apache, nonostante funzioni
naturalmente con numerosi server web. È anche ottimamente integrato con il database
MySQL, per il quale possiede più di una API: per questo motivo esiste un’enorme quantità
di script e librerie in PHP, disponibili liberamente su Internet. La versione 5, comunque,
integra al suo interno un piccolo database embedded, SQLite.
Dispone di un archivio chiamato PEAR che mette a disposizione un framework di librerie
riusabili per lo sviluppo di applicazioni PHP e di PECL che raccoglie tutte le estensioni
conosciute scritte in C.
Noi useremo la versione 5.3.1 che ci permette di utilizzare al meglio le sue funzionalità
legate all’applicazione web che intendiamo sviluppare.
100
Perché lo abbiamo scelto :

• è Open Source, presenta un’elevata qualità e costi nulli;
• è affidabile: le sue radici affondano nella storia degli elaboratori;
• è orientato ai database: possiede al suo interno tutte le funzionalità per gestire le
informazioni estrapolate dai database;
CodeIgniter
Una volta stabilito il linguaggio di programmazione, bisogna procedere con la scelta di un

framework di sviluppo che sia efficiente ed efficace: tra i tanti a disposizione abbiamo
deciso di utilizzare Codeigniter.
CodeIgniter è un potente Application Framework per PHP, cioè una piattaforma grazie
alla quale sarà possibile realizzare applicazioni in linguaggio PHP in modo semplice e
veloce grazie a classi e metodi già disponibili. Il vantaggio del suo utilizzo è indubbio:
invece di scrivere da zero ogni riga di codice necessaria per effettuare procedure anche
complesse, basterà fare riferimento ai costrutti messi a disposizione dal framework.
CodeIgniter utilizza l’approccio MVC (Model-View-Controller) che consente un ampio
livello di separazione tra la logica dell’applicazione e la presentazione della stessa.
L’utilizzo dell’MVC si riflette positivamente soprattutto nei progetti in cui è necessario che il
lavoro dei webdesigner non condizioni quello degli sviluppatori e viceversa.
L’approccio MVC è strutturato sulla base dei tre elementi fondamentali che ne
compongono il nome:
- Model: mette a disposizione i metodi con cui accedere ai dati necessari per il
funzionamento dell’applicazione;
101
- View: ha il compito di visualizzare i dati forniti dal model e permette l’interazione tra
utilizzatori e applicazione;
- Controller: ad esso vengono inviate le istruzioni provenienti dall’utenza
(generalmente mediati dalla view) e le esegue condizionando lo stato dei due
componenti presentati in precedenza.
Questa tipologia di approccio consente di isolare anche a livello pratico la logica
applicativa di un programma ponendola a carico del Controller e del Model, mentre la
parte relativa all’interfaccia utente sarà assegnata alla View.
I principali vantaggi di utilizzare un framework come CodeIgniter risiedono nell’estrema
facilità di utilizzo di questo strumento:
- è di dimensioni relativamente ridotte e non costringe lo sviluppatore a lavorare con
librerie monolitiche ed eccessive quantità di file;
- garantisce prestazioni molto elevate anche in ragione di quanto esposto nel punto
precedente;
- è compatibile con numerose versioni di PHP; a differenza di altri framework può
infatti essere utilizzato anche in ambienti hosting che non supportano ancora la
versione 5 di PHP;
- richiede una procedura di configurazione e installazione non più lunga di alcuni
minuti e, cosa invece necessaria per altre piattaforme dello stesso tipo, per il suo
utilizzo non ha bisogno dell’invio di istruzioni da linea di comando;
- non impone stili codificati per la scrittura del codice, prevede istruzioni semplici
molto simili nella sintassi a quelli comunemente utilizzati per la chiamata a funzioni
PHP;
- evita la necessità di dover utilizzare librerie esterne per l’integrazione di funzioni
addizionali come per esempio PEAR;
- non richiede di imparare un apposito linguaggio per la gestione dei template né
l’utilizzo di un template engine esterno al framework;
- è corredato da una documentazione molto completa e semplice da consultare.
Da sottolineare, infine, l’estrema velocità di questo framework che offre ottime prestazioni
sia in sede di sviluppo che in sede di produzione.
102
ARCHITETTURA SOFTWARE
Dopo aver fornito una panoramica sui programmi che utilizzeremo nella realizzazione del
nostro software, risulta di estrema importanza porre l’accento sulle scelte progettuali per
quanto concerne l’architettura del sistema, allo scopo, da un lato, di fornire una visione
d’insieme sulle caratteristiche proprie dell’architettura scelta, e dall’altro di mostrare ed
evidenziare i pregi che ci hanno condotto alla sua scelta.
La scelta da noi ritenuta migliore riguardo l’architettura software da utilizzare nella
realizzazione del nostro portale web, dopo un’attenta analisi e una serie di considerazioni,
è ricaduta sull’architettura client-server: è un tipo di architettura che ben si adatta a
sistemi distribuiti4, anche se può comunque essere utilizzata per progettare sistemi stand-
alone.
ARCHITETTURA CLIENT-SERVER
Il termine “client-server” si riferisce normalmente all’architettura di una applicazione

software (un “programma”, in termini semplici) che è in effetti divisa in due parti ben
distinte, anzi in due programmi, fra loro indipendenti: un programma “server”, quello che
fornisce il servizio richiesto, ed un programma “client”, ovvero quello utilizzabile per
accedere al servizio. In pratica il server fornisce servizi che attraverso il client saranno
fruibili dall’utente.
Un’organizzazione di tipo client-server struttura un sistema considerandolo come
costituito da:
• un insieme di servizi (ciascuno caratterizzato da un’interfaccia, che definisce il
protocollo e il formato dei messaggi scambiati, oltre che il meccanismo di
connessione tramite protocolli e porte);
• un insieme server (dove ogni server è un processo erogatore di servizi);
• un insieme client (dove ogni client è un processo fruitore di servizi).
4
Dove per sistema distribuito si intende un sistema in cui l’elaborazione dell’informazione è distribuita su
diversi computer. Questo tipo di organizzazione presenta evidenti vantaggi quali la condivisione delle
risorse, la scalabilità, l’apertura, la fault tolerance e la simultaneità, anche se di contro abbiamo la maggiore
complessità, la maggiore difficoltà riguardante la messa in sicurezza del sistema, la non prevedibilità e
quindi una gestione molto più difficoltosa.
103
In definitiva, un’applicazione client-server è un tipo di applicazione di rete nel quale un

computer client istanzia l’interfaccia utente di un’applicazione connettendosi ad una server
application o ad un sistema di database.
Più semplicemente, i sistemi client-server sono un’evoluzione dei sistemi basati sulla
condivisione semplice delle risorse. La presenza di un server permette ad un certo numero
di client di condividerne le risorse, lasciando che sia il server a gestire gli accessi alle
risorse per evitare conflitti nell’uso delle stesse.
Il software client in genere è di complessità contenuta, limitandosi normalmente ad
operare come interfaccia verso il server. In generale nel campo informatico il termine client
indica una componente che accede ai servizi o alle risorse di un’altra componente, il
server appunto. Si può quindi parlare di client riferendosi all’hardware o al software: un
computer collegato ad un server tramite rete locale o geografica, al quale richiede uno o
più servizi, utilizzando uno o più protocolli di rete è un esempio di client hardware; mentre
un programma di posta elettronica è un esempio di client software.
Inoltre possiamo considerare il fatto che sono sempre di più i software, come il web, l’e-
mail, i database, che sono divisi in una parte che costituisce il client (residente ed in
esecuzione sul pc client) ed una parte che individua il server (residente ed in esecuzione
sul server che può essere dislocato in qualunque parte della rete e non necessariamente
su di un unico pc).
Da notare, inoltre, che il termine client indica anche il software usato sul computer client
per accedere alle funzionalità offerte dal server: Ad esempio, nel web il software client è il
browser, e comunica con un web server attraverso il protocollo HTTP; per l’e-mail il client
è detto in gergo user agent o “MUA” (ad esempio Outlook, Mozilla, etc), e si scambia
messaggi con il server attraverso i protocolli SMTP e POP o IMAP; il client per la
consultazione o la modifica di database (spesso costituiti da librerie software utilizzate da
una applicazione) comunica con il DBMS, che gestisce il database, e risponde alle
interrogazioni del client.
Il software server, oltre alla gestione logica del sistema, deve implementare tutte le
tecniche di gestione degli accessi, allocazione e rilascio delle risorse, condivisione e
sicurezza dei dati o delle risorse.
Abbiamo diverse tipologie di architettura client-server: a due livelli (thin client vs fat client),
a tre livelli oppure multi-livello.
Quando un computer client si connette direttamente ad un sistema di database o a una
server application standard, questo tipo di organizzazione viene chiamato 2-tier
104
architecture (architettura a 2 livelli): il cliente richiede una risorsa e il server gliela fornisce
direttamente, utilizzando le proprio risorse e questo significa che il server non fa appello
ad un’altra applicazione per fornire il servizio richiesto.
In particolare, per quanto riguarda l’architettura thin client tutte le elaborazioni applicative
e la gestione dei dati sono prerogativa del server, mentre al client viene lasciata solo la
gestione del livello di presentazione dei servizi disponibili: in pratica fornisce
semplicemente una interfaccia utente. Quest’ultima, infatti, viene migrata verso PC,
mentre l’applicazione funge da server e gestisce tutte le elaborazioni e le gestioni dei dati.
Gli svantaggi sono legati al fatto di avere un pesante carico di lavoro sul server e sulla
rete, senza considerare il fatto che la potenza computazionale ed elaborativa dei client
viene completamente sprecata.
Invece, per quanto riguarda l’architettura fat client il client si occupa sia del livello di
presentazione dell’applicazione, sia dell’elaborazione della logica applicativa. Di contro,
questa volta, il server è un server di transazione che gestisce le transazioni col database.
Gli svantaggi sono legati al fatto di avere una maggiore complessità nella gestione del
sistema visto che le funzionalità dell’applicazione sono divise su diversi computer, i costi
sono maggiori ed ancora, elemento non trascurabile, quando il software viene modificato,
è necessario installare nuovamente il client su ogni computer.
A questo punto possiamo anche dire quali sono i problemi di un’architettura a due livelli: gli
strati logici sono mappati su due soli sistemi e questo porta a problemi di scalabilità e
prestazioni (nel thin client) e problemi di gestione del sistema (nel fat client).
Allo scopo di far fronte a tali problemi in maniera più efficiente si è introdotto un ulteriore
tipo di architettura client-server 3-tier-architetture: qui esiste un livello in più, intermedio.
Tutto ciò comporta l’ottenimento di un’architettura condivisa tra:
105
• un client, dotato di un’interfaccia utente (è la parte preposta alla presentazione);

• il server d’applicazione (detto anche middleware), incaricato di fornire la risorsa
ma facendo riferimento ad un altro server;
• il server di dati, che fornisce al server dell’applicazione i dati di cui ha bisogno.
In questo tipo di architettura, in pratica, la presentazione, l’elaborazione applicativa e la
gestione dei dati sono processi logicamente separati ed eseguiti su processori diversi.
Mentre l’architettura a due livelli è un’architettura client-server nella quale il server è

polivalente, cioè è capace di fornire direttamente l’insieme delle risorse richieste dal client,
nell’architettura a 3 livelli, invece, le funzionalità a livello del server sono de-localizzate, il
che significa che ogni server è specializzato in un compito (server web, server database
ad esempio). L’architettura a tre livelli permette:
• una più grande flessibilità;
• una maggiore sicurezza dato che questa può essere definita in maniera
indipendente per ogni servizio e ad ogni livello;
• delle performance migliori, dato che condivide dei compiti tra i differenti server.
Ora possiamo fare un’ulteriore considerazione e dire che l’architettura a 3 livelli altro non è
se non un’architettura multi livello (N-livello) con N=3.
106
In generale architetture ad N-livelli possono impiegare un certo numero di servizi distinti,

comprese relazioni transitive tra application server che implementano differenti funzioni
ognuna delle quali può impiegare o meno un sistema di database condiviso o distinto.
Ricapitolando abbiamo visto che il client sicuramente è caratterizzato da una “interfaccia di
utente” che accetta le richieste di un utilizzatore umano, ne verifica la correttezza e
compone un “messaggio” di richiesta al server. Quest’ultimo risponde appropriatamente. A
questo punto il “client” può convertire il messaggio di risposta in una forma più adatta ad
essere compresa dall’utilizzatore e presentarlo.
Nella figura sotto riportata abbiamo un esempio chiaro in cui un tipo di architettura client
server può essere utilizzata: abbiamo un client (il web browser) che fa una richiesta al
server allo scopo di ottenere una mappa. Il server a cui è indirizzata la richiesta è
direttamente connesso a sua volta ad un DBMS (che potrebbe essere gestito
autonomamente da un altro server, come previsto dall’architettura 3-tier). Se questo server
non riesce ad ottenere le risorse richieste dal client si adopera in maniera tale da
effettuare una richiesta a remoto e procurarsi così la risorsa con cui costruire il messaggio
di risposta al client stesso, assemblando eventualmente tutto quanto raccolto.
L’architettura client server, quindi, ben si adatta a situazioni di questo tipo in cui bisogna
essere in grado di soddisfare le richieste del client “appoggiandosi” su una rete di
collaborazione tra server dislocati nel web allo scopo di fornire al server di livello 2 (che si
occupa della comunicazione diretta col client) tutte le informazioni necessarie alla
ricostruzione dell’intera risorsa richiesta dal client.
107
Nella figura qui accanto abbiamo

riportato il diagramma UML degli stati
che rappresenta come il nostro sistema
software, allocato sul server, a seguito
dell’avvio, si ponga nello stato di attesa
aspettando che il client vi acceda per
effettuare richieste. Resta nello stato
finché non riceve una richiesta, quindi
passa nello stato “invoca servizio” a
seguito della richiesta di esecuzione per
poi tornare in attesa di altre richieste.
108
DIAGRAMMA DI DEPLOYMENT (DISPIEGAMENTO)
Il Deployment Diagram ("diagramma di dispiegamento") è un diagramma di tipo statico

previsto dal linguaggio di modellazione object-oriented UML per descrivere un sistema in
termini di risorse hardware dette nodi, e di relazioni fra di esse. Spesso si utilizza un
diagramma che mostra come le componenti software sono distribuite rispetto alle risorse
hardware disponibili sul sistema. In un diagramma di deployment si possono disporre
anche i singoli componenti, così da mettere in evidenza la loro collocazione nei vari
elaboratori.
Il nodo è rappresentato tramite un cubo ed un nome, e raffigura una risorsa hardware
disponibile al sistema. Per esempio in un sistema client-server a due livelli, i nodi
potrebbero rappresentare il server e il client, oppure un pc potrebbe essere scomposto in
unità centrale, video, tastiera e stampante, rappresentando ciascuna risorsa hardware in
un nodo del sistema.
In pratica descrive i nodi che formano la topologia hardware del sistema. Tipicamente ogni
nodo ospita uno o più componenti.
109
Il diagramma che descrive il nostro progetto è il seguente:
110
PATTERN ARCHITETTURALE
I pattern architetturali esprimono schemi di base per impostare l’organizzazione strutturale

di un sistema software: in questi schemi si descrivono dei sottosistemi predefiniti insieme
con i ruoli che assumono e le reciproche relazioni tra di essi. Possiamo affermare, quindi,
che, in genere, individuano le parti del sistema a cui sono associate responsabilità
omogenee e le relazioni che esistono tra i diversi sottosistemi. Ogni pattern descrive un
problema che si ripete più e più volte: descrive, quindi, il nocciolo della soluzione del
problema, in modo tale che la soluzione possa essere usata un milione di volte, senza che
venga mai applicata nella stessa maniera. Nel caso della progettazione del software,
questo significa individuare meccanismi e tecniche che permettano di risolvere
problematiche ricorrenti in modo elegante, riusabile ed efficace.
Esistono diverse tipologie di pattern architetturali, ma per la realizzazione del nostro
sistema software abbiamo deciso di utilizzare un pattern pensato per interactive
systems, che sono sistemi in cui è previsto che vi sia una certa interazione uomo-
macchina (come il nostro portale che dovrà consentire una serrata interazione tra i vari
utenti che vi accedono e il sistema stesso). Tale pattern ci aiuterà nella progettazione di un
sistema pensato per gestire questo tipo di interazione. Abbiamo scelto il pattern MVC
(MODEL VIEW CONTROLLER).
MODEL-VIEW-CONTROLLER
MODEL-VIEW-CONTROLLER (MVC) è un pattern architetturale molto diffuso nello

sviluppo di sistemi software object-oriented. Il pattern è stato esplicitamente o
implicitamente sposato da numerose tecnologie, quali i framework basati su PHP, su Java
o su .NET. A causa della crescente diffusione di tecnologie basate su MVC nel contesto di
framework o piattaforma middleware per applicazioni Web, l’espressione framework MVC
o sistema MVC sta entrando nell’uso comune anche per indicare specificamente questa
categoria di sistemi.
Il pattern è basato sulla possibilità di dividere un’applicazione software in tre componenti
distinti tra loro, idealmente indipendenti gli uni dagli altri, ma in stretta collaborazione tra
loro. Queste tre componenti si occupano ognuna di un compito diverso in modo da
dividere il controllo dell’applicazione, dalla struttura dati e dalla visualizzazione.
111
Vediamo nel dettaglio le tre componenti:
• Il model incapsula funzionalità e dati che sono indipendenti dalla specifica

rappresentazione dell’output o dal comportamento di input. Fornisce, cioè, i metodi
necessari per accedere ai dati utili all’applicazione, li gestisce e si occupa, in più,
dell’interazione e dell’estrazione dei dati dal database. Infatti, solitamente la
progettazione del modello è guidata sostanzialmente dalla struttura del database e
quindi, in pratica, dalle modalità di accesso ad esso;
• Le view si incaricano di visualizzare i dati o una porzione di essi, forniti dal
controllore attraverso un opportuno modello, in base ad una specifica formattazione
rappresentante un certo contesto applicativo, che potrá essere un lista di record, un
form per l’inserimento e la modifica, un grafico, o qualsiasi tipo di rappresentazione
si voglia dare a questi dati. Le view si occupano, in pratica, di mostrare le
informazioni all’utente: ottengono i dati dal Controller e ne consentono la
visualizzazione (possono esserci più View di uno stesso Model);
• Il controller è il “motore” dell’applicazione: riceve i comandi dall’utente,
generalmente attraverso la vista utilizzando i propri metodi, e li utilizza per
richiamare in modo adeguato gli altri due componenti, permettendo quindi al
modello di estrarre i dati, che vengono passati per la visualizzazione alle opportune
viste. In pratica il controllore si occupa di gestire l’input utente e la comunicazione
Model-View. I componenti Controller ricevono l’input che di solito codifica un evento
come il movimento del mouse o un input da tastiera. Gli eventi sono poi tradotti in
service request per il Model: riceve i comandi dell’utente (in genere attraverso le
view) e li attua modificando lo stato degli altri due componenti.
Nell’immagine seguente abbiamo in più il browser che rappresenta l’utente che interagisce
con l’applicazione e invia i dati al controller.
112
Questo schema, fra l’altro, implica anche la tradizionale separazione fra la logica
applicativa a carico di controller e model, e l’interfaccia utente a carico della view.
Un aspetto molto importante è la consistenza del modello: questa proprietà è garantita da
un meccanismo di propagazione dei cambiamenti, nel senso che quando un modello
cambia il suo stato, notifica tutte le sue viste ed i suoi controller del cambiamento in
maniera tale che questi possano aggiornare il loro stato in modo appropriato.
Nella figura seguente sintetizziamo tutte le funzionalità e i compiti di ogni singolo
componente:
113
Questa strutturazione del progetto, se applicata nelle giuste situazioni, ovvero ad

applicazioni medio-grosse, nonostante un lavoro progettuale più impegnativo apporta
enormi vantaggi come:
• facilitare il riutilizzo del codice: infatti più una parte del lavoro è indipendente dal
resto, più possibilità ci sono che possa essere utile per altre applicazioni;
• suddividere il lavoro nel caso debbano lavorare più persone o team;
• utilizzando un modello rigido e regole standard si facilita un eventuale lavoro di
manutenzione e agevola la comprensione anche da parte di altri programmatori;
• nel caso si cambi tipo di database sarà possibile adattare l’applicazione senza
dover mettere mano a tutto il codice ma solo al modello, quindi maggiore
flessibilità.
Tutto questo ci può essere molto di aiuto nello sviluppo, in particolare, di applicazioni web
e per capire come si possa implementare tutto ciò ci vengono in aiuto i frameworks5.
Bisogna dire però che vi sono anche alcuni svantaggi che comunque non ci hanno
impedito di sceglierlo come pattern architetturale di riferimento per il nostro progetto quali:
- è adatto alla progettazione di sistemi di medio-grandi dimensioni;
- è un’architettura sostanzialmente complessa;
- la flessibilità è comunque strettamente legata al framework utilizzato.
I dettagli delle interazioni fra questi tre oggetti software dipendono molto dalle tecnologie
usate (linguaggio di programmazione, eventuali librerie, middleware e via dicendo) e dal
tipo di applicazione (per esempio se si tratta di un’applicazione web, o di un’applicazione
desktop). Quasi sempre la relazione fra view e model è descrivibile anche come istanza
del pattern Observer. A volte, quando è necessario cambiare il comportamento standard
dell’applicazione a seconda delle circostanze, il controller implementa anche il pattern
Strategy (da notare che Observer e Strategy sono due Design Pattern Comportamentali).
A differenza di altri framework più conosciuti e utilizzati, CodeIgniter gestisce il paradigma
MVC in modo molto più semplice: esso si basa su una struttura per classi di tipo
Singleton (design pattern creazionale, il cui scopo è quello di assicurare che per una
classe esista una sola istanza e fornire, nello stesso tempo, un unico punto di accesso
5
Un framework è una struttura di supporto allo sviluppo di un software. In particolare, nel caso di
applicazioni web si tratta di codice sorgente già scritto che ci offre alcuni strumenti per sviluppare e
supportare l’applicazione vera e propria.
Esistono framework per vari linguaggi tra cui i frameworks MVC (quindi basati sul pattern Model-View-
Controller) sviluppati principalmente in PHP (come lo stesso CodeIgniter).
114
globale all’istanza stessa) in cui l’oggetto principale permette di caricare tutte le librerie ed
i modelli richiesti per lo sviluppo di una applicazione.
DESIGN PATTERN
Sono i pattern che si riferiscono alle problematiche legate al paradigma object-oriented.

Essi, da una parte, forniscono uno schema per raffinare gli elementi di un sistema
software o le relazioni tra di essi, dall’altra, descrivono una struttura di elementi di progetto
interconnessi, che ricorrono comunemente, utilizzati per risolvere un problema di
progettazione generale in un contesto particolare. I pattern non descrivono mai soluzioni
valide per una specifica piattaforma, ma hanno una validità generale e trasversale rispetto
alla tecnologia.
I design pattern vengono utilizzati proprio perché consentono di progettare il nostro
software in maniera tale che possano essere garante caratteristiche molto importanti. Una
di queste è il riuso che consiste nel riutilizzare soluzioni e conoscenze già pronte: i
progettisti nel corso delle loro attività usano soluzioni progettuali simili tra loro ed, inoltre, è
fondamentale l’esperienza dello sviluppatore. Un altro aspetto molto importante per cui i
pattern vengono utilizzati è legato al fatto che le innovazioni tecniche possono essere
diffuse con successo e in maniera più semplice e veloce: si possono integrare anche
nuove tecniche senza eccessivi rischi (integrazione). I pattern costituiscono un ottimo
modo di diffondere la documentazione di progetto. Tuttavia bisogna tener conto anche
del fatto che spesso è difficile realizzare una comunicazione tecnica chiara e
comprensibile e i pattern possono rimediare a questo problema (comunicazione).
Ora, un problema ricorrente nella programmazione OOP è definire la giusta struttura di
classi per la soluzione di un problema e i pattern si inseriscono in questo contesto: ne
esistono molti che descrivono le strutture basilari di una classe o parti di esse che è
possibile estendere e adattare più facilmente.
I design pattern si caratterizzano per granularità e per livello d’astrazione, ma vengono
classificati considerando lo scopo (cosa fa) e il raggio d’azione (se si applica a classi o
ad oggetti): queste due caratteristiche di classificazione sono trasversali l’una rispetto
all’altra.
Per quanto riguarda lo scopo possiamo individuare pattern:
- creazionali: riguardanti la creazione di oggetti;
- strutturali: riguardo la composizione di classi e oggetti;
115
- comportamentali: riguardo il modo in cui classi od oggetti interagiscono tra loro e

come le responsabilità vengono divise.
Per quanto riguarda il raggio d’azione possiamo individuare:
- class pattern: relazioni tra classi e sottoclassi espresse tramite l’ereditarietà. Sono
di tipo statico, cioè fissate al momento della compilazione;
- object pattern: relazioni tra oggetti. Hanno carattere dinamico, cioè possono
variare durante l’esecuzione. Questi ultimi sono i più numerosi.
PATTERN CREAZIONALI
I pattern creazionali sono quei pattern che permettono di rendere i componenti del
sistema, che utilizzano determinati oggetti, indipendenti da come tali oggetti sono creati,
composti e rappresentati. In particolare un pattern creazionale:
• nasconde (nel senso di information hiding) la conoscenza di quali sono le classi
concrete effettivamente istanziate, sfruttando tipi astratti per definire le interfacce di
riferimento;
• nasconde dettagli sulla creazione e sulla composizione degli oggetti (es. parametri
usati al momento della creazione) all’utilizzatore dell’istanza;
Le due caratteristiche suddette conferiscono una notevole flessibilità al processo di
creazione, dal momento che ciò che viene creato in generale risulta essere disaccoppiato
dal contesto di utilizzo. Infatti solo l’oggetto creatore conosce il tipo effettivo dell’istanza e
ciò che viene esternamente reso pubblico è unicamente l’interfaccia di riferimento.
SINGLETON
Vediamo da vicino il design pattern utilizzato attivamente dal framework MVC CodeIgniter
che abbiamo scelto di utilizzare nel progetto del nostro portale web: Singleton.
Lo scopo del pattern Singleton è quello di assicurare che per una determinata classe
esista un’unica istanza attiva, fornendo un entry-point globale (un unico punto di accesso)
all’istanza stessa. Questo pattern si può rivelare utile nel caso in cui si abbia la necessità
di centralizzare informazioni e comportamenti in un’unica entità condivisa da tutti i suoi
utilizzatori. Tipicamente questo si verifica quando la classe mantiene informazioni di stato
116
che devono essere condivise da più parti del programma, e non è corretto, oppure non è
efficiente (ad es. nel caso di una cache), che queste informazioni siano duplicate.
La soluzione che più si adatta a risolvere la questione associata al pattern (unicità
dell’istanza) consiste nell’associare alla classe stessa la responsabilità di creare le proprie
istanze:
• innanzitutto si rende il costruttore della classe privato, in modo che non sia possibile
creare direttamente istanze (al di fuori del codice della classe);
• si fornisce un metodo “static” per ottenere l’unica istanza, che viene conservata in
un campo static privato della classe;
• a questo punto abbiamo due diverse varianti. Una secondo la quale l’istanza può
essere creata all’inizializzazione del programma, oppure la prima volta che viene
richiesta, mentre nell’altra variante l’istanza, se necessario, può appartenere a una
sottoclasse della classe Singleton.
In questo modo è la classe stessa che può assicurare che nessun’altra istanza possa
essere creata, intercettando e gestendo in modo centralizzato le richieste di creazione di
nuove istanze.
Pertanto l’unico partecipante del pattern è:
• Singleton (One, Two e Three)
Singleton definisce un membro per accedere all’unica istanza esistente, generalmente
creata internamente alla classe stessa.
L’esempio proposto mostra tre casistiche diverse di applicazione del pattern. La classe
One prevede l’inizializzazione statica dell’istanza. La proprietà Instance ritorna l’oggetto
equivalente di tipo One statico e privato. La classe Two prevede l’inizializzazione dinamica
su richiesta tramite il controllo del riferimento all’istanza. La proprietà Instance ritorna
anche in questo caso l’oggetto equivalente di tipo Two statico e privato. La classe Three
effettua un doppio controllo sul riferimento all’istanza, dentro e fuori ad un blocco a mutua
esclusione e in base ad esso attiva l’istanza. Ancora una volta la proprietà Instance ritorna
117
l’oggetto equivalente di tipo Three statico e privato. Se i primi due casi non sono thread-
safe, il terzo lo è (nell’ambito di uno stesso appdomain). La presenza del blocco di mutua
esclusione garantisce che la creazione dell’istanza sia effettivamente eseguita una volta
sola, anche in un contesto multi-thread.
Conseguenze dell’applicazione di questo pattern creazionale:

• accesso controllato all’unica istanza;
• non occorre introdurre variabili globali per accedere all’unica istanza;
• è semplice estendere (attraverso subclassing) la classe Singleton senza modificare
il codice che la usa;
• se necessario, è semplice passare da una singola istanza a un numero diverso di
istanze.
Bisogna comunque prestare attenzione al fatto che la soluzione associata ad un design
pattern viene espressa in un modo sufficientemente generale e pertanto vengono lasciati
numerosi gradi di libertà, quindi l’implementazione non necessariamente segue lo schema
di base.
118
PATTERN STRUTTURALI
I design pattern di tipo strutturale riguardano le modalità con cui classi e oggetti vengono
aggregati allo scopo di formare entità più complesse. In generale possiamo distinguere
due tipologie di pattern strutturali:
• pattern strutturali basati sulle classi, che sfruttano l’ereditarietà multipla (se prevista)
per combinare tra loro le interfacce e le implementazioni;
• pattern strutturali basati sugli oggetti, che descrivono le modalità di composizione di
oggetti al fine di estendere in fase di esecuzione le funzionalità di una classe (cosa
non possibile nel caso della composizione statica e tramite ereditarietà).
In generale la maggior parte dei pattern strutturali sono basati sugli oggetti.
PROXY
Vediamo da vicino un design pattern di tipo strutturale che abbiamo scelto di utilizzare nel
progetto del nostro portale web: Proxy.
Lo scopo del pattern Proxy (detto anche Surrogate) è quello di fornire un surrogato o un
segnaposto di un altro oggetto per controllarne l’accesso. Questo pattern, di tipo
strutturale basato sugli oggetti, è applicabile ogni volta che si voglia disporre di un
riferimento a un oggetto più versatile di un semplice puntatore, tale da permettere, per
esempio, di controllare l’accesso all’oggetto vero e proprio piuttosto che di fornire una
rappresentazione locale di un oggetto remoto.
Il pattern in questione introduce un livello di indirezione nell’accesso a un oggetto. Questa
indirezione ricopre significati diversi a seconda dei casi:
• proxy remoto, quando si vuole nascondere al client che un oggetto risiede in uno
spazio di indirizzamento diverso (esempio classico: Web Service);
• proxy virtuale, quando si vuole eseguire un’ottimizzazione nella creazione di un
oggetto particolarmente “costoso” e pesante piuttosto che memorizzare
informazioni aggiuntive relative all’oggetto rappresentato per posticipare l’accesso
all’oggetto stesso;
• proxy di protezione, quando si vuole gestire l’accesso a un oggetto tramite
l’esecuzione di azioni preliminari di controllo.
119
I partecipanti di questo pattern sono:

• Proxy (ServiceProxy): fornisce un’interfaccia identica a quella di Subject e agisce
da sostituto di RealSubject;
• Subject (IService): definisce l’interfaccia comune per Proxy e RealSubject,
rendendo possibile l’uso di Proxy in tutte le situazioni in cui è possibile utilizzare
RealSubject.
• RealSubject (MyService): rappresenta l’oggetto vero e proprio di cui Proxy è il
surrogato.
Nell’esempio proposto l’interfaccia IService fornisce il contratto che deve essere rispettato
sia dall’oggetto vero e proprio di tipo MyService, sia dal suo surrogato ServiceProxy.
Tramite la classe factory ServiceFactory, il client attiva un’istanza della classe proxy che
assegna a un riferimento di tipo IService. Il client peraltro non è consapevole di stare
usando un surrogato, semplicemente richiama i membri definiti dal contratto,
indipendentemente dal tipo concreto istanziato. La classe proxy permette di eseguire più
codice rispetto all’oggetto originario: internamente al metodo HandleRequest() vengono
infatti eseguite istruzioni prima e dopo la chiamata del metodo di destinazione. Nel caso
dell’esempio il tipo di istruzioni aggiuntive incluse nella funzione sono davvero semplici,
ma si può arrivare ad avere situazioni in cui il codice presente all’interno della classe proxy
è molto più corposo e sostanzioso.
120
PATTERN COMPORTAMENTALI
I design pattern comportamentali si riferiscono alla distribuzione delle responsabilità fra

oggetti tra loro correlati. Essi non affrontano unicamente gli aspetti relativi alla struttura
degli oggetti e delle classi interagenti, ma si focalizzano soprattutto sulle modalità di
comunicazione e collaborazione.
La maggior parte di questi pattern fornisce soluzioni per incapsulare le diverse funzionalità
in un oggetto specifico con l’intento di delegare ad esso l’esecuzione del codice vero e
proprio. Questo approccio permette in generale di eliminare le dipendenze dirette tra i vari
oggetti coinvolti, limitando l’accoppiamento e facilitando la possibilità di estendere e
modificare il codice senza grossi sforzi. La distribuzione delle responsabilità porta
inevitabilmente a ridurre la genericità di ciascun partecipante dei pattern, aspetto in gran
parte dovuto alla forte specializzazione che caratterizza le diverse classi che di volta in
volta sono delegate a fornire le funzionalità richieste.
Vediamo da vicino i design pattern utilizzati attivamente dal pattern architetturale MVC, di
cui abbiamo parlato quando abbiamo descritto il suo funzionamento e che quindi si
riveleranno di grande importanza nel progetto del nostro portale web: Observer e
Strategy.
OBSERVER
Il pattern Observer (noto anche col nome Publish-Subscribe) permette di definire una
dipendenza uno a molti fra oggetti, in modo tale che se un oggetto cambia il suo stato
121
interno, ciascuno degli oggetti dipendenti da esso viene notificato e aggiornato

automaticamente. L’Observer nasce dall’esigenza di mantenere un alto livello di
consistenza fra classi correlate, senza peraltro produrre situazioni di forte dipendenza e
accoppiamento elevato.
Il pattern Observer si presta ad essere utilizzato in diversi casi. Ad esempio, quando
un’astrazione presenta due diversi aspetti tra loro dipendenti, è possibile definire due
classi in cui incapsulare questi aspetti in modo tale da poterli utilizzare in maniera
indipendente. In questo scenario occorre comunque prevedere un meccanismo di
comunicazione che permetta di mantenere la consistenza tra le istanze delle due classi e il
pattern Observer fornisce una soluzione elegante al problema senza generare
accoppiamento. Un’altra situazione tipica di utilizzo si ha quando la modifica dello stato di
un oggetto (per esempio, un controllo dell’interfaccia utente) implica un cambiamento dello
stato di altri oggetti correlati, a prescindere dal loro numero (per esempio, altri controlli). In
questo caso la modifica dello stato dell’oggetto (detto anche Publisher) si deve propagare
agli oggetti correlati (detti anche Subscriber) in modo tale che essi possano aggiornare il
loro stato interno di conseguenza.

• Subject (delegate Subject.Notify): conosce i suoi Observer. Fornisce l’interfaccia
per associare e rimuovere oggetti Observer.
122
• Observer: fornisce l’interfaccia di notifica per gli oggetti a cui devono essere
segnalati i cambiamenti di stato di Subject.
• ConcreteSubject (Subject): contiene lo stato monitorato dagli Observer a cui viene
inviata la notifica.
• ConcreteObserver (Observer): mantiene un riferimento ad un oggetto
ConcreteSubject. Contiene le informazioni da mantenere sincronizzate con lo stato
del Subject. Implementa il metodo di gestione della notifica da eseguire allo scopo
di mantenere sincronizzati gli stati degli oggetti.
Il meccanismo per inviare notifiche nell’ambito del .NET Framework è fornito in modo
nativo dai tipi delegate e dagli eventi. Una classe che funge da Publisher (classe Subject)
espone in generale sulla sua interfaccia una serie di eventi corrispondenti ad un tipo
particolare di delegate. Le classi Subscriber (classe Observer) sottoscrivono l’evento e ad
esso associano un metodo interno (comunemente detto event handler) che deve rispettare
la firma definita dal tipo delegate associato all’evento. L’event handler viene chiamato nel
momento in cui il Publisher inoltra ai suoi Subscriber la notifica, rendendo possibile in
questo modo l’esecuzione di codice in ciascun Subscriber al variare dello stato interno del
Publisher.
STRATEGY
Il pattern Strategy permette di definire una famiglia di algoritmi, di incapsularli e renderli

intercambiabili fra loro. Questo pattern consente agli algoritmi di variare in modo
indipendente rispetto al loro contesto di utilizzo, fornendo un basso accoppiamento tra le
123
classi partecipanti del pattern e una alta coesione funzionale delle diverse strategie di
implementazione.
Il pattern Strategy fornisce di fatto un meccanismo di configurazione per una determinata
classe, utilizzando un comportamento specifico scelto fra tanti e “iniettato” nel momento
dell’utilizzo. L’operazione di iniezione può avvenire mediante diverse modalità, a seconda
dei casi. La modalità più comune di iniezione prevede l’uso del costruttore della classe per
selezionare l’algoritmo concreto da eseguire successivamente.

• Strategy (SortAlgorithm): dichiara l’interfaccia di riferimento per tutti gli algoritmi
concreti.
• ConcreteStrategy (QuickSort, BubbleSort e MergeSort): implementa un particolare
algoritmo utilizzando l’interfaccia definita da Strategy.
• Context (Context): carica un oggetto ConcreteStrategy e utilizza un riferimento a
Strategy per eseguire l’algoritmo concreto. Definisce l’interfaccia per accedere ai
membri dell’algoritmo caricato.
L’esempio proposto si riferisce all’utilizzo di un algoritmo per ordinare un insieme di numeri
interi. Dal momento che l’ordinamento può essere fatto in svariati modi, esistono diverse
versioni parallele dello stesso algoritmo. Incapsulando ciascuna di queste implementazioni
in un oggetto specifico, è possibile renderle tra loro intercambiabili senza impattare sul
codice che effettivamente utilizza l’algoritmo e sul risultato dell’operazione. La classe
astratta SortAlgorithm rappresenta il tipo base da cui ogni implementazione dell’algoritmo
deriva. Nell’esempio sono inclusi tre tipi distinti di ordinamento corrispondenti ad
altrettante classi concrete: QuickSort, BubbleSort e MergeSort. La classe Context carica
l’istanza di un algoritmo passata tramite il costruttore. Il metodo SortArray(int[]) di Context
internamente utilizza il metodo Sort(int) di SortAlgorithm, implementato in modo particolare
124
da ciascuna delle classi derivate. In questo modo il client (classe Program) utilizza
unicamente Context per eseguire gli ordinamenti e qualsiasi modifica degli algoritmi e
delle classi relative non impatta su di esso.
125
DIAGRAMMA DELLE COMPONENTI
Il nostro sistema software è composto fondamentalmente da 3 componenti, in relazione

con il pattern architetturale MVC da noi utilizzato. L’utilizzo di tale pattern ci consente di
gestire in maniera ottimale ciascun componente e di evidenziare le relazioni che
consentono la comunicazione, lo scambio di dati e l’invocazione di comandi. I tre
componenti sono:
• View
• Controller
• Model
Per quanto riguarda il nostro sistema c’è da notare un ulteriore aspetto, ossia il fatto che
ciascun componente espone 5 interfacce:
• interfaccia utente generico (user nel diagramma);
• interfaccia punto vendita (pv);
• interfaccia amministrazione (amministrazione);
• interfaccia marketing (marketing);
• interfaccia logistica (logistica).
L’utilizzo di una determinata interfaccia è strettamente legato ai privilegi di accesso che
l’utente acquisisce non appena effettua il login: quindi l’utente punto vendita utilizzerà solo
le interfacce di tipo pv, l’amministrazione solo le interfacce amministrazione e così via.
Il componente view contiene tutti i file che implementeranno l’interfaccia grafica del
software. Per semplicità le classi view sono suddivise in sotto-componenti a seconda
dell’interfaccia grafica che implementano. Nel dettaglio sono:
• amministrazione;
• logistica;
• marketing;
• moduli ;
• pv;
• utente.
Il componente model, appunto, contiene tutte le classi model. Forniscono un modello per
gli oggetti utilizzati dal sistema e contengono tutte le query per poter utilizzare il driver che
dà accesso al data base fisico.
126
Il componente controller contiene tutte le classi di tipo controller. Quindi è una collezione
di metodi, esposti opportunamente tramite le interfacce, che permettono di utilizzare le
informazioni contenute nel data base tramite le classi model. Contiene anche la classe
che, gestendo gli accessi, discrimina il tipo di utente che sta accedendo al sistema.
127
Component view
properties qualified name view
visibility public
leaf false
abstract false
indirectlyInstantiated true
use for code engineering true
interfaces amministrazione
logistica
marketing
pv
user
source of Usage controller
relation
sub- amministrazione: Fornitore_aggiunto
components Elimina_fornitore_non_riuscita
Elimina_fornitore_riuscita
Elimina_pv_non_riuscita
Elimina_pv_riuscita
Modifica_fornitore
Modifica_fornitore_riuscita
Modifica_insegna_pv
Modifica_insegna_pv_riuscita
Nuovo_fornitore
Visualizza_elenco_fornitori
Visualizza_elenco_ordini
Visualizza_elenco_pv
Visualizza_elenco_storico
Visualizza_fornitore
Visualizza_pv
logistica: Visualizza_elenco_fornitori
Visualizza_elenco_listini
Visualizza_elenco_prodotti
Visualizza_listino
Visualizza_ordine
Visualizza_prodotto
128
marketing: Listino_aggiunto
Elimina_listino_non_riuscita
Elimina_listino_riuscita
Elimina_prodotto_non_riuscita
Elimina_prodotto_riuscita
Elimina_reparto_riuscita_e_non
Modifica_listino
Modifica_listino_riuscita
Modifica_prodotto
Modifica_prodotto_non_consentita
Modifica_prodotto_riuscita
Nuovo_listino
Nuovo_prodotto
Nuovo_reparto
Prodotto_aggiunto
Visualizza_elenco_fornitori
Visualizza_elenco_listini
Visualizza_elenco_prodotti
Visualizza_elenco_reparti
Visualizza_listino
Visualizza_prodotto
menu: Login
Menu_amministrazione
Menu_logistica
Menu_marketing
Menu_pv
pv: Carrello
Disponibilita_non_sufficiente
Introduzione
Modifica_pv
Modifica_pv_riuscita
Nuovo_ordine
Ordine_aggiunto
Profilo
Visualizza_elenco_storico
Visualizza_ordine
Visualizza_prodotto
129
Visualizza_proprio_listino
Vota_ordine
Vota_ordine_storico
Voto_ordine_inserito
Voto_storico_inserito
utente: Chi_siamo
Contatti
Dove_siamo
Esito_recupera-password
Introduzione
Note_legali
Recupera_password
Registrati
Registrazione_riuscita
shown on Component Diagram
diagram
Component controller
properties qualified name controller
visibility public
leaf false
abstract false
logistica
marketing
pv
user
source of Usage model
relation
target of Usage view
relation
classes Autenticazione
Home
Home_amministrazione
Home_logistica
Home_marketing
Home_pv
130
ProtectionProxyOrdina
RealeOrdina
diagram
Component model
properties qualified name model
visibility public
leaf false
abstract false
logistica
marketing
pv
user
target of Usage controller
relation
classes Fornitore_model
Listino_model
Ordine_model
Prodotto_model
Reparto_model
Storico_model
Utente_model
diagram
131
PROGETTAZIONE LOGICA E BUSINESS RULES
Di seguito sono riportate le entità e le relazioni del modello E-R normalizzate (modello
relazionale):
FORNITORE (p_iva_fornitore, nome, indirizzo, tel, e-mail)
REPARTO (nome_reparto)
PRODOTTO (id_prodotto, nome, descrizione, data_scadenza, provenienza, prezzo,

disponibilita, p_iva_fornitore, nome_reparto)
LISTINO (nome_insegna, sconto_listino)
PRODOTTO_IN_LISTINO (nome_insegna, id_prodotto)
ORDINE (id_ordine, data_ordine, data_consegna, metodo_pagamento, stato_ordine, voto,

p_iva_pv)
ORDINE_PROD_LIST (nome_insegna, id_prodotto, id_ordine, quantita, prezzo_vendita)
PV (p_iva_pv, nome, indirizzo, tel, e-mail; orari_apertura, nome_insegna)
STORICO (id_storico, p_iva_pv, data_ordine, importo_fattura, pagamento_usato,

flag_stato_ordine)
132
BUSINESS RULES
FORNITORE:
◊ Il campo p_iva_fornitore è un codice numerico di 11 cifre;
◊ Il campo indirizzo è un campo di tipo testuale.
REPARTO:
◊ Il campo nome_reparto può assumere uno dei seguenti valori:
- gastronomia(formaggi e salumi);
- frutta e verdura;
- macelleria;
- pescheria;
- colazione;
- bevande;
- freschi e surgelati;
- forno;
- pasticceria;
- dispensa;
- gelati.
PRODOTTO:
◊ Il campo descrizione è un campo di tipo testuale che ci permetterà di esprimere
per ogni prodotto la quantità acquistabile: in particolare in esso troveremo traccia di
quello che è il nome del prodotto con la rispettiva quantità per lotto. Ad esempio:
100Kg mele, e così via.
LISTINO:
◊ Il campo sconto_listino è un FLOAT che non può eccedere il valore 100.
ORDINE:
◊ Il campo metodo_pagamento può assumere uno tra i seguenti valori:
- pagamento in contanti alla consegna;
- bonifico bancario;
133
- pagamento tramite paypal.

◊ Il campo stato_ordine può assumere uno tra i seguenti valori:
- in preparazione;
- pervenuto;
- evaso;
- annullato.
◊ Appena un ordine viene confermato da un punto vendita il campo stato_ordine
viene riempito col valore ‘in preparazione”.
◊ Il campo voto è un campo numerico.
◊ Il campo voto può assumere i seguenti valori: { NULL,1,2,3,4 }.
◊ Il campo voto IS NULL se (stato_ordine==‘in preparazione’ OR
stato_ordine==‘annullato’) AND (voto IS NOT NULL se
(stato_ordine==‘pervenuto’ OR stato_ordine==‘evaso’)).
ORDINE_PROD_LIST:
◊ Il campo quantita è un campo numerico. È riferito al numero di lotti acquistati per
ogni singolo prodotto.
◊ Il campo prezzo_vendita si ottiene dall’espressione che considera la somma dei
prezzi per le quantità indicate dei prodotti nell’ordine cui va sommato il 7% del
risultato di questa sommatoria per le spese di spedizione
PV:
◊ Il campo p_iva_pv è un codice numerico di 11 cifre.
◊ Il campo orari_apertura è un campo di tipo testuale.
STORICO:
◊ Il campo pagamento_usato può assumere uno tra i seguenti valori:
- pagamento in contanti alla consegna;
- bonifico bancario;
- pagamento tramite paypal.
◊ Il campo flag_stato_ordine è di tipo booleano.
134
CLASSI DI PROGETTO
Riportiamo di seguito il diagramma delle classi e le specifiche delle classi di progetto.
135
SPECIFICA DELLE CLASSI DI PROGETTO
Package
Package amministrazione
owner view
properties qualified name view::amministrazione
visibility public
ownedMember Elimina_fornitore_non_riuscita Elimina_fornitore_riuscita Elimina_pv_non_riuscita
Elimina_pv_riuscita Fornitore_aggiunto Modifica_fornitore
Modifica_fornitore_riuscita Modifica_insegna_pv Modifica_insegna_pv_riuscita
Nuovo_fornitore Visualizza_elenco_fornitori Visualizza_elenco_ordini
Visualizza_elenco_pv Visualizza_elenco_storico Visualizza_fornitore Visualizza_pv
Package logistica
owner view
properties qualified name view::logistica
visibility public
ownedMember Visualizza_elenco_fornitori Visualizza_elenco_listini Visualizza_elenco_ordini
Visualizza_elenco_prodotti Visualizza_fornitore Visualizza_listino Visualizza_ordine
Visualizza_prodotto
Package marketing
owner view
properties qualified name view::marketing
visibility public
ownedMember Elimina_listino_non_riuscita Elimina_listino_riuscita Elimina_prodotto_non_riuscita
Elimina_prodotto_riuscita Elimina_reparto_riuscita_e_non Listino_aggiunto
Modifica_listino Modifica_listino_riuscita Modifica_prodotto
Modifica_prodotto_non_consentita Modifica_prodotto_riuscita Nuovo_listino
Nuovo_prodotto Nuovo_reparto Prodotto_aggiunto Visualizza_elenco_fornitori
Visualizza_elenco_listini Visualizza_elenco_prodotti Visualizza_elenco_reparti
Visualizza_fornitore Visualizza_listino Visualizza_prodotto
Package menu
owner view
properties qualified name view::menu
visibility public
ownedMember Login Menu_amministrazione Menu_logistica Menu_marketing Menu_pv
136
Package pv
owner view
properties qualified name view::pv
visibility public
ownedMember Carrello Introduzione Modifica_pv Modifica_riuscita_pv Profilo
Visualizza_proprio_listino
Package utente
owner view
properties qualified name view::utente
visibility public
ownedMember amministrazione logistica marketing menu pv utente
Package model
owner Root
properties qualified name model
visibility public
ownedMember Fornitore_model Listino_model Ordine_model Prodotto_model Reparto_model
Storico_model Utente_model
Package view
owner Root
properties qualified name view
visibility public
ownedMember amministrazione logistica marketing menu pv utente
Package controller
owner Root
properties qualified name controller
visibility public
ownedMember Autenticazione Home Home_amministrazione Home_logistica Home_marketing
Home_pv
137
Classi
In tutte le classi controller che consentono di mostrare l’home personalizzata in base al

tipo di utente loggato, ricorrono i metodi dove_siamo(), chi_siamo(), note_legali(),
contatti(). Questi sono metodi generali di nessuna utilità dal punto di vista del
funzionamento del portale: essi forniscono, semplicemente, un servizio informativo.
Specifca dei metodi:

• dove_siamo() – chiama la classe view che mostra la pagina html che contiene le
indicazioni sulla dislocazione geografica dell’azienda distributrice;
• chi_siamo() – chiama la classe view che mostra la pagina php che fornisce una
presentazione dell’azienda distributrice;
• note_legali() – chiama la classe view che mostra la pagina php con la citazione
delle leggi e dei regolamenti alla base del commercio elettronico e la specifica degli
obblighi contrattuali che si contraggono usufruendo dei servizi del portale;
• contatti() – chiama la classe view che mostra la pagina php con le informazioni per
contattare l’azienda distributrice che fornisce il servizio di vendita on line.
L’implementazione di tali metodi e delle classi view chiamate è sempre la stessa, pertanto
vi è una ridondanza nel codice.
Questo potrebbe sembrare superfluo o, addirittura, controproducente, dato che

aumentano le dimensioni del codice con conseguente aumento della difficoltà di
manutenzione, aggiornamento e controllo.
D’altro canto, tuttavia, questa scelta ci permette di mantenere il portale completamente
disaccoppiato dal punto di vista della tipologia di utente loggato, quindi è più semplice
effettuare delle modifiche selettive. Ad esempio è molto semplice modificare un certo
metodo solo per l’utente pv; o, ancora, si potrebbe decidere di non mostrare alcune
informazioni agli utenti dell’azienda distributrice, a tutti oppure ad una parte.
Il disaccoppiamento delle varie aree funzionali del portale permette, oltre ad una più facile
modifica del sistema, anche una maggiore facilità di estensione. Quindi la nostra scelta, a
prima vista sconveniente, risulta essere utile al fine di modificare il sistema in maniera
localizzata e circoscritta.
138
Lo stesso discorso vale per le funzioni di filtraggio dei risultati di una query di tipo mostra
elenco (di qualsiasi tipo: elenco pv, fornitori, prodotti, ordini, listini, storico).
Inoltre in tutte le classi controller che permettono di visualizzare le varie home page, è
presente il metodo index(). Tale metodo è tipico nell’ambito dei portali internet e, nel
nostro caso, contiene le chiamate alle classi view, le quali mostreranno effettivamente
all’utente informazioni relative alla home page. L’implementazione del metodo si
differenzia a seconda della classe che lo chiama in quanto invoca una differente classe
view.
Class Home
diagram Hom e
Property1:Introduzione
Property2:Login
Property3:Dove_siamo
Property4:Contatti
Property5:Chi_siamo
Property6:Note_legali
Property7:Recupera_passw ord
Property8:Esito_recupera_passw ord
index()
dove_siamo()
chi_siamo()
note_legali()
contatti()
owner controller
properties qualified name controller::Home
visibility public
leaf false
abstract false
active false
ownedMember chi_siamo contatti dove_siamo index note_legali Property1 Property2 Property3
Property4 Property5 Property6 Property7 Property8
associations to from to Association name
Property1 Introduzione
Property2 Login
Property3 Dove_siamo
Property4 Contatti
Property5 Chi_siamo
Property6 Note_legali
Property7 Recupera_password
Property8 Esito_recupera_password
shown on Class Diagram
diagram
139
Class Chi_siamo
diagram Chi_siam o
owner utente
properties qualified name view::utente::Chi_siamo
visibility public
leaf false
abstract false
active false
associations from Association name
from Home (Property5)
typedElements Class Home Property Property5

diagram
Class Contatti
diagram Contatti
owner utente
properties qualified name view::utente::Contatti
visibility public
leaf false
abstract false
active false

Class Home_pv Property Property14
diagram
Class Dove_siamo
diagram Dove_siam o
owner utente
properties qualified name view::utente::Dove_siamo
visibility public
leaf false
abstract false
active false
from Home_pv (Property13)
Home (Property4)
140

diagram
Class Introduzione
diagram Introduzione
owner utente
properties qualified name view::utente::Introduzione
visibility public
leaf false
abstract false
active false

diagram
Class Note_legali
diagram Note_legali
owner utente
properties qualified name view::utente::Note_legali
visibility public
leaf false
abstract false
active false

diagram
Class Login
diagram Login
Property1:Autenticazione
owner menu
141
properties qualified name view::menu::Login

visibility public
leaf false
abstract false
active false
ownedMember Property1
Property1 Autenticazione

diagram
Class Recupera_password
diagram Recupera_passw ord
owner utente
properties qualified name view::utente::Recupera_password
visibility public
leaf false
abstract false
active false

diagram
Class Esito_recupera_password
diagram Esito_recupera_passw ord
owner utente
properties qualified name view::utente::Esito_recupera_password
visibility public
leaf false
abstract false
active false

diagram
142
Class Autenticazione
diagram Autenticazione
Property1:Registrati
Property2:Registrazione_riuscita
Property3:Utente_model
Property4:Home_amministrazione
Property5:Home_logistica
Property6:Home_marketing
Property7:Home_pv
autenticazione()
index()
verifica()
logout()
registrati()
registrazione()
consenso_privacy()
esiste_user_name()
esiste_partita_iva()
recupera_passw ord()
invia_nuova_passw ord()
genera_passw ord()
owner controller
properties qualified name controller::Autenticazione
visibility public
leaf false
abstract false
active false
ownedMember autenticazione consenso_privacy esiste_partita_iva esiste_user_name index
invia_nuova_password logout Property1 Property2 Property3 Property4 Property5
Property6 Property7 recupera_password registrati registrazione verifica
Property1 Registrati
Property2 Registrazione_riuscita
Property3 Utente_model
Property4 Home_amministrazione
Property5 Home_logistica
Property6 Home_marketing
Property7 Home_pv
from Login (Property1)
typedElements Class Login Property Property1

diagram
143
Specifica dei metodi:

- autenticazione() – costruttore della classe;
- verifica() – verifica i dati immessi per l’autenticazione;
- logout() – termina la sessione dell’utente attualmente loggato;
- registrati() – salva sul database i dati del nuovo utente tramite una classe model;
- registrazione() – compone il form di registrazione;
- consenso_privacy() – controlla che l’utente abbia acconsentito al trattamento dei
dati personali nel form di registrazione;
- esiste_user_name() – controlla, nel form di registrazione, che l’utente non abbia
specificato uno username già in uso;
- esiste_partita_iva() – controlla, nel form di registrazione, che l’utente non abbia
specificato uno username già in uso;
- recupera_password() – chiama la view che mostra le informazioni per il recupero
della password;
- invia_nuova_password() – genera una nuova password e la invia all’utente
tramite e-mail;
- genera_password() – genera una nuova password casualmente.
Class Registrati
diagram Registrati
owner utente
properties qualified name view::utente::Registrati
visibility public
leaf false
abstract false
active false
from Autenticazione (Property1)
typedElements Class Autenticazione Property Property1

diagram
144
Class Registrazione_riuscita
diagram Registrazione_riuscita
owner utente
properties qualified name view::utente::Registrazione_riuscita
visibility public
leaf false
abstract false
active false

diagram
145
Class Home_amministrazione
diagram Hom e_am m inistrazione
Property1:Fornitore_aggiunto
Property2:Modifica_fornitore
Property3:Modifica_fornitore_riuscita
Property4:Nuovo_fornitore
Property5:Visualizza_elenco_fornitori
Property6:Visualizza_elenco_ordini
Property7:Visualizza_elenco_pv
Property8:Visualizza_elenco_storico
Property9:Visualizza_fornitore
Property10:Visualizza_pv
Property11:Fornitore_model
Property12:Ordine_model
Property13:Storico_model
Property15:Menu_amministrazione
Property16:Elimina_fornitore_riuscita
Property17:Elimina_fornitore_non_riuscita
Property18:Elimina_pv_riuscita
Property19:Elimina_pv_non_riuscita
Property20:Modifica_insegna_pv
Property21:Modifica_insegna_pv_riuscita
home_amministrazione()
index()
dove_siamo()
visualizza_elenco_storico()
filtra_elenco_storico()
visualizza_elenco_ordine()
filtra_elenco_ordine()
gestione_pv()
filtra_pv()
visualizza_pv()
elimina_pv()
gestione_fornitori()
nuovo_fornitore()
aggiungi_fornitore()
visualizza_fornitore()
modifica_fornitore()
conferma_modifiche_fornitore()
elimina_fornitore()
esiste_p_iva_f()
filtra_elenco_pv()
filtra_elenco_fornitore()
chi_siamo()
note_legali()
contatti()
modifica_insegna_pv()
conferma_modifica_insegna_pv()
owner controller
properties qualified name controller::Home_amministrazione
visibility public
146
leaf false
abstract false
active false
ownedMember aggiungi_fornitore chi_siamo conferma_modifica_insegna_pv
conferma_modifiche_fornitore contatti dove_siamo elimina_fornitore elimina_pv
esiste_p_iva_f filtra_elenco_fornitore filtra_elenco_ordine filtra_elenco_pv
filtra_elenco_storico filtra_pv gestione_fornitori gestione_pv home_amministrazione
index modifica_fornitore modifica_insegna_pv note_legali nuovo_fornitore
Property1 Property10 Property11 Property12 Property13 Property14 Property15
visualizza_elenco_ordine visualizza_elenco_storico visualizza_fornitore
visualizza_pv
Property1 Fornitore_aggiunto
Property2 Modifica_fornitore
Property3 Modifica_fornitore_riuscita
Property4 Nuovo_fornitore
Property5 Visualizza_elenco_fornitori
Property6 Visualizza_elenco_ordini
Property7 Visualizza_elenco_pv
Property8 Visualizza_elenco_storico
Property9 Visualizza_fornitore
Property10 Visualizza_pv
Property11 Fornitore_model
Property12 Ordine_model
Property13 Storico_model
Property15 Menu_amministrazione
Property16 Elimina_fornitore_riuscita
Property17 Elimina_fornitore_non_riuscita
Property18 Elimina_pv_riuscita
Property19 Elimina_pv_non_riuscita
Property20 Modifica_insegna_pv
Property21 Modifica_insegna_pv_riuscita

diagram

- home_amministrazione() – costruttore;
- visualizza_elenco_storico() – chiama la model che effettua la query sul database
per prelevare gli ordini nello storico, e poi la view che li mostra a schermo;
- filtra_elenco_storico() – filtra l’elenco precedente a seconda dei valori specificati;
- visualizza_elenco_ordine() – chiama la model che effettua la query sul database
per prelevare gli ordini, e poi la view che li mostra a schermo;
- filtra_elenco_ordine() – filtra l’elenco precedente a seconda dei valori specificati;
147
- gestione_pv() – permette l’accesso all’area di gestione dei punti vendita

mostrandone fin da subito un elenco;
- filtra_pv() – filtra l’elenco dei punti vendita;
- visualizza_pv() – mostra informazioni aggiuntive sul punto vendita selezionato;
- elimina_pv() – elimina il punto vendita selezionato;
- gestione_fornitori() – permette l’accesso all’area di gestione dei fornitori
- nuovo_fornitore() – salva sul database il nuovo fornitore tramite la classe model;
- aggiungi_fornitore() – compone il form di aggiunta del nuovo fornitore;
- visualizza_fornitore() – mostra informazioni aggiuntive sul fornitore selezionato;
- modifica_fornitore() – entra nell’area di modifica delle informazioni relative al
fornitore selezionato;
- conferma_modifiche_fornitore() – controllo sulla richiesta di conferma delle
modifiche;
- elimina_fornitore() – elimina il fornitore selezionato;
- esiste_p_iva_f() – controlla che la partita iva del fornitore che si sta aggiungendo
o modificando non appartenga già ad un altro fornitore;
- filtra_elenco_pv() – filtra l’elenco dei punti vendita;
- filtra_elenco_fornitore() – filtra l’elenco dei fornitori;
- modifica_insegna_pv() – modifica l’insegna a cui è assegnato il pv;
- conferma_modifica_insegna_pv() – controllo sulla richiesta di conferma delle
modifiche.
Class Menu_amministrazione
diagram Menu_am m inistrazione
owner menu
properties qualified name view::menu::Menu_amministrazione
visibility Public
leaf False
abstract False
active False
from Home_amministrazione (Property15)
typedElements Class Home_amministrazione Property Property15

diagram
148
Class Fornitore_aggiunto
diagram Fornitore_aggiunto
owner amministrazione
properties qualified name view::amministrazione::Fornitore_aggiunto
visibility public
leaf false
abstract false
active false

diagram
Class Modifica_fornitore
diagram Modifica_fornitore
properties qualified name view::amministrazione::Modifica_fornitore
visibility public
leaf false
abstract false
active false

diagram
Class Modifica_fornitore_riuscita
diagram Modifica_fornitore_riuscita
properties qualified name view::amministrazione::Modifica_fornitore_riuscita
visibility public
leaf false
abstract false
149
active false

diagram
Class Nuovo_fornitore
diagram Nuovo_fornitore
properties qualified name view::amministrazione::Nuovo_fornitore
visibility public
leaf false
abstract false
active false

diagram
Class Visualizza_elenco_fornitore
diagram Visualizza_elenco_fornitori
properties qualified name view::amministrazione::Visualizza_elenco_fornitori
visibility public
leaf false
abstract false
active false

diagram
150
Class Visualizza_elenco_ordini
diagram Visualizza_elenco_ordini
properties qualified name view::amministrazione::Visualizza_elenco_ordini
visibility public
leaf false
abstract false
active false

diagram
Class Visualizza_elenco_pv
diagram Visualizza_elenco_pv
properties qualified name view::amministrazione::Visualizza_elenco_pv
visibility public
leaf false
abstract false
active false

diagram
Class Visualizza_elenco_storico
diagram Visualizza_elenco_storico
properties qualified name view::amministrazione::Visualizza_elenco_storico
visibility public
leaf false
abstract false
151
active false

diagram
Class Visualizza_fornitore
diagram Visualizza_fornitore
properties qualified name view::amministrazione::Visualizza_fornitore
visibility public
leaf false
abstract false
active false

diagram
Class Visualizza_pv
diagram Visualizza_pv
properties qualified name view::amministrazione::Visualizza_pv
visibility public
leaf false
abstract false
active false

diagram
152
Class Elimina_fornitore_non_riuscita
diagram Elim ina_fornitore_non_riuscita
properties qualified name view::amministrazione::Elimina_fornitore_non_riuscita
visibility public
leaf false
abstract false
active false

diagram
Class Elimina_fornitore_riuscita
diagram Elim ina_fornitore_riuscita
properties qualified name view::amministrazione::Elimina_fornitore_riuscita
visibility public
leaf false
abstract false
active false

diagram
Class Elimina_pv_non_riuscita
diagram Elim ina_pv_non_riuscita
properties qualified name view::amministrazione::Elimina_pv_non_riuscita
visibility public
leaf false
abstract false
153
active false

diagram
Class Elimina_pv_riuscita
diagram Elim ina_pv_riuscita
properties qualified name view::amministrazione::Elimina_pv_riuscita
visibility public
leaf false
abstract false
active false

diagram
Class Modifica_insegna_pv
diagram Modifica_insegna_pv
properties qualified name view::amministrazione::Modifica_insegna_pv
visibility public
leaf false
abstract false
active false

diagram
154
Class Modifica_insegna_pv_riuscita
diagram Modifica_insegna_pv_riuscita
properties qualified name view::amministrazione::Modifica_insegna_pv_riuscita
visibility public
leaf false
abstract false
active false

diagram
155
Class Home_logistica
diagram Hom e_logistica
Property2:Visualizza_elenco_listini
Property4:Visualizza_elenco_prodotti
Property6:Visualizza_ordine
Property7:Visualizza_prodotto
Property9:Listino_model
Property11:Prodotto_model
Property12:Reparto_model
Property13:Menu_logistica
Property14:Visualizza_listino
index()
dove_siamo()
gestione_ordine()
visualizza_ordine()
modifica_stato_ordine()
visualizza_elenco_listino()
filtra_elenco_listino()
visualizza_listino()
visualizza_elenco_prodotto()
filtra_elenco_prodotto()
visualizza_prodotto()
visualizza_elenco_fornitore()
home_logistica()
chi_siamo()
note_legali()
contatti()
owner controller
properties qualified name controller::Home_logistica
visibility public
leaf false
abstract false
active false
ownedMember chi_siamo contatti dove_siamo filtra_elenco_fornitore filtra_elenco_listino
filtra_elenco_ordine filtra_elenco_prodotto gestione_ordine home_logistica index
modifica_stato_ordine note_legali Property1 Property10 Property11 Property12
Property13 Property14 Property2 Property3 Property4 Property5 Property6 Property7
Property8 Property9 visualizza_elenco_fornitore visualizza_elenco_listino
visualizza_elenco_prodotto visualizza_fornitore visualizza_listino visualizza_ordine
visualizza_prodotto
156

Property2 Visualizza_elenco_listini
Property4 Visualizza_elenco_prodotti
Property6 Visualizza_ordine
Property7 Visualizza_prodotto
Property9 Listino_model
Property11 Prodotto_model
Property12 Reparto_model
Property13 Menu_logistica
Property14 Visualizza_listino

diagram

- home_logistica() – costruttore;
- gestione_ordine() – permette l’accesso all’area di logistica degli ordini
- filtra_elenco_ordine() – filtra l’elenco degli ordini;
- visualizza_ordine() – visualizza informazioni aggiuntive sull’ordine selezionato;
- modifica_stato_ordine() – modifica lo stato dell’ordine selezionato;
- visualizza_elenco_listino() – chiama la model che effettua la query sul database
per prelevare i listini, e poi la view che li mostra a schermo;
- filtra_elenco_listino() – filtra l’elenco dei listini;
- visualizza_elenco_prodotto() – chiama la model che effettua la query sul
database per prelevare i prodotti, e poi la view che li mostra a schermo;
- filtra_elenco_prodotto() – filtra l’elenco dei prodotti;
- visualizza_prodotto() – visualizza informazioni aggiuntive sul prodotto
selezionato;
- visualizza_elenco_fornitore() – chiama la model che effettua la query sul
database per prelevare i fornitori, e poi la view che li mostra a schermo;
- visualizza_fornitore() – mostra informazioni aggiuntive sul fornitore selezionato.
157
Class Menu_logistica
diagram Menu_logistica
owner menu
properties qualified name view::menu::Menu_logistica
visibility public
leaf false
abstract false
active false
from Home_logistica (Property13)
typedElements Class Home_logistica Property Property13

diagram
Class Visualizza_elenco_fornitori
owner logistica
properties qualified name view::logistica::Visualizza_elenco_fornitori
visibility public
leaf false
abstract false
active false

diagram
Class Visualizza_elenco_listini
diagram Visualizza_elenco_listini
owner logistica
properties qualified name view::logistica::Visualizza_elenco_listini
visibility public
leaf false
abstract false
158
active false

diagram
owner logistica
properties qualified name view::logistica::Visualizza_elenco_ordini
visibility public
leaf false
abstract false
active false

diagram
Class Visualizza_elenco_prodotti
diagram Visualizza_elenco_prodotti
owner logistica
properties qualified name view::logistica::Visualizza_elenco_prodotti
visibility public
leaf false
abstract false
active false

diagram
159
owner logistica
properties qualified name view::logistica::Visualizza_fornitore
visibility public
leaf false
abstract false
active false

diagram
Class Visualizza_ordine
diagram Visualizza_ordine
owner logistica
properties qualified name view::logistica::Visualizza_ordine
visibility public
leaf false
abstract false
active false

diagram
Class Visualizza_prodotto
diagram Visualizza_prodotto
owner logistica
properties qualified name view::logistica::Visualizza_prodotto
visibility public
leaf false
abstract false
160
active false

diagram
Class Visualizza_listino
diagram Visualizza_listino
owner logistica
properties qualified name view::logistica::Visualizza_listino
visibility public
leaf false
abstract false
active false

diagram
161
Class Home_marketing
diagram Hom e_m arketing
Property1:Listino_aggiunto
Property2:Modifica_prodotto
Property3:Modifica_prodotto_riuscita
Property4:Nuovo_listino
Property5:Nuovo_prodotto
Property6:Prodotto_aggiunto
Property8:Visualizza_elenco_listini
Property9:Visualizza_elenco_prodotti
Property16:Menu_marketing
Property17:Elimina_listino_riuscita
Property18:Elimina_listino_non_riuscita
Property19:Elimina_prodotto_riuscita
Property20:Elimina_prodotto_non_riuscita
Property21:Modifica_listino
Property22:Modifica_listino_riuscita
Property23:Visualizza_listino
Property24:Nuovo_reparto
Property25:Visualizza_elenco_reparti
Property26:Modifica_prodotto_non_consentita
Property27:Elimina_reparto_riuscita_e_non
index()
dove_siamo()
gestione_prodotti()
nuovo_prodotto()
aggiungi_prodotto()
modifica_prodotto()
conferma_modifiche_prodotto()
elimina_prodotto()
esiste_cod_prodotto()
gestione_listini()
filtra_elenco_listino()
nuovo_listino()
aggiungi_listino()
modifica_listino()
conferma_modifiche_listino()
elimina_listino()
visualizza_elenco_fornitore()
home_marketing()
chi_siamo()
note_legali()
contatti()
gestione_reparti()
nuovo_reparto()
aggiungi_reparto()
esiste_nomeReparto()
elimina_reparto()
esiste_nomeInsegna()
owner controller
properties qualified name controller::Home_marketing
visibility public
162
leaf false
abstract false
active false
ownedMember aggiungi_listino aggiungi_prodotto aggiungi_reparto chi_siamo
conferma_modifiche_listino conferma_modifiche_prodotto contatti dove_siamo
elimina_listino elimina_prodotto elimina_reparto esiste_cod_prodotto
esiste_nomeInsegna esiste_nomeReparto filtra_elenco_fornitore filtra_elenco_listino
filtra_elenco_prodotto gestione_listini gestione_prodotti gestione_reparti
home_marketing index modifica_listino modifica_prodotto note_legali nuovo_listino
nuovo_prodotto nuovo_reparto Property1 Property10 Property11 Property12
Property9 visualizza_elenco_fornitore visualizza_fornitore visualizza_listino
visualizza_prodotto
Property1 Listino_aggiunto
Property2 Modifica_prodotto
Property3 Modifica_prodotto_riuscita
Property4 Nuovo_listino
Property5 Nuovo_prodotto
Property6 Prodotto_aggiunto
Property8 Visualizza_elenco_listini
Property9 Visualizza_elenco_prodotti
Property16 Menu_marketing
Property17 Elimina_listino_riuscita
Property18 Elimina_listino_non_riuscita
Property19 Elimina_prodotto_riuscita
Property20 Elimina_prodotto_non_riuscita
Property21 Modifica_listino
Property22 Modifica_listino_riuscita
Property23 Visualizza_listino
Property24 Nuovo_reparto
Property25 Visualizza_elenco_reparti
Property26 Modifica_prodotto_non_consentita
Property27 Elimina_reparto_riuscita_e_non

diagram

- home_marketing() – costruttore;
163
- gestione_prodotti() – permette l’accesso all’area di gestione dei prodotti e ne

mostra un elenco;
- filtra_elenco_prodotto() – filtra l’elenco dei prodotti;
- nuovo_prodotto() – aggiunge al database un nuovo prodotto tramite la classe
model;
- aggiungi_prodotto() – compone il form di aggiunta del nuovo prodotto;
- visualizza_prodotto() – mostra informazioni aggiuntive sul prodotto selezionato;
- modifica_prodotto() – modifica i dati del prodotto selezionato;
- conferma_modifiche_prodotto() – chiede conferma delle modifiche apportate al
prodotto;
- elimina_prodotto() – elimina il prodotto selezionato;
- esiste_cod_prodotto() – controlla che il codice del prodotto che si vuole
modificare non sia già in uso;
- gestione_listini() – consente l’accesso all’area di gestione dei listini, e ne mostra
fin da subito un elenco;
- filtra_elenco_listino() – filtra l’elenco dei listini;
- aggiungi_listino() – aggiunge al database un nuovo listino tramite la classe
model;
- visualizza_listino() – compone il form di aggiunta del nuovo listino;
- modifica_listino() – modifica il listino selezionato;
- conferma_modifiche_listino() – chiede conferma dei dati modificati;
- visualizza_elenco_fornitore() – chiama la model che effettua la query sul
database per prelevare i fornitori, e poi chiama la view per mostrarli;
- visualizza_fornitore() – mosta informazioni aggiuntive sul fornitore selezionato;
- gestione_reparti() – entra nell’area di gestione dei reparti a cui appartengono i
prodotti, mostrandone fin da subito un elenco;
- nuovo_reparto() – aggiunge al database un nuovo reparto tramite la classe
model;
- aggiungi_reparto() – compone il form di aggiunta del nuovo reparto;
- esiste_nomeReparto() – controlla che il nome del reparto non sia già in uso;
- elimina_reparto() – elimina il reparto selezionato;
- esiste_nomeInsegna() – controlla che il nome dell’insegna non sia già in uso.
164
Class Menu_marketing
diagram Menu_m arketing
owner menu
properties qualified name view::menu::Menu_marketing
visibility public
leaf false
abstract false
active false
from Home_marketing (Property16)
typedElements Class Home_marketing Property Property16

diagram
Class Listino_aggiunto
diagram Listino_aggiunto
owner marketing
properties qualified name view::marketing::Listino_aggiunto
visibility public
leaf false
abstract false
active false

diagram
Class Modifica_prodotto
diagram Modifica_prodotto
owner marketing
properties qualified name view::marketing::Modifica_prodotto
visibility public
leaf false
abstract false
165
active false

diagram
Class Modifica_prodotto_riuscita
diagram Modifica_prodotto_riuscita
owner marketing
properties qualified name view::marketing::Modifica_prodotto_riuscita
visibility public
leaf false
abstract false
active false

diagram
Class Nuovo_listino
diagram Nuovo_listino
owner marketing
properties qualified name view::marketing::Nuovo_listino
visibility public
leaf false
abstract false
active false

diagram
166
Class Nuovo_prodotto
diagram Nuovo_prodotto
owner marketing
properties qualified name view::marketing::Nuovo_prodotto
visibility public
leaf false
abstract false
active false

diagram
Class Prodotto_aggiunto
diagram Prodotto_aggiunto
owner marketing
properties qualified name view::marketing::Prodotto_aggiunto
visibility public
leaf false
abstract false
active false

diagram
Class Visualizza_elenco_fornitori
owner marketing
properties qualified name view::marketing::Visualizza_elenco_fornitori
visibility public
leaf false
abstract false
167
active false

diagram
Class Visualizza_elenco_listini
diagram Visualizza_elenco_listini
owner marketing
properties qualified name view::marketing::Visualizza_elenco_listini
visibility public
leaf false
abstract false
active false

diagram
Class Visualizza_elenco_prodotti
diagram Visualizza_elenco_prodotti
owner marketing
properties qualified name view::marketing::Visualizza_elenco_prodotti
visibility public
leaf false
abstract false
active false

diagram
168
owner marketing
properties qualified name view::marketing::Visualizza_fornitore
visibility public
leaf false
abstract false
active false

diagram
owner marketing
properties qualified name view::marketing::Visualizza_prodotto
visibility public
leaf false
abstract false
active false

diagram
Class Elimina_listino_non_riuscita
diagram Elim ina_listino_non_riuscita
owner marketing
properties qualified name view::marketing::Elimina_listino_non_riuscita
visibility public
leaf false
abstract false
169
active false

diagram
Class Elimina_listino_riuscita
diagram Elim ina_listino_riuscita
owner marketing
properties qualified name view::marketing::Elimina_listino_riuscita
visibility public
leaf false
abstract false
active false

diagram
Class Elimina_prodotto_non_riuscita
diagram Elim ina_prodotto_non_riuscita
owner marketing
properties qualified name view::marketing::Elimina_prodotto_non_riuscita
visibility public
leaf false
abstract false
active false

diagram
170
Class Elimina_prodotto_riuscita
diagram Elim ina_prodotto_riuscita
owner marketing
properties qualified name view::marketing::Elimina_prodotto_riuscita
visibility public
leaf false
abstract false
active false

diagram
Class Modifica_listino
diagram Modifica_listino
owner marketing
properties qualified name view::marketing::Modifica_listino
visibility public
leaf false
abstract false
active false

diagram
Class Modifica_listino_riuscita
diagram Modifica_listino_riuscita
owner marketing
properties qualified name view::marketing::Modifica_listino_riuscita
visibility public
leaf false
abstract false
171
active false

diagram
Class Visualizza_listino
diagram Visualizza_listino
owner marketing
properties qualified name view::marketing::Visualizza_listino
visibility public
leaf false
abstract false
active false

diagram
Class Nuovo_reparto
diagram Nuovo_reparto
owner marketing
properties qualified name view::marketing::Nuovo_reparto
visibility public
leaf false
abstract false
active false

diagram
172
Class Visualizza_elenco-reparti
diagram Visualizza_elenco_reparti
owner marketing
properties qualified name view::marketing::Visualizza_elenco_reparti
visibility public
leaf false
abstract false
active false

diagram
Class Modifica_prodotto_non_consentita
diagram Modifica_prodotto_non_consentita
owner marketing
properties qualified name view::marketing::Modifica_prodotto_non_consentita
visibility public
leaf false
abstract false
active false

diagram
173
Class Elimina_reparto_riuscita_e_non
diagram Elim ina_reparto_riuscita_e_non
owner marketing
properties qualified name view::marketing::Elimina_reparto_riuscita_e_non
visibility public
leaf false
abstract false
active false

diagram
174
Class Home_pv
diagram Hom e_pv
Property1:Carrello
Property2:Introduzione
Property3:Modifica_pv
Property4:Modifica_pv_riuscita
Property5:Profilo
Property6:Visualizza_proprio_listino
Property13:Dove_siamo
Property14:Contatti
Property15:Menu_pv
Property16:Storico_model
Property17:Disponibilita_non_sufficiente
Property18:Nuovo_ordine
Property19:Ordine_aggiunto
Property21:Visualizza_elenco_storico
Property22:Visualizza_ordine
Property24:Vota_ordine
Property25:Voto_ordine_inserito
Property26:Vota_ordine_storico
Property27:Voto_storico_inserito
home_pv()
index()
dove_siamo()
aggiungi_al_carrello()
visualizza_carrello()
modifica_carrello()
effettua_ordine()
profilo()
modifica_pv()
conferma_modifiche_pv()
esiste_username()
passw ord_corretta()
esiste_partita_iva()
aggiungi_ordine()
visualizza_ordini_attivi()
visualizza_ordine()
vota_ordine()
conferma_voto()
visualizza_storico()
filtra_visualizza_storico()
vota_ordine_in_storico()
conferma_voto_storico()
chi_siamo()
note_legali()
contatti()
owner controller
properties qualified name controller::Home_pv
visibility public
175
leaf false
abstract false
active false
ownedMember aggiungi_al_carrello aggiungi_ordine chi_siamo conferma_modifiche_pv
conferma_voto conferma_voto_storico contatti dove_siamo effettua_ordine
esiste_partita_iva esiste_username filtra_elenco_ordine filtra_elenco_prodotto
filtra_visualizza_storico home_pv index modifica_carrello modifica_pv note_legali
password_corretta profilo Property1 Property10 Property11 Property12 Property13
visualizza_carrello visualizza_listino visualizza_ordine visualizza_ordini_attivi
visualizza_prodotto visualizza_storico vota_ordine vota_ordine_in_storico
Property1 Carrello
Property2 Introduzione
Property3 Modifica_pv
Property4 Modifica_pv_riuscita
Property5 Profilo
Property6 Visualizza_proprio_listino
Property15 Menu_pv
Property16 Storico_model
Property17 Disponibilita_non_sufficiente
Property18 Nuovo_ordine
Property19 Ordine_aggiunto
Property21 Visualizza_elenco_storico
Property22 Visualizza_ordine
Property24 Vota_ordine
Property25 Voto_ordine_inserito
Property26 Vota_ordine_storico
Property27 Voto_storico_inserito

diagram

- home_pv() – costruttore;
- visualizza_listino() – chiama la classe model che effettua la query sul database
per prelevare il listino del pv in questione che viene mostrato da una view;
- aggiungi_al_carrello() – aggiunge il prodotto selezionato al carrello;
- visualizza_carrello() – visualizza il contenuto del carrello allo stato attuale;
176
- modifica_carrello() – modifica il contenuto del carrello;

- effettua_ordine() – conferma il contenuto del carrello ed effettua l’ordine;
- profilo() – mostra i dati del pv;
- modifica_pv() – modifica i dati del pv;
- conferma_modifiche_pv() – chiede conferma dei dati modificati;
- esiste_username() – controlla che l’username modificato non sia già in uso;
- password_corretta() – controlla che la password e quella ripetuta coincidano;
- esiste_partita_iva() – controlla che la partita iva non sia già utilizzata da un altro
pv;
- aggiungi_ordine() – aggiunge l’ordine all’elenco degli ordini;
- visualizza_ordini_attivi() – visualizza tutti gli ordini del pv che attualmente sono
attivi (non evasi);
- filtra_elenco_ordine() – filtra l’elenco degli ordini attivi;
- visualizza_ordine() – mostra informazioni aggiuntive sull’ordine selezionato;
- vota_ordine() – permette di esprimere il giudizio sull’ordine selezionato;
- conferma_voto() – chiede conferma del voto espresso;
- visualizza_storico() – visualizza lo storico degli ordini propri del pv;
- filtra_visualizza_storico() – filtra lo storico dei propri ordini;
- vota_ordine_in_storico() – permette di esprimere un giudizio su un ordine evaso
presente nello storico;
- conferma_voto_in_storico() – chiede conferma del voto espresso per l’ordine
nello storico;
- filtra_elenco_prodotto() – filtra l’elenco dei prodotti nel listino;
- visualizza_prodotto() – mostra informazioni aggiuntive sul prodotto selezionato.
Class Menu_pv
diagram Menu_pv
owner menu
properties qualified name view::menu::Menu_pv
visibility public
leaf false
abstract false
active false
177

typedElements Class Home_pv Property Property15

diagram
Class Carrello
diagram Carrello
owner pv
properties qualified name view::pv::Carrello
visibility public
leaf false
abstract false
active false

diagram
Class Introduzione
diagram Introduzione
owner pv
properties qualified name view::pv::Introduzione
visibility public
leaf false
abstract false
active false

diagram
178
Class Modifica_pv
diagram Modifica_pv
owner pv
properties qualified name view::pv::Modifica_pv
visibility public
leaf false
abstract false
active false

diagram
Class Modifica_pv_riuscita
diagram Modifica_pv_riuscita
owner pv
properties qualified name view::pv::Modifica_pv_riuscita
visibility public
leaf false
abstract false
active false

diagram
Class Profilo
diagram Profilo
owner pv
properties qualified name view::pv::Profilo
visibility public
leaf false
abstract false
179
active false

diagram
Class Visualizza_proprio_listino
diagram Visualizza_proprio_listino
owner pv
properties qualified name view::pv::Visualizza_proprio_listino
visibility public
leaf false
abstract false
active false

diagram
Class Disponibilita_non_sufficiente
diagram Disponibilita_non_sufficiente
owner pv
properties qualified name view::pv::Disponibilita_non_sufficiente
visibility public
leaf false
abstract false
active false

diagram
180
Class Nuovo_ordine
diagram Nuovo_ordine
owner pv
properties qualified name view::pv::Nuovo_ordine
visibility public
leaf false
abstract false
active false

diagram
Le seguenti due classi ProtectionProxyOrdina e RealeOrdina servono per implementare

il design pattern proxy.
Class ProtectionProxyOrdina
diagram ProtectionProxyOrdina
Property1:RealeOrdina
procedi()
owner controller
properties qualified name controller::ProtectionProxyOrdina
visibility Public
leaf False
abstract False
active False
ownedMember procedi Property1
Property1 RealeOrdina
from Nuovo_ordine (Property1)
typedElements Class Nuovo_ordine Property Property1

diagram
181
Class RealeOrdina
diagram RealeOrdina
procedi()
owner controller
properties qualified name controller::RealeOrdina
visibility public
leaf false
abstract false
active false
ownedMember procedi
from ProtectionProxyOrdina (Property1)
typedElements Class ProtectionProxyOrdina Property Property1

diagram
Per la specifica delle classi che implementano il proxy si riveda la definizione di tale
pattern nella parte introduttiva del documento di progettazione.
Class Ordine_aggiunto
diagram Ordine_aggiunto
owner pv
properties qualified name view::pv::Ordine_aggiunto
visibility public
leaf false
abstract false
active false

diagram
182
owner pv
properties qualified name view::pv::Visualizza_elenco_ordini
visibility public
leaf false
abstract false
active false

diagram
Class Visualizza_elenco_storico
diagram Visualizza_elenco_storico
owner pv
properties qualified name view::pv::Visualizza_elenco_storico
visibility public
leaf false
abstract false
active false

diagram
Class Visualizza_ordine
diagram Visualizza_ordine
owner pv
properties qualified name view::pv::Visualizza_ordine
visibility public
leaf false
abstract false
183
active false

diagram
owner pv
properties qualified name view::pv::Visualizza_prodotto
visibility public
leaf false
abstract false
active false

diagram
Class Vota_ordine
diagram Vota_ordine
owner pv
properties qualified name view::pv::Vota_ordine
visibility public
leaf false
abstract false
active false

diagram
184
Class Voto_ordine_inserito
diagram Voto_ordine_inserito
owner pv
properties qualified name view::pv::Voto_ordine_inserito
visibility public
leaf false
abstract false
active false

diagram
Class Vota_ordine_storico
diagram Vota_ordine_storico
owner pv
properties qualified name view::pv::Vota_ordine_storico
visibility public
leaf false
abstract false
active false

diagram
Class Voto_storico_inserito
diagram Voto_storico_inserito
owner pv
properties qualified name view::pv::Voto_storico_inserito
visibility public
leaf false
abstract false
185
active false

diagram
Class Fornitore_model
diagram Fornitore_m odel
p_iva_f
nome
indirizzo
tel
email
fonitore_model()
required()
aggiungi_fonitore()
preleva_elenco_fornitore()
preleva_fornitore()
modifica_fornitore()
elimina_fornitore()
trova_p_iva_f()
owner model
properties qualified name model::Fornitore_model
visibility public
leaf false
abstract false
active false
ownedMember aggiungi_fonitore elimina_fornitore email fonitore_model indirizzo
modifica_fornitore nome p_iva_f preleva_elenco_fornitore preleva_fornitore required
tel trova_p_iva_f
Home_marketing (Property15)
Home_logistica (Property8)
Home_amministrazione (Property11)
Class Home_logistica Property Property8
Class Home_marketing Property Property15
diagram
186

- fornitore_model() – costruttore;
- aggiungi_fornitore() – aggiunge un nuovo fornitore al database;
- preleva_elenco_fornitore() – preleva l’elenco dei fornitori dal database;
- preleva_fornitore() – preleva un fornitore dal database;
- modifica_fornitore() – modifica un fornitore sul database;
- elimina_fornitore() – elimina un fornitore dal database;
- trova_p_iva_f() – ricerca una specifica partita iva nel database dei fornitori.
Class Listino_model
diagram Listino_m odel
nomeInsegna
sconto_listino
cod_prodotto
listino_model()
required()
aggiungi_listino()
aggiungi_prodotto_listino()
elimina_prodotto_listino()
preleva_elenco_listino()
elimina_listino()
preleva_listino()
preleva_prodotto_listino()
modifica_listino()
trova_listino()
modifica_prodotto_listino()
preleva_prodotto_listino_filtrato()
modifica_insegna_ordine_prod_listino()
owner model
properties qualified name model::Listino_model
visibility public
leaf false
abstract false
active false
ownedMember aggiungi_listino aggiungi_prodotto_listino cod_prodotto elimina_listino
elimina_prodotto_listino listino_model modifica_insegna_ordine_prod_listino
modifica_listino modifica_prodotto_listino nomeInsegna preleva_elenco_listino
preleva_listino preleva_prodotto_listino preleva_prodotto_listino_filtrato required
sconto_listino trova_listino
187
diagram

- listino_model() – costruttore;
- aggiungi_listino() – aggiunge un nuovo listino nel database;
- aggiungi_prodotto_listino() – aggiunge un nuovo prodotto ad un certo listino nel
data base;
- elimina_prodotto_listino() – elimina un certo prodotto da un certo listino nel
database;
- preleva_elenco_listino() – preleva l’elenco dei listini dal database;
- elimina_listino() – elimina un listino dal database;
- preleva_listino() – preleva un certo listino dal database;
- preleva_prodotto_listino() – preleva un certo prodotto da un certo listino dal
database;
- modifica_listino() – modifca un listino nel data base;
- trova_listino() – ricerca un certo listino sul data base;
- modifica_prodotto_listino() – modifica un certo prodotto in un certo listino nel
data base;
- preleva_prodotto_listino_filtrato() – filtra i prodotti prelevati da un certo listino;
- modifica_insegna_ordine_prod_listino() – modifica sul database l’insegna a cui
è associato un listino.
188
Class Ordine_model
diagram Ordine_m odel
codice_ordine
data_ordine
data_consegna
metodo_pagamento
stato_ordine
voto
p_iva_pv
codiceProdotto
nomeInsegna
quantita
prezzoVendita
ordine_model()
preleva_elenco_ordine()
preleva_ordine()
preleva_prodotti_ordinati()
modifica_stato_ordine()
elimina_ordine()
prezzo_ordine()
required()
aggiungi_ordine()
aggiungi_ordine_prodotto_listino()
modifica_voto_ordine()
numero_fattura_precedente()
modifica_piva_in_ordine()
numero_ordini_attivi_pv()
numero_ordini_con_prodotto()
owner model
properties qualified name model::Ordine_model
visibility public
leaf false
abstract false
active false
ownedMember aggiungi_ordine aggiungi_ordine_prodotto_listino codice_ordine codiceProdotto
data_consegna data_ordine elimina_ordine metodo_pagamento
modifica_piva_in_ordine modifica_stato_ordine modifica_voto_ordine nomeInsegna
numero_fattura_precedente numero_ordini_attivi_pv numero_ordini_con_prodotto
ordine_model p_iva_pv preleva_elenco_ordine preleva_ordine
preleva_prodotti_ordinati prezzo_ordine prezzoVendita quantita required
stato_ordine voto
Class Home_logistica Property Property10
189

diagram

- ordine_model() – costruttore;
- preleva_elenco_ordine() – preleva dal database l’elenco degli ordini attivi;
- preleva_ordine() – preleva un ordine attivo dal database;
- preleva_prodotti_ordinati() – preleva i prodotti presenti in un certo ordine attivo
dal database;
- modifica_stato_ordine() – modifica sul database lo stato di un ordine;
- elimina_ordine() – elimina un ordine dal database;
- prezzo_ordine() – preleva il costo complessivo di un ordine dal database;
- aggiungi_ordine() – aggiunge le informazioni di un ordine al database degli ordini
attivi;
- aggiungi_ordine_prodotto_listino() – aggiunge i prodotti relavitvi ad un dato
ordine precedentemente effettuato;
- modifica_voto_ordine() – modifica il voto di un ordine attivo nel database;
- numero_fattura_precedente() – preleva l’ultimo numero di fattura memorizzato
nel database; il numero della fattura relativa all’ordine attuale sarà pari a quello
precedente più uno;
- modifica_piva_in_ordine() – modifica il campo partita iva dell’ordine nel
database;
- numero_ordini_attivi_pv() – calcola il numero di ordini attivi per un certo pv;
- numero_ordini_con_prodotto() – calcola il numero di ordini con un certo prodotto
richiesto.
190
Class Prodotto_model
diagram Prodotto_m odel
cod_prodotto
nome
descrizione
provenienza
prezzo_unitario
disponibilita_residua
data_scadenza
p_iva_f
nomeReparto
prodotto_model()
required()
aggiungi_prodotto()
preleva_prodotto()
modifica_prodotto()
elimina_prodotto()
trova_cod_prodotto()
preleva_elenco_prodotto()
modifica_pivaf_in_prodotto()
numero_prodotti_fornitore()
controllo_disponibilita()
numero_prodotti_con_reparto()
owner model
properties qualified name model::Prodotto_model
visibility public
leaf false
abstract false
active false
ownedMember aggiungi_prodotto cod_prodotto controllo_disponibilita data_scadenza descrizione
disponibilita_residua elimina_prodotto modifica_pivaf_in_prodotto
modifica_prodotto nome nomeReparto numero_prodotti_con_reparto
numero_prodotti_fornitore p_iva_f preleva_elenco_prodotto preleva_prodotto
prezzo_unitario prodotto_model provenienza required trova_cod_prodotto
diagram
191
Spefica dei metodi:

- prodotto_model() – costruttore;
- aggiungi_prodotto() – aggiunge un nuovo prodotto nel database;
- preleva_prodotto() – preleva dal database un certo prodotto;
- modifica_prodotto() – modifica un certo prodotto nel database;
- elimina_prodotto() – elimina un certo prodotto dal database;
- trova_cod_prodotto() – ricerca un certo prodotto tramite il suo codice;
- preleva_elenco_prodotto() – preleva l’elenco dei prodotti;
- modifica_pivaf_in_prodotto() – modifica la partita iva del fornitore di un certo
prodotto;
- numero_prodotti_fornitore() – conta il numero dei prodotti proveniente da un
certo fornitore;
- controllo_disponibilita() – controlla la disponibilità di un prodotto;
- numero_prodotti_con_reparto() – conta il numero di prodotti in un certo reparto.
Class Reparto_model
diagram Reparto_m odel
nome_reparto
reparto_model()
required()
aggiungi_reparto()
preleva_elenco_reparto()
trova_reparto()
elimina_reparto()
owner model
properties qualified name model::Reparto_model
visibility public
leaf false
abstract false
active false
ownedMember aggiungi_reparto elimina_reparto nome_reparto preleva_elenco_reparto
reparto_model required trova_reparto
diagram
192

- reparto_model() – costruttore;
- aggiungi_reparto() – aggiunge al database un nuovo reparto;
- preleva_elenco_reparto() – preleva dal database l’elenco dei reparti;
- trova_reparto() – ricerca sul database un certo reparto;
- elimina_reparto() – elimina dal database un certo reparto.
Class Storico_model
diagram Storico_m odel
id_storico
p_iva_pv
data_ordine
data_consegna
importo_fattura
pagamento_usato
flag_stato_ordine
voto
storico_model()
aggiungi_tupla_storico()
preleva_elenco_storico()
preleva_ordine_storico()
modifica_piva_in_storico()
modifica_voto_ordine_storico()
owner model
properties qualified name model::Storico_model
visibility public
leaf false
abstract false
active false
ownedMember aggiungi_tupla_storico data_consegna data_ordine flag_stato_ordine id_storico
importo_fattura modifica_piva_in_storico modifica_voto_ordine_storico p_iva_pv
pagamento_usato preleva_elenco_storico preleva_ordine_storico storico_model
voto
diagram
193

- storico_model() – costruttore;
- aggiungi_tupla_storico() – aggiunge un nuovo ordine allo storico nel database;
- preleva_elenco_storico() – mostra tutto lo storico;
- preleva_ordine _storico() – preleva un certo ordine dallo storico;
- modifica_piva_in_storico() – modifica la partita iva di un certo ordine nello
storico;
- modifica_voto_ordine_storico() – modifica il voto di un certo ordine nello storico.
194
Class Utente_model
diagram Utente_m odel
username
pass
tipo
p_iva_pv
nome
indirizzo
tel
e_mail
orari_a
nome_i
utente_model()
required()
aggiungi_utente()
preleva_elenco_pv()
preleva_pv()
preleva_indirizzo_pv()
preleva_utente()
modifica_utente()
elimina_pv()
login()
trova_utente()
trova_partita_iva()
preleva_nome_insegna()
preleva_utente_da_user()
preleva_p_iva()
modifica_passw ord()
assegna_insegna_pv()
modifica_insegna_pv()
numero_pv_con_insegna()
owner model
properties qualified name model::Utente_model
visibility public
leaf false
abstract false
active false
ownedMember aggiungi_utente assegna_insegna_pv e_mail elimina_pv indirizzo login
modifica_insegna_pv modifica_password modifica_utente nome nome_i
numero_pv_con_insegna orari_a p_iva_pv pass preleva_elenco_pv
preleva_indirizzo_pv preleva_nome_insegna preleva_p_iva preleva_pv
preleva_utente preleva_utente_da_user required tel tipo trova_partita_iva
trova_utente username utente_model
Home_pv (Property7)
195
Class Home_amministrazione Property Property14

Shown on Class Diagram
diagram

- utente_model() – costruttore;
- aggiungi_utente() – aggiunge i dati di un nuovo utente al database. Si intende
l’utente generico, quindi i dati aggiunti potranno essere di un pv,
dell’amministrazione, del marketing o della logistica;
- preleva_elenco_pv() – preleva l’elenco dei pv dal database;
- preleva_utente() – preleva i dati di un certo utente dal database;
- modifica_utente() – modifica i dati di un certo utente nel database;
- elimina_pv() – elimina un pv dal database;
- login() – avvia la sessione;
- trova_utente() – ricerca un certo utente nel database;
- trova_partita_iva() – trova la partita iva di un pv nel database;
- preleva_nome_insegna() – preleva dal database i nomi delle insegne;
- preleva_utente_da_user() – preleva dal database l’utente a cui corrisponde
l’username fornito;
- preleva_p_iva() – preleva la partita iva di un pv dal database;
- modifica_password() – modifica la password di un utente;
- assegna_insegna_pv() – assegna un’insenga ad un pv;
- modifica_insegna_pv() – modifica l’insegna di appartenenza di un pv;
- numero_pv_con_insegna() – conta il numero di pv appartenenti ad una certa
insegna.
196
DIAGRAMMI DI MACCHINA A STATI
I diagrammi di macchina a stati consentono di enumerare gli stati in cui si può trovare un
sistema, un componente oppure una classe, indicando le transizioni tra uno stato ed un
altro.
Questa tipologia di diagramma non è altro che una riproposizione, attraverso una
notazione grafica unificata e standardizzata, di un qualcosa che si è usato fin dagli albori
dell’informatica: solo che non si usano gli ovali, che potrebbero confondersi con il
diagramma dei casi d’uso, ma rettangoli smussati uniti da frecce, con la punta aperta, che
rappresentano le transizioni, etichettate in maniera appropriata.
Nel diagramma è possibile identificare uno stato iniziale ed uno finale. Il primo costituisce il
punto di inizio della situazione descritta dal diagramma: non si tratta di un vero e proprio
stato ma piuttosto di uno pseudo stato ed eventualmente una condizione che lo innesca. Il
secondo, identifica la fine del ciclo di vita de sistema in oggetto: oltre questo stato ogni
elaborazione, a livello di sistema software osservato, termina e non è più possibile
eseguire una transizione in uno degli stati del diagramma.
Il passaggio da uno stato all’altro è definito da transizioni generate da un evento, detto
trigger, che scatena il cambiamento di stato. In genere la transazione è rappresentata
anche da una guardia che specifica la condizione che deve verificarsi affinchè, a seguito
del trigger, si scelga di andare in uno stato piuttosto che in un altro.
Nel caso specifico abbiamo scelto di rappresentare il diagramma di stato relativo al ciclo di
vita dell’ordine che parte dalla sua creazione (effettuata dal punto vendita che crea il
carrello ed effettua l’ordine), fino al momento in cui può essere visualizzato dalla logistica
con tutte le operazioni che ne possono seguire (modifica, filtraggio, annullamento, accesso
allo storico degli ordini).
197
CREAZIONE ORDINE
198
AGGIUNGI PRODOTTO
199
GESTIONE ORDINI
200
DIAGRAMMI DI SEQUENZA
Abbiamo già visto come illustrare le classi che compongono il nostro sistema software, in
particolare con il corrispondente diagramma, nonché come esprimere relazioni e vincoli tra
loro. Un punto di vista statico è però un modo limitato per studiare un sistema software, in
quanto non può mettere in evidenza il suo comportamento in un ambiente dinamico, che è
la normale modalità di funzionamento del software. UML mette a disposizione vari
diagrammi di interazione, il cui scopo è quello di evidenziare le modalità di dialogo tra i veri
componenti del software stesso: noi utilizzeremo i diagrammi di sequenza, che mostrano il
comportamento del sistema in uno specifico scenario operativo.
Gli elementi compositivi di tale diagramma sono principalmente i partecipanti, che
evidenziano gli elementi software (classi oppure oggetti) che intervengono in un dato
processo: vengono rappresentati come riquadri nella parte alta del diagramma da cui
discende una linea verticale tratteggiata che rappresenta la progressione temporale delle
operazioni; da questa linea, una serie di frecce collega i singoli partecipanti in modo
opportuno ed in specifici momenti del ciclo di vita del software, rappresentando messaggi
che i singoli partecipanti si scambiano tra loro. La successione di questi messaggi, che
possono essere messaggi da visualizzare, messaggi di pura comunicazione, oppure
invocazioni di metodi rappresenta una descrizione esaustiva di quelli che sono i passi da
seguire per portare a termine una determinata operazione, o meglio un determinato
scenario di funzionamento (in genere un diagramma di sequenza corrisponde allo
scenario di base del corrispondente caso d’uso e può inglobare anche lo scenario
alternativo).
201
USER
Visualizzare Home page
202
Registrare punto vendita
203
Recuperare password
204
Login
205
PUNTO VENDITA
Visualizzare proprio listino
206
Filtrare prodotti (pv)
207
Gestire carrello
208
Aggiungi al carrello
Effettuare ordine
209
Confermare ordine
210
Visualizzare profilo
211
Modificare profilo
212
Visualizzare storico propri ordini
213
Filtrare storico (pv)
Valutare ordine evaso
214
Visualizzare propri ordini
215
Filtrare ordini (pv)
216
Valutare ordine pervenuto
Visualizzare ordine (pv)
217
AMMINISTRAZIONE
Gestire fornitori
218
Filtrare fornitori
219
Modificare fornitore
220
Rimuovere fornitore
Aggiungere fornitore
221
Gestire punti vendita
222
Filtrare punti vendita
Visualizzare punto vendita
223
Modificare insegna
Rimuovere punto vendita
224
Visualizzare storico ordini
Filtrare storico
225
Visualizzare ordini (amministrazione)
Filtrare ordini (amministrazione)
226
MARKETING
Gestire listini
227
Filtrare listini
228
229
Aggiungere listino
230
Modificare listino
231
Rimuovere listino
232
Gestire prodotti
233
Filtrare prodotti
234
Modificare prodotto
235
Rimuovere prodotto
Aggiungere prodotto
236
Visualizzare fornitori (marketing)
Filtrare fornitori (marketing)
237
Visualizzare fornitore (marketing)
238
LOGISTICA
Visualizzare ordini
239
Filtrare ordini
240
Visualizzare ordine
241
242
Annullare stato ordine
243
Visualizzare fornitori (logistica)
Filtrare fornitori (logistica)
244
Visualizzare fornitore (logistica)
Visualizzare prodotti (logistica)
245
Filtrare prodotti (logistica)
Visualizzare prodotto (logistica)
246
Visualizzare listini (logistica)
Filtrare listini (logistica)
247
Visualizzare listino (logistica)
248
STRUTTURA INTERFACCIA
Nella figura qui riportata abbiamo pensato di riprodurre quella che sarà l’interfaccia, per
linee generali, che l’utente si troverà di fronte quando accederà al nostro portale web.
Nell’intestazione del sito scriveremo il nome della nostra azienda di grande distribuzione
sul web, con l’indicazione di uno slogan che la rappresenti.
Sulla sinistra troveranno posto un menù utente ed un’area di autenticazione. La prima
varia a seconda del tipo di utente che si collega, attraverso l’autenticazione, al nostro
portale, offrendo a ciascuno le funzionalità specifiche cui il particolare utente potrà
accedere e di cui potrà usufruire. La seconda, invece, consentirà al generico utente di
effettuare la registrazione, di recuperare la password qualora dimenticata, oppure di
effettuare la procedura di login a seconda delle proprie necessità. In particolare avremo
che, una volta loggato, l’utente visualizzerà, al posto del form di autenticazione, un
messaggio di benvenuto recante il proprio nome e la possibilità di effettuare logout.
249
Il footer (letteralmente “piè di pagina”) si usa per indicare la parte finale della pagina web
(ad esempio prodotta con un word processor). Di seguito un breve elenco di alcuni
elementi che generalmente si inseriscono in un footer:
• informazioni sull’autore/sviluppatore del sito;
• informazioni di contatto (email, telefono, …);
• informazioni sull’azienda (nome, p.iva, …);
• copyright/licenze di utilizzo;
• strumento utilizzato per la generazione della pagina (editor, cms, …);
• link alla pagina dei contatti, policy, mappa del sito, disclaimer o termini e condizioni:
• riferimenti alle validazioni della pagina (html, css, …);
Infine ecco che troveremo il contenuto principale che varierà a seconda della funzione
con la quale l’utente decide di interagire con il nostro sistema.
Un’ulteriore aspetto da rappresentare sarà il carrello: quando un punto vendita si
autentica ed accede alla visualizzazione del proprio listino, verrà fornita una ulteriore area,
oltre alle suddette, che conterrà informazioni sintetiche riguardo il carrello.
250
Bavaro - Conversano - Gaeta - Gallitelli - Saponieri Fase di Test
TEST DI SISTEMA
Le attività di verifica e di convalida vengono svolte alla fine di ogni stadio del processo di
sviluppo del software per individuare:
• malfunzionamenti;
• difetti;
• errori.
La verifica è una attività di controllo atta ad attestare che il prodotto sia conforme alle sue
specifiche (requisiti funzionali e non funzionali). Serve per capire se il prodotto è stato
“costruito” nel modo giusto (o si sta costruendo, nel caso di verifica alla fine di un
particolare stadio).
La validazione è il processo di valutazione dell’intero sistema o di un suo componente per
determinare se esso soddisfa le esigenze del cliente: serve per capire se si sta
“costruendo” il prodotto nel modo giusto.
Una descrizione degli elementi da verificare, la tempistica della verifica, i requisiti
hardware e software necessari alla verifica stessa vengono raccolti nel piano delle
verifiche (test plan).
Tutta la fase di test può essere considerata come l’insieme delle misure di controllo utili a
verificare e garantire la qualità del software.
In particolare possiamo affermare che la qualità del software altro non è se non l’insieme
delle caratteristiche che incidono sulla capacità del prodotto di soddisfare i requisiti espliciti
od impliciti (ISO/IEC 9126).
A determinare la qualità complessiva di un software concorrono tre diverse tipologie di
qualità (ISO/IEC 9126):
• interna (intrinseca). Esprime la misura in cui il codice software possiede una serie
di attributi, indipendentemente dall’ambiente di utilizzo e dall’utente;
• esterna. Esprime le prestazioni e le funzionalità del software;
• percepita (in uso). Esprime l’efficacia e l’efficienza con cui il software serve le
esigenze dell’utente, ed è correlata all’usabilità del prodotto.
499
Tutta la fase di test può essere suddivisa in diversi livelli:

1. test di unità;
2. test di integrazione;
3. test di sistema;
4. test di accettazione;
5. test di regressione.
Il test di unità consiste nel controllare separatamente le diverse parti di un modulo di un

programma, per rilevare gli errori e per migliorarle durante la codifica.
Nel test di integrazione i moduli sono integrati in sottosistemi più grandi i quali a loro
volta sono integrati in sistemi più complessi: tale livello di test consiste in un controllo delle
interfacce dei moduli integrati.
Il test di sistema consiste nel verificare che le specifiche di progetto di un programma
siano state soddisfatte e i miglioramenti apportati.
Nel test di accettazione il cliente verifica che le sue richieste siano state effettivamente
soddisfatte.
Nel test di regressione si verifica che versioni successive dello stesso programma non
introducano errori.
La verifica può essere sia statica che dinamica, invece la validazione è necessariamente
solo dinamica.
La verifica statica riguarda l’analisi di una rappresentazione statica del sistema per
individuare difetti.
La verifica e la validazione dinamica, invece, riguardano la fase di test con cui si

osserva il comportamento dinamico del sistema.
La fase di test verrà condotta stilando delle check list ed andandole poi a verificare.
500
ISPEZIONE DEL SOFTWARE
In questa fase del processo di verifica si analizzano e controllano le rappresentazioni

statiche del sistema: l’ispezione consente di scoprire quelli che sono i difetti veri e propri
ma non le modalità per correggerli.
I ruoli in un’ispezione sono:
• il moderatore, ossia il responsabile della conduzione dell’ispezione;

• il produttore, ossia il responsabile del prodotto da ispezionare;
• i revisori, ossia gli ispettori interessati e conoscitori del prodotto da ispezionare;
• il registratore, ossia colui che raccoglie i risultati più significativi dell’ispezione.
Tecniche di ispezione:
• Ad Hoc in cui l’ispettore decide autonomamente, dipendentemente dalla sua

esperienza e dal tipo di manufatto da ispezionare, i difetti da scoprire e le modalità
di ispezione da seguire;
• Check List in cui l’ispettore ha una check list di possibili difetti che devono essere
scoperti nel manufatto da ispezionare.
CHECK LIST DI ANALISI
CHECK LIST PER L’ANALISI DEI CASI D’USO
◊ Attori
1) Sono stati omessi degli attori necessari? Vale a dire, il sistema ha bisogno di
interagire con qualche altro utente, sistema, o dispositivo hardware descritto nei
requisiti?
Nel sistema sono presenti tutti e soli gli attori specificati nella commessa. Il sistema è stato
progettato per interagire direttamente solo con attori umani e quindi non ci sono problemi
relativi ad altri sistemi o dispositivi hardware che vi si interfacciano.
501
2) C’è una classe di utenti, un sistema esterno, o un dispositivo hardware descritto

nei requisiti che non interagisce in realtà con il sistema?
Come prima, non ci sono utenti o classi di utenti, sottosistemi, dispositivi hardware che
non partecipano al sistema.
◊ Comunicazioni tra attori e casi d’uso
3) Ci sono dei casi d’uso che non sono compatibili con la descrizione dell’attore?
No, i casi d’uso sono stati progettati appositamente in base alle operazioni che erano
richieste agli attori nella commessa.
4) Ci sono dei casi d’uso per i quali non è specificato nessun attore?
Come conseguenza dalla 3) tutti i casi d’uso sono utilizzati da almeno un attore.
◊ Descrizione dei casi d’uso
5) Sono chiare le condizioni di avvio di ciascun caso d’uso?
Il documento di analisi contiene specificatamente per ogni caso d’uso le condizioni che ne
determinano l’avvio.
6) E’ stata omessa qualche funzione che dovrebbe comparire in un caso d’ uso?
Tutte le possibilità richieste ai vari utenti nella commessa sono state racchiuse in un caso
d’uso.
7) Sono state omesse delle funzioni necessarie?
No.
8) La descrizione dettagliata di come un sistema interagisce con un attore è

consistente con i requisiti generali? I requisiti sono oscuri o inconsistenti circa
questa interazione?
502
E’ stata prestata particolare attenzione alla interazione tra attore e casi d’uso. Nel
documento di progetto il tutto è stato specificato attraverso i diagrammi degli stati.
CHECK LIST PER L’ANALISI ORIENTATA AGLI OGGETTI
◊ Classi di oggetti
1) Sono state specificate tutte e solo le classi rilevanti per il problema?
Sono state progettate ed implementate tutte le classi rilevanti, con in aggiunta altre per
garantire il soddisfacimento dei requisiti non funzionali. Inoltre sono state aggiunte delle
classi per garantire un buon livello di sicurezza (design pattern proxy).
Il progetto in generale è stato reso più leggibile andando a raggruppare le classi dal punto
di vista logico in delle componenti. Ciò assicura anche una facile manutenibilità.
2) Gli oggetti delle classi hanno identità distinte?
Si. Tutto ciò viene assicurato anche dall’uso del design pattern Singleton.
◊ Gerarchie di classificazione
3) Sono stati generalizzati gli stati e i comportamenti e riportate le classi

necessarie?
Si veda la 8) della check list dei casi d’uso e la 1) della check list degli oggetti.
503
CHECK LIST PER I REQUISITI
◊ Omissione
1) Le funzioni descritte sono sufficienti per soddisfare gli obiettivi del sistema?
Si. Inoltre sono state aggiunte altre funzionalità per garantire il soddisfacimento dei
requisiti non funzionali.
2) Sono presi in considerazione gli eventi non desiderati e sono specificate le

risposte richieste?
Sono stati considerati tutti i più comuni eventi non desiderati che possono scaturire da
errori dovuti ad inadempienza dell’utente: ad esempio gli errori nella compilazione di un
form. Sono stati approntati dei messaggi che consentano di guidare l’utente nella
correzione degli errori sia dal lato del fornitore del servizio che da quello del cliente.
3) Il sistema può essere ispezionato per mostrare che soddisfa i requisiti di

prestazione?
Il sistema è stato suddiviso in componenti che ne garantiscono una facile ispezione.
4) Sono specificati i requisiti non funzionali?
Nel documento di analisi sono specificati tutti i requisiti non funzionali.
◊ Informazione ambigua
5) Un requisito ammette più di una interpretazione?
Qualora un requisito ammetta più di una interpretazione, il caso d’uso corrispondente

consentirà la scelta tra diversi scenari alternativi in modo da contemplare la maggior parte
delle possibili interpretazioni.
504
◊ Inconsistenza
6) Ci sono requisiti specifici in conflitto tra loro (conflitti logici, temporali, di

formato, ecc.)?
Non c’è conflitto tra i requisiti. Grazie all’implementazione delle transazioni, inoltre, non
possono esserci nemmeno conflitti dovuti all’inconsistenza dei dati.
◊ Fatto incorretto
7) Ci sono requisiti specifici che contraddicono gli obiettivi, le definizioni e la

descrizione generale del sistema?
No, i requisiti sono stati considerati appositamente per soddisfare gli obiettivi della
commessa.
CHECK LIST DI PROGETTO
1) Il progetto è tracciabile con le specifiche?
Le specifiche sono tutte rispettate, il progetto dipende da esse.
2) È prevista la gestione degli errori?
È stata prevista una vasta gamma di errori dovuti sia all’utente che al sistema stesso. Per
garantirne l’immunità sono state progettate delle classi e/o delle operazioni che
permettano di evitare problemi di questo tipo oppure di correggerli.
3) I servizi sono adeguatamente localizzati in componenti software?
Il sistema è stato suddiviso in componenti usando il pattern architetturale MVC.
4) Devono essere apportate modifiche al progetto in funzione del linguaggio di

programmazione o dell’ambiente operativo?
505
No, il sistema è stato progettato fin dall’inizio tenendo presente il pattern architetturale da
usare (MVC) il framework (CodeIgniter) e quindi anche il linguaggio di programmazione.
5) È descritta l’organizzazione in sottosistemi?
Il sistema è un blocco unico. Vanno in esecuzione solo alcune sue parti a seconda del tipo
di utente che si è autenticato.
6) L’interazione con l’utente è gestita da componenti specifiche?
L’interazione è gestita da una serie di classi view che mostrano all’utente le operazioni che
può effettuare: è garantita la facilità di utilizzo anche per utenti poco esperti da punto di
vista informatico.
7) Le entità concettuali sono gestite da un apposito DB Interface?
Dato il linguaggio di programmazione (php) ed il web server (Apache) scelti il sistema è

totalmente portabile. Quindi l’interfaccia al data base può essere generica: ad esempio
ODBC di Microsoft oppure la DB interface di Oracle.
8) Tutte le tabelle sono in terza forma normale?
Si, tutte le tabelle sono espresse in terza forma normale per garantire quelli che sono i
requisiti di consistenza dell’informazione contenuta in esse e ottimizzare la ricerca che
avviene in tabelle non ridondanti di informazioni.
9) Il numero di campi per ogni tabella è adeguato?
Si, il numero dei campi per ogni singola tabella è conforme con quanto stabilito in sede di
analisi e progettazione.
10) Tutte le decisioni di progetto sono giustificate adeguatamente?
Ogni scelta progettuale è stata attentamente ponderata al fine di garantire un software

funzionante, nel rispetto delle specifiche, portabile ed user friendly.
506
11) Contiene le classi utili per la restituzione all’esterno dei dati gestiti dal sistema?
Le classi view permettono di mostrare all’utente gli output richiesti. Con una semplice
estensione del sistema è facile portare questi dati su dispositivi esterni al sistema quali, ad
esempio, gli smart phone di ultima generazione attraverso delle e-mail.
12) Contiene le classi utili per la comunicazione di messaggi all’utente?
Si. Il tutto è gestito dalle classi view nel rispetto del pattern architetturale MVC.
13) Tutti gli oggetti riconosciuti dal dominio applicativo sono adeguatamente
descritti in classi specifiche?
Il modello del dominio utilizzato è molto ampio e garantisce una buona aderenza al
mercato reale. Le classi e gli oggetti utilizzati sono esaustivi al fine di implementare
correttamente questo modello.
14) Contiene le classi che implementano i servizi generali utilizzati dalle altre classi
del sistema?
Abbiamo preferito non raggruppare le funzioni di utilità in un’unica classe. Tali funzioni
sono state ridondate ed incapsulate a seconda dell’utente che le chiami. In questo modo è
facile estendere il sistema aggiungendo o modificando le possibilità date all’utente sia nel
senso dell’implementazione sia dal punto di vista logico.
Al fine di garantire leggibilità ed interpretabilità, il documento:
• è sotto il controllo di versione e di configurazione (numero di versione, data di

emissione, autore);
• include un indice;
• include un capitolo dedicato all’architettura del sistema;
• include un capitolo dedicato all’architettura software;
• include un capitolo dedicato alla descrizione delle componenti;
• include un capitolo dedicato alla descrizione delle strutture dati.
L’architettura di sistema identifica l’ambiente fisico di esecuzione.

L’architettura software include diagrammi che mostrano l’architettura con un livello di
507
astrazione adeguato e nel rispetto dello standard UML 2.0.

Sono definiti tutti e soli i componenti esistenti.
Le interfacce di comunicazione sono ampiamente descritte in modo da rendere il sistema
facilmente manutenibile ed estendibile.
UTILIZZATORI DEL SISTEMA
Viene definito un modello degli Utenti a 6 categorie.

L’utente che appartiene alla categoria 1 è quello che più di tutti conosce il dominio
applicativo ma è anche quello meno esperto di applicazioni web e che ha meno familiarità
con il sistema. L’obiettivo è di testare il sistema in tutte le sue funzionalità, a cui solo la
categoria 1 ha accesso, utilizzando un valutatore non esperto dal punto di vista del
software.
Gli utenti che appartengono alle categorie 2, 3, 4 e 5 hanno una conoscenza specifica del
dominio relativa al proprio ruolo ma con una differente familiarità con i sistemi informatici.
L’utente che appartiene all’ultima categoria risulta poco esperto del dominio applicativo ma
con una maggiore conoscenza delle applicazioni web.
Content
Funzionalità Front-end
Management
Le funzioni disponibili sono usufruibili senza lasciare il sito 3 5
Le funzioni implementate sono usufruibili senza il download 3 2

di plug-in
Il sito è visualizzabile con tutti i principali browsers 3 4
Tutte le funzionalità sono chiaramente rappresentate 3 5
Tutte le funzionalità sono raggruppate logicamente 2 5
Tutte le funzionalità sono facili da utilizzare 4 4
Tutte le funzionalità del Portale sono utili 4 5
Tutte le funzionalità implementate rispettano le specifiche 3 5

dei requisiti
508
Content
Chiarezza visiva Front-end
Management
Il layout è chiaro e gli spazi sono adeguati tra box, immagini 3 4

e parti di testo
La grafica è coerente con obiettivi e target del sito 4 4
Visibilità del testo sugli sfondi 2 4
Immagini e animazioni inutili sono evitate 2 3
Le pagine non sono troppo lunghe 3 3
Content
Controllo Front-end
Management
L’utente può cancellare tute le operazioni 2 5
Nel caso di implementazione di funzioni come esecuzione 2 5

guidata di diversi passi, l’utente può cancellare l’operazione
di ogni singolo passo
C’è una chiara opzione di uscita in ogni pagina 2 4
Il peso delle pagine è adeguato 3 2
Content
Correzione e Prevenzione degli errori Front-end
Management
Non vengono proposti messaggi di errore inutili 3 4
I messaggi di errore sono in formato testo 4 4
I messaggi di errore illustrano le azioni da compiere 2 4
I messaggi di errore forniscono una chiara opzione di uscita 2 3
I messaggi di errore forniscono la possibilità di ottenere 3 3

assistenza
509
CONTROLLI DI ISPEZIONE DEL CODICE
◊ Errori di riferimento ai dati
1) Ci si riferisce ad una variabile non inizializzata?
Il linguaggio di programmazione scelto (php) non necessita né l’inizializzazione e né la

dichiarazione delle variabili che vengono usate.
2) Una variabile ha tipo diverso da quello previsto dal programma?
Il linguaggio di programmazione scelto (php) non necessita la specifica del tipo di dato di
una variabile: il compilatore (che poi è il browser), infatti, riconosce autonomamente il tipo
di dato con cui sta lavorando.
3) Esistono variabili con nome simile (pratica pericolosa)?
I nomi delle variabili sono ben distinti tra loro in maniera tale da evitare che si possano
verificare errori dovuti alla confusione tra i nomi delle variabili processate.
◊ Errori di calcolo
4) I calcoli coinvolgono tipi inconsistenti (ad es., stringhe e interi)?
Anche se il linguaggio scelto non necessita la specifica del tipo di dato di una variabile, è
stata posta particolare attenzione a tutte quelle operazioni che coinvolgano più variabili di
tipo differente: in questo modo sono stati evitati tutti quegli errori tipici dovuti ad operazioni
tra variabili di tipo diverso.
5) Esistono dei calcoli che coinvolgono tipi compatibili ma di precisione differente?
Gli unici calcoli che si effettuano sono delle somme di prezzi di prodotti. Tutti questi prezzi
sono modellati con la stessa precisione.
510
6) È possibile una condizione di overflow (ad esempio nei calcoli intermedi, o nelle
conversioni)?
Non è stata rilevata nessuna anomalia di questo genere, anche perché i calcoli veri e
propri sono pochi e limitati a somme aritmetiche tra numeri che, al momento del loro
inserimento, sono rigidamente controllati.
7) Il valore di una variabile esce dall’intervallo ragionevole?
Come dalla 6) tutti i valori sono rigidamente controllati nel momento nell’inserimento nel
data base. Quindi si conosce un ordine di grandezza indicativo dei risultati delle somme.
◊ Errori di confronto
8) Ci sono confronti fra variabili di diverso tipo?
No, tutti i confronti avvengono tra variabili dello stesso tipo. A ciò si è posta particolare
attenzione in fase di implementazione dato che il linguaggio di programmazione scelto non
prevede la specifica del tipo di dato di una variabile.
◊ Errori di controllo
9) I cicli terminano?
Tutti i cicli vengono a termine con un output positivo o negativo. I possibili scenari sono
stati modellati in fase di analisi, quindi è noto il motivo per cui un ciclo si arresta prima del
normale.
10) Le funzioni/procedure terminano?
Tutte le funzioni e procedure usate sono state ampiamente analizzate in fase di

progettazione ed implementate di conseguenza. Non ci sono problemi dovuti ad arresti
critici o a loop indefiniti.
511
11) È possibile che, a causa delle condizioni di ingresso, un ciclo non venga mai
eseguito?
Ciò è possibile. Tutte le situazioni possibili sono state ampiamente analizzate nelle fasi di
analisi e progettazione. Per assurdo se nessun punto vendita richiede mai una ricerca di
un prodotto, il ciclo che effettua tale ricerca sul data base non verrà mai eseguito.
12) Le condizioni di uscita dal ciclo sono corrette?
Si. Eventuali scenari alternativi per un dato ciclo sono stati analizzati nelle precedenti fasi
del progetto.
13) Esistono delle decisioni non esaustive (ad es., in un’istruzione switch)?
No, tutto il progetto è stato condotto per evitare situazioni poco chiare o ambigue.
◊ Errori di interfaccia
14) Il numero e l’ordine dei parametri attuali corrisponde a quello dei parametri
formali?
Si. Inoltre i parametri vengono passati tramite post http quindi un errore su tali parametri
non consentirebbe una corretta esecuzione del codice e visualizzazione della pagina html.
15) Le assunzioni sulla conversione di tipo fra parametri attuali e formali sono
corrette?
Come detto in precedenza con il php non si lavora specificando il tipo di dato
manualmente. Ciò potrebbe essere fonte di errore. E’ stata posta particolare attenzione a
tutte le chiamate per garantire la consistenza tra parametri attuali e formali.
16) La modalità di passaggio dei parametri (valore, riferimento) è corretta?
Il passaggio dei dati avviene tramite post http. Il passaggio è stato ampiamente testato già
in fase di implementazione e poi in fase di test.
512
◊ Errori di I/O
17) Input imprevisti possono causare corruzione?
Ciò non è possibile dato che i dati vengono rigidamente controllati in fase di inserimento
del data base.
◊ Altro
18) Esistono delle variabili dichiarate ma che non vengono usate?
Come detto più volte in precedenza, in php, le variabili non vengono dichiarate.
19) Il programma è sufficientemente robusto? Controlla la validità dell’input?
Il controllo è molto rigido ed è svolto dai metodi delle classi che effettuano le insert nel
data base.
513

Progetto Di Ingegneria Del Software

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Progetto Di Ingegneria Del Software

Diunggah oleh

Hak Cipta:

Format Tersedia

POLITECNICO DI BARI

PROGETTO DI INGEGNERIA DEL SOFTWARE

GESTIONE DI UNA RETE DI VENDITA PER LA GRANDE

Anno accademico 2009-2010

Capitolo 1. Fase preliminare

Capitolo 5. Test di sistema

gestione dell’anagrafica dei punti vendita;

gestione dell’anagrafica dei fornitori;

gestione dei prodotti;

tracciabilità degli ordini: possibilità di vedere lo stato dell’ordine;

possibilità da parte dell’azienda distributrice di monitorare e aggiornare lo stato

raccolta degli ordini evasi in uno storico;

Inoltre, il sistema software deve rispettare la seguente specifiche:

L'azienda distributrice ha il compito di registrare i prodotti che intende immettere sul

Il sistema da implementare ha costi e tempi prevedibili, con conseguente riduzione dei

Il sistema software sarà dotato di un’interfaccia grafica di tipo user-friendly permettendo di

Il progetto sarà realizzato in maniera tale da garantire il rispetto di principi fondamentali

Tale progetto si articola in cinque fasi fondamentali:

Il team di sviluppo posto alla realizzazione di tale sistema software è costituito da un

La durata complessiva dell’intero progetto è di 111 giorni lavorativi.

FUNZIONALITÀ GENERALI DEL SISTEMA

1. GESTIONE PUNTO VENDITA

6. VISUALIZZAZIONE STATO ORDINE

8. AGGIORNAMENTO STATO ORDINE

9. GESTIONE STORICO ORDINI

10. GESTIONE ACCESSI

- punto vendita (pv);

Tale procedura consiste nell’inserimento di una username e della relativa password,

Responsabile dei punti vendita e dei fornitori (amministrazione): corrisponde

Addetto ai prodotti e ai listini (marketing): si occupa dell’inserimento e della gestione

• Responsabile dei punti vendita e dei fornitori (amministrazione);

L’amministrazione corrisponde all’utilizzatore del sistema che si occupa della gestione

SPECIFICHE DEI REQUISITI

1. GESTIONE PUNTO VENDITA

Identificativo 1. GESTIONE PUNTO VENDITA

1.2) Il sistema, nel momento dell’aggiunta o della cancellazione di un

1.3) Il sistema dovrà essere in grado di consentire al punto vendita (pv) la

Identificativo 2. GESTIONE FORNITORE

2.2) Il sistema dovrà permettere di visualizzare l’elenco di tutti i fornitori e i

2.3) Un fornitore potrà essere eliminato soltanto se non esistono prodotti

Identificativo 3. GESTIONE PRODOTTO

3.2) Il sistema dovrà permettere di visualizzare l’elenco di tutti i prodotti

3.3) Il sistema dovrà permettere di effettuare una visualizzazione selettiva

3.4) Il campo genere/reparto dovrà essere determinato mediante un

categorie di prodotto oppure diminuito nel caso in cui un determinato

3.5) Un prodotto non può essere eliminato se ci sono ordini ancora in

3.7) Al momento della registrazione di un prodotto bisognerà definire il campo

La parte interessata direttamente in questo requisito sarà l’addetto ai prodotti e ai listini

Identificativo 4. GESTIONE LISTINO

4.2) La creazione, modifica e cancellazione di un listino sarà effettuabile

4.3) L’addetto alla gestione degli ordini (logistica) potrà visualizzare i

4.5) Ogni punto vendita avrà la possibilità di consultare il listino relativo

4.6) Per ogni prodotto sarà possibile visualizzare il prezzo, le quantità

4.7) I punti vendita avranno la possibilità di effettuare una ricerca

4.8) Un listino non potrà essere eliminato se esiste almeno un punto

La parte interessata direttamente in questo requisito sarà l’addetto ai prodotti e ai listini

Identificativo 5. GESTIONE ORDINE

5.3) La quantità da aggiungere al carrello non potrà essere superiore alla

5.4) Il punto vendita potrà sempre modificare il proprio carrello tramite

5.5) Il sistema dovrà fornire la possibilità di scegliere tra i diversi metodi di

5.6) Il sistema dovrà fornire un riepilogo dell’ordine richiesto, contenente

5.7) Il sistema dovrà garantire l’avvenuta conferma di creazione

6. VISUALIZZAZIONE STATO ORDINE