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

I

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

II

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

III

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

IV

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

V

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

VI

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

Bavaro - Conversano - Gaeta - Gallitelli - Saponieri Fase preliminare

1

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.


2

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.


3

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.


4

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.


5

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.


6

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.


7

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.


8

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

Bavaro - Conversano - Gaeta - Gallitelli - Saponieri Fase di analisi

9

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


10

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.


11

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

sistema

1.1) Il sistema dovrà permettere la visualizzazione e la cancellazione dei

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)


12

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.


13

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.


14

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

sistema

2.1) Il sistema dovrà permettere l’inserimento, la modifica, la

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)


15



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


16

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

sistema

3.1) Il sistema dovrà permettere l’inserimento, la modifica, la

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


17

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;


18

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


19

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

sistema

4.1) Il sistema dovrà permettere la creazione, la modifica, la

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)


20

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.


21

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

sistema

5.1) L’ordine potrà essere effettuato solo da parte dei punti vendita

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)


22

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


23

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.


24

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

sistema

6.1) Lo stato dell’ordine potrà essere impiegato per tener traccia del

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)


25

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


26

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.


27

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

sistema

7.1) Il sistema dovrà permettere ad ogni punto vendita, di poter accedere

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)


28

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.


29

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

sistema

8.1) Solo l’addetto alla gestione degli ordini (logistica) avrà la possibilità di

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


30

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


31

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.


32

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

sistema

9.1) Il responsabile dei punti vendita e dei fornitori (amministrazione)

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)


33


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.


34

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

sistema

10.1) La richiesta di registrazione al sistema da parte dell’utente generico

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.



35

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.


36

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.

ID

1 2 3 4 5 6 7 8 9 10

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


37

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


38

DIAGRAMMA DEI CASI D’USO


39

DESCRIZIONE DEI CASI D’USO

USER


40

Visualizzare home page

Attore principale Utente generico (user).

Descrizione

L’utente generico ha la possibilità di visualizzare la home page del

nostro portale web, in maniera tale da poter comprendere che tipo di

servizi vengono ad essere offerti da esso.

Precondizioni È necessario digitare il corretto indirizzo web relativo al nostro

portale per potervi accedere e visualizzare la relativa home page.

Trigger Il caso d’uso viene ad essere attivato automaticamente nel momento

in cui si accede alla home page del nostro sito web.

Scenario di base 1. Viene visualizzata la home page del nostro portale web.

Esteso dal caso

d’uso

1. Registrare punto vendita

2. Login

3. Recuperare password

Extend point

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

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.


41

Registrare punto vendita


Descrizione

Tramite una ben precisa procedura prevista dal sistema, l’utente

generico (user) può procedere alla relativa registrazione presso il

nostro portale web.

Precondizioni

L’utente generico deve aver precedentemente eseguito il caso d’uso

“Visualizzare home page”.

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.

Trigger Il caso d’uso si attiva nel momento in cui l’utente generico decide di

cliccare sull’apposito pulsante “Registrati”.

Scenario di base

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

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.

Scenario

alternativo di

insuccesso

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,

viene visualizzato un messaggio di errore e richiesta

l’immissione di una nuova password.

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,


42

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


Descrizione L’utente generico si autentica tramite username e password per

poter accedere alla propria area riservata.

Precondizioni



L’utente deve essere già registrato al sito (caso d’uso “Registrare

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

Scenario di base

1. Vengono inseriti username e password negli appositi riquadri.

2. Dopo aver compilato i campi sopra citati, l’utente generico (user)

preme il pulsante di conferma “Login”.

3. L’utente accede alla propria area riservata.

Scenario

alternativo di

insuccesso

3.1. Se l’username e/o la password sono errati, viene visualizzato un

messaggio di errore e richiesta una nuova immissione dei dati.

3.2. Se i dati inseriti non corrispondono a nessuna delle tipologie di

utente previste dal nostro sistema, viene fornito un messaggio di

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


43

Recuperare password


Descrizione

Grazie ad una ben precisa procedura prevista dal sistema che

consiste nell’invio di un messaggio di posta elettronica, l’utente

generico ha la possibilità di recuperare la propria password, qualora

smarrita o dimenticata.

Precondizioni



L’utente che usufruisce di tale funzionalità deve essersi già

precedentemente registrato, e deve essere in possesso dei dati

impiegati nella compilazione del modulo di registrazione previsto dal

sistema.

Trigger Il caso d’uso si attiva nel momento in cui l’utente generico decide di

cliccare sull’apposito link “Recupera password”.

Scenario di base

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.

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.

Scenario

alternativo di

insuccesso

2.1. Se l’utente generico compie un errore nella digitazione

dell’indirizzo e-mail e/o dello username, viene visualizzato un

messaggio di errore e richiesta una nuova immissione.

5.1. Il sistema non riesce a trovare nessun riscontro tra username ed

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.


44

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.


45

PUNTO VENDITA


46

Visualizzare proprio listino

Attore principale Punto vendita (pv).

Descrizione Il punto vendita accede all’area del portale che mostra il listino dei

prodotti cui può accedere, con i relativi prezzi di vendita.

Precondizioni L’utente deve essersi autenticato come punto vendita (caso d’uso

“Login”).

Trigger Il caso d’uso si attiva cliccando sull’apposito pulsante “Listino

prodotti”.

Scenario di base

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.

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

Scenario

alternativo di

insuccesso

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.

1.2. Se il punto vendita non è stato associato ad alcuna insegna, il

sistema lo informerà mostrando un messaggio di errore. In

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.


47

Visualizzare proprio listino <<include>> Gestire carrello


Descrizione

Dopo aver visualizzato il listino dei prodotti relativi all’insegna di

appartenenza, il punto vendita seleziona i prodotti di interesse

indicandone le relative quantità, e li aggiunge al carrello per poter poi

eventualmente procedere con la conferma dell’ordine.

Precondizioni

L’utente deve essersi autenticato come punto vendita (caso d’uso

“Login”), e deve essere disponibile un listino prodotti relativo alla

propria insegna.

Il punto vendita deve aver precedentemente eseguito il caso d’uso

“Visualizzare proprio listino”.

Trigger

Il caso d’uso “Gestire carrello” si attiva automaticamente al momento

della visualizzazione del listino dei prodotti in quanto è incluso nel

caso d’uso “Visualizzare listino”.

Scenario di base

1. Visualizzando il listino, il punto vendita ha la possibilità di

selezionare i prodotti di interesse indicandone le relative quantità

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.

Scenario

alternativo di

insuccesso

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

notifica dell’errore.

1.2. Se il campo quantità relativo anche ad uno solo dei prodotti

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

d’uso Ordinare prodotto

Extend point

Ordina prodotto: cliccando sul pulsante “Ordina” si avvia la

procedura di attivazione dell’ordine inerente tutti i prodotti presenti

nel carrello. Si procede con il relativo caso d’uso.


48

Ordinare prodotto


Descrizione Il punto vendita procede con l’ordinazione dei prodotti e delle relative

quantità attualmente presenti nel carrello.

Precondizioni


“Login”), e deve essere disponibile un listino prodotti relativo alla

propria insegna.

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.

Trigger Il caso d’uso si attiva cliccando sul pulsante “Ordina” presente

all’interno della pagina relativa alla gestione del carrello.

Scenario di base

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.

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.

Scenario

alternativo di

insuccesso

4.1. Se il punto vendita non conferma l’ordine, gli è consentito di

poter tornare alla gestione del carrello.

5.1. Se la password inserita è errata, viene visualizzato un

messaggio di errore e richiesto il reinserimento della stessa.

L’ordine resta quindi in sospeso fino a quando non viene inserita

la password corretta.


49

Visualizzare profilo


Descrizione

Il punto vendita ha la possibilità di visualizzare una schermata

riassuntiva relativa ai propri dati (utilizzati durante la fase di

registrazione al nostro portale web).


“Login”).

Trigger Il caso d’uso si attiva selezionando la voce “Visualizza profilo”.

Scenario di base

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,

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

d’uso Modificare profilo

Extend point

Modifica profilo: cliccando sul pulsante “Modifica” il sistema consente

all’utente di poter accedere alla sezione di modifica dei propri dati in

maniera tale da potervi applicare determinati cambiamenti qualora

necessario. Si procede con il relativo caso d’uso.


50

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

Trigger Il caso d’uso si attiva cliccando sull’apposito pulsante “Modifica

profilo”.

Scenario di base

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

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

Scenario

alternativo di

insuccesso

2.1. Se i nuovi dati inseriti risultano essere errati, il sistema provvede

a darne notifica mediante un messaggio di errore indicando il

tipo di problema e richiedendo una nuova immissione dei dati in

maniera corretta.

3.1. Se il punto vendita non conferma le modifiche apportate al

proprio profilo, tali modifiche andranno perse mantenendo i dati

originari.


51

Visualizzare storico propri ordini


Descrizione

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

effettivamente archiviati come conclusi. Per tale motivo riguarda solo

gli ordini che si trovino nello stato “evaso”.


“Login”).

Trigger Il caso d’uso si attiva cliccando sull’apposito pulsante “Storico degli

ordini”.

Scenario di base

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.



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


Scenario

alternativo di

insuccesso

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

oppure che nessuno degli ordini effettuati dal punto vendita si

trova nello stato “evaso”.




non esiste nessun ordine che rispetti i dati inseriti.

Esteso dal caso

d’uso Valutare ordine

Extend point Valuta ordine: una volta selezionato l’ordine che si desidera valutare,


52

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


Descrizione

Il punto vendita ha la possibilità di visualizzare una lista contenente

tutti i propri ordini attivi, ossia tutti gli ordini che si trovano nello stato

“in preparazione” o nello stato “pervenuto”.


“Login”).

Trigger Il caso d’uso si attiva cliccando sull’apposito pulsante “Ordini attivi”.

Scenario di base

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

propri ordini sulla base di determinati campi tra quelli a

disposizione.



passo precedente.


relativi all’ordine in questione.

Scenario

alternativo di

insuccesso

1.1. Qualora la tabella relativa agli ordini attivi non contenga alcuna

tupla, il sistema visualizza un messaggio di notifica con il quale

si indica che in quel dato istante il punto vendita non presenta

alcun ordine attivo.



53




Esteso dal caso

d’uso Valutare ordine

Extend point

Valutare ordine: una volta selezionato l’ordine che si desidera

valutare, 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.


54

Valutare ordine


Descrizione

Il punto vendita ha la possibilità di esprimere un giudizio sull’ordine,

o meglio sul servizio ricevuto dall’azienda distributrice attraverso

l’ordine stesso. La valutazione consta in un numero compreso tra 1 e

4, utilizzato come indice di gradimento del servizio offerto.

Precondizioni

La valutazione dell’ordine può essere effettuata se e solo se l’ordine

in questione esiste e si trova nello stato “pervenuto” o nello stato

“evaso”.

Trigger

Quando un ordine si trova nello stato “pervenuto” o nello stato

“evaso”, il sistema consente al punto vendita di poter effettuare una

valutazione su di esso tramite apposita sezione di valutazione

dell’ordine.

Scenario di base

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

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

alternativo di

insuccesso

2.1. Se la valutazione dell’ordine non viene confermata, andrà persa

e sarà possibile effettuarla nuovamente in seguito.


55

AMMINISTRAZIONE


56

Gestire fornitori

Attore principale Responsabile dei punti vendita e dei fornitori (amministrazione).

Descrizione

L’amministrazione gestisce tutti i fornitori dell’azienda distributrice.

Pertanto ha la possibilità di visualizzare, aggiungere, modificare e

rimuovere i dati relativi a tutti i fornitori con i quali intrattiene rapporti

di tipo commerciale. (*)

Precondizioni L’utente deve essersi loggato come amministrazione (caso d’uso

“Login”).

Trigger Il caso d’uso si attiva selezionando l’apposita voce dal menù relativo

all’amministrazione.

Scenario di base

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.



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.

Scenario

alternativo di

insuccesso

1.1. Se la tabella dei fornitori non contiene alcuna tupla, viene

visualizzato un messaggio con il quale si indica che nessun

fornitore è presente in archivio.




non esiste nessun fornitore che rispetti i dati inseriti.

Esteso dal caso

d’uso

1. Visualizzare fornitore

2. Aggiungere fornitore

3. Modificare fornitore

4. Rimuovere fornitore


57

Extend point

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.

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


Descrizione

L’amministrazione ha la possibilità di visualizzare i dati caratteristici

relativi ad ogni fornitore con il quale l’azienda distributrice intrattiene

rapporti di tipo commerciale.

Precondizioni

L’amministrazione deve aver precedentemente eseguito il caso

d’uso “Gestire fornitori” e selezionato il fornitore che si intende

visualizzare.

Trigger

Il caso d’uso si attiva selezionando la voce “Visualizza” presente

nell’apposito menù di gestione dei fornitori (caso d’uso “Gestire

fornitori”).

Scenario di base

1. A partire dalla visualizzazione dell’elenco di tutti i fornitori,

l’amministrazione visualizza i dati caratteristici relativi al fornitore

selezionato.


relativi al fornitore in questione.


58

Aggiungere fornitore


Descrizione L’amministrazione provvede ad aggiungere un nuovo fornitore nel

database, inserendo tutti i dati relativi ad esso.

Precondizioni L’amministrazione deve aver precedentemente eseguito il caso

d’uso “Gestire fornitori”.

Trigger

Il caso d’uso si attiva selezionando la voce “Aggiungi” presente


fornitori”).

Scenario di base

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

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.

Scenario

alternativo di

insuccesso

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.

1.2. Se i nuovi dati inseriti fanno riferimento ad un fornitore già

presente all’interno del database, il sistema notifica tale

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.


59

Modificare fornitore


Descrizione L’amministrazione ha la possibilità di modificare i dati relativi ad un

determinato fornitore presente all’interno del database.

Precondizioni



modificare.

Trigger

Il caso d’uso si attiva selezionando la voce “Modifica” presente


fornitori”).

Scenario di base

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



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.

Scenario

alternativo di

insuccesso



un messaggio di errore e invita l’amministrazione ad apportare

le opportune modifiche.

2.2. Se i nuovi dati inseriti fanno riferimento ad un fornitore già


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.


60

Rimuovere fornitore


Descrizione L’amministrazione rimuove dal database tutti i dati relativi ad un

determinato fornitore.

Precondizioni



eliminare dal database.

Trigger

Il caso d’uso si attiva selezionando la voce “Rimuovi” presente


fornitori”).

Scenario di base

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

“Conferma eliminazione”.


riguardo l’avvenuta eliminazione di tutti i dati relativi al fornitore in

esame.

Scenario

alternativo di

insuccesso

2.1. Se l’amministrazione non conferma l’eliminazione del fornitore,

verranno mantenuti nel database tutti i dati relativi al fornitore in

questione.

3.1. Se è presente anche un solo prodotto associato al fornitore che

si intende eliminare, l’eliminazione fallisce e il sistema notifica

tale situazione con un messaggio di segnalazione indicando il

motivo per il quale il fornitore non può essere rimosso dal

database.


61

Gestire punti vendita


Descrizione

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.

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.

Precondizioni L’utente deve essersi loggato come amministrazione (caso d’uso

“Login”).


all’amministrazione.

Scenario di base

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.

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

alternativo di

insuccesso

1.1. Se la tabella dei punti vendita non contiene alcuna tupla, viene


nessun punto vendita è presente in archivio.


62




non esiste nessun punto vendita che rispetti i dati inseriti.

Esteso dal caso

d’uso

1. Visualizzare punto vendita

2. Rimuovere punto vendita

Extend point

1. Visualizza punto vendita: l’amministrazione visualizza i dati relativi

ad un determinato punto vendita. Si procede con il relativo caso

d’uso.

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


Descrizione

L’amministrazione ha la possibilità di visualizzare i dati caratteristici

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

Scenario di base

1. A partire dalla visualizzazione dell’elenco di tutti i punti vendita,

l’amministrazione ha la possibilità di visualizzare i dati

caratteristici relativi al punto vendita selezionato.


relativi al punto vendita in questione.


63

Rimuovere punto vendita


Descrizione L’amministrazione rimuove dal database tutti i dati relativi ad un

determinato punto vendita.

Precondizioni


d’uso “Gestire punti vendita” e selezionato il punto vendita che si

intende eliminare dal database.

Trigger

Il caso d’uso si attiva selezionando la voce “Rimuovi” presente

nell’apposito menù di gestione dei punti vendita (caso d’uso “Gestire

punti vendita”).

Scenario di base

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



riguardo l’avvenuta eliminazione di tutti i dati relativi al punto

vendita in esame.

Scenario

alternativo di

insuccesso

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.

3.1. In riferimento al punto vendita in questione, se è presente anche

un solo ordine che si trova in uno stato diverso da quello

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


64

Visualizzare storico ordini


Descrizione

L’amministrazione ha la possibilità di visualizzare uno storico di tutti

gli ordini effettuati dai vari punti vendita e archiviati come conclusi.

Per tale motivo riguarda solo gli ordini che si trovino nello stato

“evaso”.

Precondizioni L’utente deve essersi autenticato come amministrazione (caso d’uso

“Login”).

Trigger Il caso d’uso si attiva cliccando sull’apposito pulsante “Storico degli

ordini”.

Scenario di base

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

disposizione.



passo precedente.


relativi all’ordine in questione nello storico.

Scenario

alternativo di

insuccesso

1.1. Se la tabella dello storico non contiene alcuna tupla, viene


nessun ordine si trova nello stato “evaso”.






65

Visualizzare ordini


Descrizione

L’amministrazione ha la possibilità di visualizzare una lista

contenente tutti gli ordini attivi, ossia tutti gli ordini che si trovano

nello stato “in preparazione” o nello stato “pervenuto”.

Precondizioni L’utente deve essersi autenticato come amministrazione (caso d’uso

“Login”).

Trigger Il caso d’uso si attiva cliccando sull’apposito pulsante “Ordini attivi”.

Scenario di base

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.



passo precedente.



Scenario

alternativo di

insuccesso



si indica che in quel dato istante nessun punto vendita presenta





non esiste nessun ordine attivo che rispetti i dati inseriti.


66

MARKETING


67

Gestire listini

Attore principale Addetto ai prodotti e ai listini (marketing).

Descrizione

Il marketing gestisce tutti i listini dell’azienda distributrice. Pertanto

ha la possibilità di visualizzare, aggiungere, modificare e rimuovere i

dati relativi a tutti i listini dei prodotti in vendita.

Precondizioni L’utente deve essersi autenticato come marketing (caso d’uso

“Login”).


alla sezione marketing.

Scenario di base

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.



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.

Scenario

alternativo di

insuccesso

1.1. Se la tabella dei listini non contiene alcuna tupla, viene


listino prodotti è presente in archivio.




non esiste nessun listino prodotti che rispetti i dati inseriti.

Esteso dal caso

d’uso

1. Visualizzare listino

2. Aggiungere listino

3. Modificare listino

4. Rimuovere listino

Extend point 1. Visualizza listino: il marketing visualizza i dati relativi ad un

determinato listino prodotti. Si procede con il relativo caso d’uso.


68

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


Descrizione Il marketing ha la possibilità di visualizzare i dati relativi al listino

(insegna) selezionato.

Precondizioni

Il marketing deve aver precedentemente eseguito il caso d’uso

“Gestire listini” e selezionato il listino prodotti che si intende

visualizzare.

Trigger


nell’apposito menù di gestione delle insegne (caso d’uso “Gestire

listini”).

Scenario di base

1. A partire dalla visualizzazione dell’elenco di tutte le insegne, il

marketing visualizza i dati caratteristici relativi al listino prodotti

selezionato.


relativi al listino prodotti in questione.


69

Aggiungere listino


Descrizione Il marketing provvede ad aggiungere una nuova insegna

commerciale nel database, inserendo tutti i dati relativi ad essa.

Precondizioni Il marketing deve aver precedentemente eseguito il caso d’uso

“Gestire listini”.

Trigger

Il caso d’uso si attiva cliccando sulla voce “Aggiungi” presente


listini”).

Scenario di base

1. Il marketing inserisce i dati relativi al nuovo listino prodotti



2. Il marketing ha la possibilità di confermare l’inserimento del nuovo

listino semplicemente andando a cliccare sull’apposito pulsante

“Conferma inserimento”.


relativo all’avvenuto inserimento del nuovo listino prodotti

all’interno del database.

Scenario

alternativo di

insuccesso



un messaggio di errore e invita il marketing ad apportare le

opportune modifiche.

1.2. Se i nuovi dati inseriti fanno riferimento ad un listino prodotti già


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.


70

Modificare listino


Descrizione Il marketing ha la possibilità di modificare i dati relativi ad un

determinato listino prodotti presente all’interno del database.

Precondizioni


“Gestire listini” e selezionato il listino prodotti che si intende

modificare.

Trigger

Il caso d’uso si attiva cliccando sulla voce “Modifica” presente


listini”).

Scenario di base

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

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

alternativo di

insuccesso





2.2. Se i nuovi dati inseriti fanno riferimento ad un listino prodotti già


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.


71

Rimuovere listino


Descrizione Il marketing rimuove dal database tutti i dati relativi ad un

determinato listino prodotti.

Precondizioni


“Gestire listini” e selezionato il listino che si intende eliminare dal

database.

Trigger

Il caso d’uso si attiva cliccando sulla voce “Rimuovi” presente


listini”).

Scenario di base

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

eliminazione”.


riguardo l’avvenuta eliminazione di tutti i dati relativi al listino

prodotti in esame.

Scenario

alternativo di

insuccesso

2.1. Se il marketing non conferma l’eliminazione dell’insegna,

verranno mantenuti nel database tutti i dati relativi al listino

prodotti in questione.

3.1. Se è presente anche un solo punto vendita associato al listino

che si intende eliminare, l’eliminazione fallisce e il sistema

notifica tale situazione con un messaggio di segnalazione

indicando il motivo per il quale il listino non può essere rimosso

dal database.


72

Gestire prodotti


Descrizione

Il marketing gestisce tutti i prodotti dell’azienda distributrice. Pertanto

ha la possibilità di visualizzare, aggiungere, modificare e rimuovere i

dati relativi a tutti i prodotti in vendita.


“Login”).


alla sezione marketing.

Scenario di base

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.



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.

Scenario

alternativo di

insuccesso

1.1. Se la tabella dei prodotti non contiene alcuna tupla, viene


prodotto è presente in archivio.




non esiste nessun prodotto che rispetti i dati inseriti.

Esteso dal caso

d’uso

1. Visualizzare prodotto

2. Aggiungere prodotto

3. Modificare prodotto

4. Rimuovere prodotto

Extend point 1. Visualizza prodotto: il marketing visualizza i dati relativi ad un

determinato prodotto. Si procede con il relativo caso d’uso.


73

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


Descrizione

Il marketing ha la possibilità di visualizzare una lista contenente tutti i

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.

Trigger

Il caso d’uso si attiva cliccando sulla voce “Visualizza” presente

nell’apposito menù di gestione dei prodotti (caso d’uso “Gestire

prodotti”).

Scenario di base

1. A partire dalla visualizzazione dell’elenco di tutti i prodotti, il

marketing visualizza i dati caratteristici relativi al prodotto

selezionato.


relativi al prodotto in questione.


74

Aggiungere prodotto


Descrizione Il marketing provvede ad aggiungere un nuovo prodotto nel

database, inserendo tutti i dati relativi ad esso.


“Gestire prodotti”.

Trigger

Il caso d’uso si attiva cliccando sulla voce “Aggiungi” presente


prodotti”).

Scenario di base

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

prodotto semplicemente andando a cliccare sull’apposito pulsante

“Conferma inserimento”.


relativo all’avvenuto inserimento del nuovo prodotto all’interno del

database.

Scenario

alternativo di

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.


75

Modificare prodotto


Descrizione Il marketing ha la possibilità di modificare i dati relativi ad un

determinato prodotto presente all’interno del database.


“Gestire prodotti” e selezionato il prodotto che si intende modificare.

Trigger

Il caso d’uso si attiva cliccando sulla voce “Modifica” presente


prodotti”).

Scenario di base

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



3. Il marketing ha la possibilità di confermare le modifiche effettuate




riguardo l’avvenuta modifica dei dati relativi al prodotto in esame.

Scenario

alternativo di

insuccesso





3.1. Se il marketing non conferma le modifiche apportate al prodotto,

tali modifiche andranno perse mantenendo i dati originari.

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.


76

Rimuovere prodotto


Descrizione Il marketing rimuove dal database tutti i dati relativi ad un

determinato prodotto.

Precondizioni


“Gestire prodotti” e selezionato il prodotto che si intende eliminare

dal database.

Trigger

Il caso d’uso si attiva cliccando sulla voce “Rimuovi” presente


prodotti”).

Scenario di base

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



riguardo l’avvenuta eliminazione di tutti i dati relativi al prodotto in

esame.

Scenario

alternativo di

insuccesso

2.1. Se il marketing non conferma l’eliminazione del prodotto,

verranno mantenuti nel database tutti i dati relativi al prodotto in

questione.

3.1. Se è presente anche un solo ordine (in preparazione) associato

al prodotto che si intende eliminare, l’eliminazione fallisce e il

sistema notifica tale situazione con un messaggio di

segnalazione indicando il motivo per il quale il prodotto non può

essere rimosso dal database.


77



Descrizione

Il marketing ha la possibilità di visualizzare i dati caratteristici relativi

ad ogni fornitore con il quale l’azienda distributrice intrattiene rapporti

di tipo commerciale.


“Login”).

Trigger Il caso d’uso si attiva selezionando la voce “Visualizza fornitori”.

Scenario di base

1. A partire dalla visualizzazione dell’elenco di tutti i fornitori, il

marketing visualizza i dati caratteristici relativi al fornitore

selezionato.




78

LOGISTICA


79

Visualizzare ordini

Attore principale Addetto alla gestione degli ordini (logistica).

Descrizione

La logistica ha la possibilità di visualizzare una lista contenente tutti

gli ordini attivi, ossia tutti gli ordini che si trovano nello stato “in

preparazione” o nello stato “pervenuto”.

Precondizioni L’utente deve essersi autenticato come logistica (caso d’uso

“Login”).

Trigger Il caso d’uso si attiva selezionando la voce “Ordini attivi”

nell’apposito menù di gestione degli ordini.

Scenario di base

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.



passo precedente.

4. La logistica ha la possibilità di aggiornare lo stato di un dato

ordine richiamando il relativo caso d’uso.



Scenario

alternativo di

insuccesso



si indica che in quel dato istante nessun punto vendita presenta





non esiste nessun ordine attivo che rispetti i dati inseriti.

Esteso dal caso

d’uso Aggiornare stato ordine

Extend point

Aggiorna stato ordine: selezionando la voce “Aggiorna stato ordine”

si procede con l’aggiornamento dello stato dell’ordine in base al suo

avanzamento. Si passa al relativo caso d’uso.


80

Visualizzare ordini <<include>> Visualizzare stato ordine


Descrizione

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

esempio l’organizzazione delle spedizioni. Inoltre, la logistica può

svolgere una ricerca selettiva per poter individuare gli ordini

d’interesse.

Precondizioni La logistica deve aver precedentemente eseguito il caso d’uso

“Visualizzare ordini”.

Trigger

Il caso d’uso “Visualizzare stato ordine” si attiva automaticamente al

momento della visualizzazione degli ordini in quanto è incluso nel

caso d’uso “Visualizzare ordini”.

Scenario di base

1. Quando viene visualizzata la tabella degli ordini (caso d’uso

“Visualizzare ordini”), viene visualizzato lo stato attuale di ogni

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

alternativo di

insuccesso

2.1. Se la tabella degli ordini non contiene alcuna tupla

corrispondente alla chiave di ricerca specificata, viene

visualizzato un messaggio di errore.


81

Aggiornare stato ordine


Descrizione


ha la possibilità di modificare lo stato degli ordini in maniera tale da

tenerne traccia costantemente. Inoltre ha la possibilità di effettuare

una ricerca selettiva per individuare gli ordini d’interesse.

Precondizioni

La logistica deve aver precedentemente eseguito il caso d’uso

“Visualizzare ordini”. E’ necessario garantire che tale campo sia

costantemente sotto controllo e che sia rappresentativo dell’effettivo

stato in cui si trova l’ordine.

Trigger Il caso d’uso si attiva quando la logistica ha bisogno di aggiornare lo

stato di avanzamento di uno o più ordini.

Scenario di base

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

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

alternativo di

insuccesso

5.2. Se non si conferma la modifica, tutti i cambiamenti effettuati

vanno persi e restano i dati precedenti


82



Descrizione


ha la possibilità di visualizzare i fornitori di tutti i prodotti

effettivamente distribuiti dal nostro sito commerciale.


“Login”).

Trigger Il caso d’uso si attiva entrando nell’apposito menù e scegliendo la

relativa voce “Visualizza fornitori”.

Scenario di base

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.



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.



Scenario

alternativo di

insuccesso

1.1. Se la tabella dei fornitori non contiene alcuna tupla, viene

visualizzato un messaggio di errore con il quale si indica che

nessun fornitore è presente in archivio.

3.1. Se i dati inseriti come chiave di ricerca non soddisfano alcun

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.


83



Descrizione


deve avere la possibilità di visualizzare tutti i prodotti a disposizione

al momento in cui viene effettuata la richiesta.


“Login”).


relativa voce “Visualizza prodotti”.

Scenario di base

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.

Scenario

alternativo di

insuccesso

1.2. Se la tabella dei prodotti non contiene alcuna tupla, viene


nessun prodotto è presente in archivio.



notifica con il quale si indica che non esiste nessun prodotto che



84



Descrizione


deve avere la possibilità di visualizzare tutti i listini prodotti a

disposizione al momento in cui viene effettuata la richiesta.


“Login”).


relativa voce “Visualizza listini ”.

Scenario di base

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.

Scenario

alternativo di

insuccesso

1.2. Se la tabella dei listini non contiene alcuna tupla, viene


nessun listino è presente in archivio.



notifica con il quale si indica che non esiste nessun prodotto che



85

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.

REPARTO

PRODOTTO

FORNITORE

PRODOTTO IN

LISTINO

ORDINE LISTINO

PUNTO

VENDITA STORICO

1

N

N

1

1 N

N

N

1

1

N

1

N

N


86

DIAGRAMMA DELLE CLASSI DI ANALISI

Bavaro - Conversano - Gaeta - Gallitelli – Saponieri Fase di progettazione

87

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


88

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


89

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


90

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


91

� 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,


92

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.


93

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.


94

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


95

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


96

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


97

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.


98

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


99

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


100

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.


101

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;


102

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


103

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.


104

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


105

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:


106

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


107

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.


108

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.


109

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.


110

Il diagramma che descrive il nostro progetto è il seguente:


111

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.


112

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.


113

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:


114

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


115

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;


116

- 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


117

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


118

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.


119

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.


120

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.


121

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


122

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.


123

• 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


124

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


125

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.


126

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.


127

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.


128

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

relation

Usage controller

sub-

components

amministrazione: Fornitore_aggiunto

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


129

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


130

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

diagram

Component Diagram

Component controller

properties qualified name controller

visibility public

leaf false

abstract false




logistica

marketing

pv

user

source of relation

Usage model

target of relation

Usage view

classes Autenticazione

Home

Home_amministrazione

Home_logistica

Home_marketing

Home_pv


131

ProtectionProxyOrdina

RealeOrdina

shown on diagram

Component Diagram

Component model

properties qualified name model

visibility public

leaf false

abstract false




logistica

marketing

pv

user

target of relation

Usage controller

classes Fornitore_model

Listino_model

Ordine_model

Prodotto_model

Reparto_model

Storico_model

Utente_model

shown on diagram

Component Diagram


132

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)


133

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;


134

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


135

CLASSI DI PROGETTO

Riportiamo di seguito il diagramma delle classi e le specifiche delle classi di progetto.


136

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


137

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


138

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.


139

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 Home

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 diagram

Class Diagram


140

Class Chi_siamo

diagram Chi_siamo

owner utente

properties qualified name view::utente::Chi_siamo visibility public


active false associations

from

from Association name Home (Property5 )

typedElements Class Home Property Property5

shown on diagram

Class Diagram

Class Contatti

diagram Contatti

owner utente

properties qualified name view::utente::Contatti visibility public



from


typedElements Class Home Property Property4 Class Home_pv Property Property14

shown on diagram

Class Diagram

Class Dove_siamo

diagram Dove_siamo

owner utente

properties qualified name view::utente::Dove_siamo visibility public



from

from Association name Home_pv (Property13 ) Home (Property4 )


141

typedElements Class Home Property Property4 Class Home_pv Property Property13

shown on diagram

Class Diagram

Class Introduzione

diagram Introduzione

owner utente

properties qualified name view::utente::Introduzione visibility public



from



shown on diagram

Class Diagram

Class Note_legali

diagram Note_legali

owner utente

properties qualified name view::utente::Note_legali visibility public



from



shown on diagram

Class Diagram

Class Login

diagram Login

Property1:Autenticazione

owner menu


142

properties qualified name view::menu::Login visibility public


active false ownedMember Property1

associations to from to Association name Property1 Autenticazione

associations from



shown on diagram

Class Diagram

Class Recupera_password

diagram Recupera_password

owner utente

properties qualified name view::utente::Recupera_password visibility public



from



shown on diagram

Class Diagram

Class Esito_recupera_password

diagram Esito_recupera_password

owner utente

properties qualified name view::utente::Esito_recupera_password visibility public



from



shown on diagram

Class Diagram


143

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

verif ica()

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


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

associations to from to Association name Property1 Registrati Property2 Registrazione_riuscita Property3 Utente_model Property4 Home_amministrazione Property5 Home_logistica Property6 Home_marketing Property7 Home_pv

associations from

from Association name Login (Property1 )

typedElements Class Login Property Property1

shown on diagram

Class Diagram


144

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



from

from Association name Autenticazione (Property1 )

typedElements Class Autenticazione Property Property1

shown on diagram

Class Diagram


145

Class Registrazione_riuscita

diagram Registrazione_ riuscita

owner utente

properties qualified name view::utente::Registrazione_riuscita visibility public



from



shown on diagram

Class Diagram


146

Class Home_amministrazione

diagram Home_amministrazione

Property1:Fornitore_aggiunto

Property2:Modif ica_fornitore

Property3:Modif ica_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:Modif ica_insegna_pv

Property21:Modif ica_insegna_pv_riuscita

home_amministrazione()

index()

dove_siamo()

visualizza_elenco_storico()

f iltra_elenco_storico()

visualizza_elenco_ordine()

f iltra_elenco_ordine()

gestione_pv()

f iltra_pv()

visualizza_pv()

elimina_pv()

gestione_fornitori()

nuovo_fornitore()

aggiungi_fornitore()

visualizza_fornitore()

modif ica_fornitore()

conferma_modif iche_fornitore()

elimina_fornitore()

esiste_p_iva_f()

f iltra_elenco_pv()

f iltra_elenco_fornitore()

chi_siamo()

note_legali()

contatti()

modif ica_insegna_pv()

conferma_modif ica_insegna_pv()

owner controller

properties qualified name controller::Home_amministrazione visibility public


147


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 Property16 Property17 Property18 Property19 Property2 Property20 Property21 Property3 Property4 Property5 Property6 Property7 Property8 Property9 visualizza_elenco_ordine visualizza_elenco_storico visualizza_fornitore visualizza_pv

associations to from to Association name 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 Property14 Utente_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

associations from



shown on diagram

Class 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;


148

- 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_amministrazione

owner menu

properties qualified name view::menu::Menu_amministrazione visibility Public

leaf False abstract False

active False associations

from

from Association name Home_amministrazione (Property15 )

typedElements Class Home_amministrazione Property Property15

shown on diagram

Class Diagram


149

Class Fornitore_aggiunto

diagram Fornitore_aggiunto

owner amministrazione

properties qualified name view::amministrazione::Fornitore_aggiunto visibility public



from



shown on diagram

Class Diagram

Class Modifica_fornitore

diagram Modifica_fornitore


properties qualified name view::amministrazione::Modifica_fornitore visibility public



from



shown on diagram

Class Diagram

Class Modifica_fornitore_riuscita

diagram Modifica_fornitore_riuscita


properties qualified name view::amministrazione::Modifica_fornitore_riuscita visibility public



150


from



shown on diagram

Class Diagram

Class Nuovo_fornitore

diagram Nuovo_fornitore


properties qualified name view::amministrazione::Nuovo_fornitore visibility public



from



shown on diagram

Class Diagram

Class Visualizza_elenco_fornitore

diagram Visualizza_elenco_fornitori


properties qualified name view::amministrazione::Visualizza_elenco_fornitori visibility public



from



shown on diagram

Class Diagram


151

Class Visualizza_elenco_ordini

diagram Visualizza_elenco_ordini


properties qualified name view::amministrazione::Visualizza_elenco_ordini visibility public



from



shown on diagram

Class Diagram

Class Visualizza_elenco_pv

diagram Visualizza_elenco_ pv


properties qualified name view::amministrazione::Visualizza_elenco_pv visibility public



from



shown on diagram

Class Diagram

Class Visualizza_elenco_storico

diagram Visualizza_elenco_storico


properties qualified name view::amministrazione::Visualizza_elenco_storico visibility public



152


from



shown on diagram

Class Diagram

Class Visualizza_fornitore

diagram Visualizza_ fornitore


properties qualified name view::amministrazione::Visualizza_fornitore visibility public



from



shown on diagram

Class Diagram

Class Visualizza_pv

diagram Visualizza_ pv


properties qualified name view::amministrazione::Visualizza_pv visibility public



from



shown on diagram

Class Diagram


153

Class Elimina_fornitore_non_riuscita

diagram Elimina_fornitore_non_riuscita


properties qualified name view::amministrazione::Elimina_fornitore_non_riuscita visibility public



from



shown on diagram

Class Diagram

Class Elimina_fornitore_riuscita

diagram Elimina_fornitore_riuscita


properties qualified name view::amministrazione::Elimina_fornitore_riuscita visibility public



from



shown on diagram

Class Diagram

Class Elimina_pv_non_riuscita

diagram Elimina_pv_non_riuscita


properties qualified name view::amministrazione::Elimina_pv_non_riuscita visibility public



154


from



shown on diagram

Class Diagram

Class Elimina_pv_riuscita

diagram Elimina_pv_riuscita


properties qualified name view::amministrazione::Elimina_pv_riuscita visibility public



from



shown on diagram

Class Diagram

Class Modifica_insegna_pv

diagram Modifica_insegna_pv


properties qualified name view::amministrazione::Modifica_insegna_pv visibility public



from



shown on diagram

Class Diagram


155

Class Modifica_insegna_pv_riuscita

diagram Modifica_insegna_pv_riuscita


properties qualified name view::amministrazione::Modifica_insegna_pv_riuscita visibility public



from



shown on diagram

Class Diagram


156

Class Home_logistica

diagram Home_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()

f iltra_elenco_ordine()

visualizza_ordine()

modif ica_stato_ordine()

visualizza_elenco_listino()

f iltra_elenco_listino()

visualizza_listino()

visualizza_elenco_prodotto()

f iltra_elenco_prodotto()

visualizza_prodotto()

visualizza_elenco_fornitore()



home_logistica()

chi_siamo()

note_legali()

contatti()

owner controller

properties qualified name controller::Home_logistica visibility public


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


157

associations to from to Association name Property1 Visualizza_elenco_fornitori Property2 Visualizza_elenco_listini Property3 Visualizza_elenco_ordini Property4 Visualizza_elenco_prodotti Property5 Visualizza_fornitore Property6 Visualizza_ordine Property7 Visualizza_prodotto Property8 Fornitore_model Property9 Listino_model Property10 Ordine_model Property11 Prodotto_model Property12 Reparto_model Property13 Menu_logistica Property14 Visualizza_listino

associations from



shown on diagram

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


158

Class Menu_logistica

diagram Menu_logistica

owner menu

properties qualified name view::menu::Menu_logistica visibility public



from

from Association name Home_logistica (Property13 )

typedElements Class Home_logistica Property Property13

shown on diagram

Class Diagram

Class Visualizza_elenco_fornitori


owner logistica

properties qualified name view::logistica::Visualizza_elenco_fornitori visibility public



from



shown on diagram

Class Diagram

Class Visualizza_elenco_listini

diagram Visualizza_elenco_listini

owner logistica

properties qualified name view::logistica::Visualizza_elenco_listini visibility public



159


from



shown on diagram

Class Diagram



owner logistica

properties qualified name view::logistica::Visualizza_elenco_ordini visibility public



from



shown on diagram

Class Diagram

Class Visualizza_elenco_prodotti

diagram Visualizza_elenco_prodotti

owner logistica

properties qualified name view::logistica::Visualizza_elenco_prodotti visibility public



from



shown on diagram

Class Diagram


160



owner logistica

properties qualified name view::logistica::Visualizza_fornitore visibility public



from



shown on diagram

Class Diagram

Class Visualizza_ordine

diagram Visualizza_ordine

owner logistica

properties qualified name view::logistica::Visualizza_ordine visibility public



from



shown on diagram

Class Diagram

Class Visualizza_prodotto

diagram Visualizza_prodotto

owner logistica

properties qualified name view::logistica::Visualizza_prodotto visibility public



161


from



shown on diagram

Class Diagram

Class Visualizza_listino

diagram Visualizza_listino

owner logistica

properties qualified name view::logistica::Visualizza_listino visibility public



from



shown on diagram

Class Diagram


162

Class Home_marketing

diagram Home_marketing

Property1:Listino_aggiunto

Property2:Modif ica_prodotto

Property3:Modif ica_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:Modif ica_listino

Property22:Modif ica_listino_riuscita

Property23:Visualizza_listino

Property24:Nuovo_reparto

Property25:Visualizza_elenco_reparti

Property26:Modif ica_prodotto_non_consentita

Property27:Elimina_reparto_riuscita_e_non

index()

dove_siamo()

gestione_prodotti()

f iltra_elenco_prodotto()

nuovo_prodotto()

aggiungi_prodotto()


modif ica_prodotto()

conferma_modif iche_prodotto()

elimina_prodotto()

esiste_cod_prodotto()

gestione_listini()

f iltra_elenco_listino()

nuovo_listino()

aggiungi_listino()


modif ica_listino()

conferma_modif iche_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


163


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 Property13 Property14 Property15 Property16 Property17 Property18 Property19 Property2 Property20 Property21 Property22 Property23 Property24 Property25 Property26 Property27 Property3 Property4 Property5 Property6 Property7 Property8 Property9 visualizza_elenco_fornitore visualizza_fornitore visualizza_listino visualizza_prodotto

associations to from to Association name Property1 Listino_aggiunto Property2 Modifica_prodotto Property3 Modifica_prodotto_riuscita Property4 Nuovo_listino Property5 Nuovo_prodotto Property6 Prodotto_aggiunto Property7 Visualizza_elenco_fornitori Property8 Visualizza_elenco_listini Property9 Visualizza_elenco_prodotti Property10 Visualizza_fornitore Property11 Visualizza_prodotto Property12 Reparto_model Property13 Prodotto_model Property14 Listino_model Property15 Fornitore_model 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

associations from



shown on diagram

Class Diagram


- home_marketing() – costruttore;


164

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


165

Class Menu_marketing

diagram Menu_marketing

owner menu

properties qualified name view::menu::Menu_marketing visibility public



from

from Association name Home_marketing (Property16 )

typedElements Class Home_marketing Property Property16

shown on diagram

Class Diagram

Class Listino_aggiunto

diagram Listino_aggiunto

owner marketing

properties qualified name view::marketing::Listino_aggiunto visibility public



from



shown on diagram

Class Diagram

Class Modifica_prodotto

diagram Modifica_prodotto

owner marketing

properties qualified name view::marketing::Modifica_prodotto visibility public



166


from



shown on diagram

Class Diagram

Class Modifica_prodotto_riuscita

diagram Modifica_prodotto_ riuscita

owner marketing

properties qualified name view::marketing::Modifica_prodotto_riuscita visibility public



from



shown on diagram

Class Diagram

Class Nuovo_listino

diagram Nuovo_listino

owner marketing

properties qualified name view::marketing::Nuovo_listino visibility public



from



shown on diagram

Class Diagram


167

Class Nuovo_prodotto

diagram Nuovo_prodotto

owner marketing

properties qualified name view::marketing::Nuovo_prodotto visibility public



from



shown on diagram

Class Diagram

Class Prodotto_aggiunto

diagram Prodotto_aggiunto

owner marketing

properties qualified name view::marketing::Prodotto_aggiunto visibility public



from



shown on diagram

Class Diagram

Class Visualizza_elenco_fornitori


owner marketing

properties qualified name view::marketing::Visualizza_elenco_fornitori visibility public



168


from



shown on diagram

Class Diagram

Class Visualizza_elenco_listini

diagram Visualizza_elenco_listini

owner marketing

properties qualified name view::marketing::Visualizza_elenco_listini visibility public



from



shown on diagram

Class Diagram

Class Visualizza_elenco_prodotti

diagram Visualizza_elenco_prodotti

owner marketing

properties qualified name view::marketing::Visualizza_elenco_prodotti visibility public



from



shown on diagram

Class Diagram


169



owner marketing

properties qualified name view::marketing::Visualizza_fornitore visibility public



from



shown on diagram

Class Diagram



owner marketing

properties qualified name view::marketing::Visualizza_prodotto visibility public



from



shown on diagram

Class Diagram

Class Elimina_listino_non_riuscita

diagram Elimina_listino_non_riuscita

owner marketing

properties qualified name view::marketing::Elimina_listino_non_riuscita visibility public



170


from



shown on diagram

Class Diagram

Class Elimina_listino_riuscita

diagram Elimina_listino_riuscita

owner marketing

properties qualified name view::marketing::Elimina_listino_riuscita visibility public



from



shown on diagram

Class Diagram

Class Elimina_prodotto_non_riuscita

diagram Elimina_prodotto_non_riuscita

owner marketing

properties qualified name view::marketing::Elimina_prodotto_non_riuscita visibility public



from



shown on diagram

Class Diagram


171

Class Elimina_prodotto_riuscita

diagram Elimina_prodotto_riuscita

owner marketing

properties qualified name view::marketing::Elimina_prodotto_riuscita visibility public



from



shown on diagram

Class Diagram

Class Modifica_listino

diagram Modifica_listino

owner marketing

properties qualified name view::marketing::Modifica_listino visibility public



from



shown on diagram

Class Diagram

Class Modifica_listino_riuscita

diagram Modifica_listino_riuscita

owner marketing

properties qualified name view::marketing::Modifica_listino_riuscita visibility public



172


from



shown on diagram

Class Diagram

Class Visualizza_listino

diagram Visualizza_listino

owner marketing

properties qualified name view::marketing::Visualizza_listino visibility public



from



shown on diagram

Class Diagram

Class Nuovo_reparto

diagram Nuovo_reparto

owner marketing

properties qualified name view::marketing::Nuovo_reparto visibility public



from



shown on diagram

Class Diagram


173

Class Visualizza_elenco-reparti

diagram Visualizza_elenco_reparti

owner marketing

properties qualified name view::marketing::Visualizza_elenco_reparti visibility public



from



shown on diagram

Class Diagram

Class Modifica_prodotto_non_consentita

diagram Modifica_prodotto_non_consentita

owner marketing

properties qualified name view::marketing::Modifica_prodotto_non_consentita visibility public



from



shown on diagram

Class Diagram


174

Class Elimina_reparto_riuscita_e_non

diagram Elimina_reparto_riuscita_e_non

owner marketing

properties qualified name view::marketing::Elimina_reparto_riuscita_e_non visibility public



from



shown on diagram

Class Diagram


175

Class Home_pv

diagram Home_pv

Property1:Carrello

Property2:Introduzione

Property3:Modifica_pv

Property4:Modifica_pv_riuscita

Property5:Prof ilo

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_modif iche_pv()

esiste_username()

passw ord_corretta()

esiste_partita_iva()

aggiungi_ordine()

visualizza_ordini_attivi()

filtra_elenco_ordine()

visualizza_ordine()

vota_ordine()

conferma_voto()

visualizza_storico()

filtra_visualizza_storico()

vota_ordine_in_storico()

conferma_voto_storico()

chi_siamo()

note_legali()

contatti()

filtra_elenco_prodotto()


owner controller

properties qualified name controller::Home_pv visibility public


176


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 Property14 Property15 Property16 Property17 Property18 Property19 Property2 Property20 Property21 Property22 Property23 Property24 Property25 Property26 Property27 Property3 Property4 Property5 Property6 Property7 Property8 Property9 visualizza_carrello visualizza_listino visualizza_ordine visualizza_ordini_attivi visualizza_prodotto visualizza_storico vota_ordine vota_ordine_in_storico

associations to from to Association name Property1 Carrello Property2 Introduzione Property3 Modifica_pv Property4 Modifica_pv_riuscita Property5 Profilo Property6 Visualizza_proprio_listino Property7 Utente_model Property8 Reparto_model Property9 Prodotto_model Property10 Ordine_model Property11 Listino_model Property12 Fornitore_model Property15 Menu_pv Property16 Storico_model Property17 Disponibilita_non_sufficiente Property18 Nuovo_ordine Property19 Ordine_aggiunto Property20 Visualizza_elenco_ordini Property21 Visualizza_elenco_storico Property22 Visualizza_ordine Property23 Visualizza_prodotto Property24 Vota_ordine Property25 Voto_ordine_inserito Property26 Vota_ordine_storico Property27 Voto_storico_inserito

associations from



shown on diagram

Class 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;


177

- 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


active false


178

associations from

from Association name Home_pv (Property15 )

typedElements Class Home_pv Property Property15

shown on diagram

Class Diagram

Class Carrello

diagram Carrello

owner pv

properties qualified name view::pv::Carrello visibility public



from



shown on diagram

Class Diagram

Class Introduzione

diagram Introduzione

owner pv

properties qualified name view::pv::Introduzione visibility public



from



shown on diagram

Class Diagram


179

Class Modifica_pv

diagram Modifica_ pv

owner pv

properties qualified name view::pv::Modifica_pv visibility public



from



shown on diagram

Class Diagram

Class Modifica_pv_riuscita

diagram Modifica_pv_riuscita

owner pv

properties qualified name view::pv::Modifica_pv_riuscita visibility public



from



shown on diagram

Class Diagram

Class Profilo

diagram Profilo

owner pv

properties qualified name view::pv::Profilo visibility public



180


from



shown on diagram

Class Diagram

Class Visualizza_proprio_listino

diagram Visualizza_proprio_listino

owner pv

properties qualified name view::pv::Visualizza_proprio_listino visibility public



from



shown on diagram

Class Diagram

Class Disponibilita_non_sufficiente

diagram Disponibilita_non_sufficiente

owner pv

properties qualified name view::pv::Disponibilita_non_sufficiente visibility public



from



shown on diagram

Class Diagram


181

Class Nuovo_ordine

diagram Nuovo_ordine

owner pv

properties qualified name view::pv::Nuovo_ordine visibility public



from



shown on diagram

Class 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

associations to from to Association name Property1 RealeOrdina

associations from

from Association name Nuovo_ordine (Property1 )

typedElements Class Nuovo_ordine Property Property1

shown on diagram

Class Diagram


182

Class RealeOrdina

diagram RealeOrdina

procedi()

owner controller

properties qualified name controller::RealeOrdina visibility public


active false ownedMember procedi

associations from

from Association name ProtectionProxyOrdina (Property1 )

typedElements Class ProtectionProxyOrdina Property Property1

shown on diagram

Class 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



from



shown on diagram

Class Diagram


183



owner pv

properties qualified name view::pv::Visualizza_elenco_ordini visibility public



from



shown on diagram

Class Diagram

Class Visualizza_elenco_storico

diagram Visualizza_elenco_storico

owner pv

properties qualified name view::pv::Visualizza_elenco_storico visibility public



from



shown on diagram

Class Diagram

Class Visualizza_ordine

diagram Visualizza_ordine

owner pv

properties qualified name view::pv::Visualizza_ordine visibility public



184


from



shown on diagram

Class Diagram



owner pv

properties qualified name view::pv::Visualizza_prodotto visibility public



from



shown on diagram

Class Diagram

Class Vota_ordine

diagram Vota_ordine

owner pv

properties qualified name view::pv::Vota_ordine visibility public



from



shown on diagram

Class Diagram


185

Class Voto_ordine_inserito

diagram Voto_ordine_inserito

owner pv

properties qualified name view::pv::Voto_ordine_inserito visibility public



from



shown on diagram

Class Diagram

Class Vota_ordine_storico

diagram Vota_ordine_storico

owner pv

properties qualified name view::pv::Vota_ordine_storico visibility public



from



shown on diagram

Class Diagram

Class Voto_storico_inserito

diagram Voto_storico_inserito

owner pv

properties qualified name view::pv::Voto_storico_inserito visibility public



186


from



shown on diagram

Class Diagram

Class Fornitore_model

diagram Fornitore_model

p_iva_f

nome

indirizzo

tel

email

fonitore_model()

required()

aggiungi_fonitore()

preleva_elenco_fornitore()

preleva_fornitore()

modif ica_fornitore()

elimina_fornitore()

trova_p_iva_f()

owner model

properties qualified name model::Fornitore_model visibility public


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

associations from

from Association name Home_pv (Property12 ) Home_marketing (Property15 ) Home_logistica (Property8 ) Home_amministrazione (Property11 )

typedElements Class Home_amministrazione Property Property11 Class Home_logistica Property Property8

Class Home_marketing Property Property15 Class Home_pv Property Property12

shown on diagram

Class Diagram


187


- 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_model

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

modif ica_listino()

trova_listino()

modif ica_prodotto_listino()

preleva_prodotto_listino_filtrato()

modif ica_insegna_ordine_prod_listino()

owner model

properties qualified name model::Listino_model visibility public


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

associations from



188

Home_marketing (Property14 ) Home_logistica (Property9 )

typedElements Class Home_logistica Property Property9 Class Home_marketing Property Property14

Class Home_pv Property Property11 shown on

diagram Class 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.


189

Class Ordine_model

diagram Ordine_model

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

modif ica_stato_ordine()

elimina_ordine()

prezzo_ordine()

required()

aggiungi_ordine()

aggiungi_ordine_prodotto_listino()

modif ica_voto_ordine()

numero_fattura_precedente()

modif ica_piva_in_ordine()

numero_ordini_attivi_pv()

numero_ordini_con_prodotto()

owner model

properties qualified name model::Ordine_model visibility public


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

associations from

from Association name Home_pv (Property10 ) Home_logistica (Property10 ) Home_amministrazione (Property12 )

typedElements Class Home_amministrazione Property Property12 Class Home_logistica Property Property10

Class Home_pv Property Property10


190

shown on diagram

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


191

Class Prodotto_model

diagram Prodotto_model

cod_prodotto

nome

descrizione

provenienza

prezzo_unitario

disponibilita_residua

data_scadenza

p_iva_f

nomeReparto

prodotto_model()

required()

aggiungi_prodotto()

preleva_prodotto()

modif ica_prodotto()

elimina_prodotto()

trova_cod_prodotto()

preleva_elenco_prodotto()

modif ica_pivaf_in_prodotto()

numero_prodotti_fornitore()

controllo_disponibilita()

numero_prodotti_con_reparto()

owner model

properties qualified name model::Prodotto_model visibility public


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

associations from

from Association name Home_pv (Property9 ) Home_marketing (Property13 ) Home_logistica (Property11 )





192

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_model

nome_reparto

reparto_model()

required()

aggiungi_reparto()

preleva_elenco_reparto()

trova_reparto()

elimina_reparto()

owner model

properties qualified name model::Reparto_model visibility public


active false ownedMember aggiungi_reparto elimina_reparto nome_reparto preleva_elenco_reparto

reparto_model required trova_reparto

associations from

from Association name Home_pv (Property8 ) Home_marketing (Property12 ) Home_logistica (Property12 )





193


- 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_model

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

modif ica_piva_in_storico()

modif ica_voto_ordine_storico()

owner model

properties qualified name model::Storico_model visibility public


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

associations from

from Association name Home_pv (Property16 ) Home_amministrazione (Property13 )

typedElements Class Home_amministrazione Property Property13 Class Home_pv Property Property16

shown on diagram

Class Diagram


194


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


195

Class Utente_model

diagram Utente_model

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

modif ica_utente()

elimina_pv()

login()

trova_utente()

trova_partita_iva()

preleva_nome_insegna()

preleva_utente_da_user()

preleva_p_iva()

modif ica_passw ord()

assegna_insegna_pv()

modif ica_insegna_pv()

numero_pv_con_insegna()

owner model

properties qualified name model::Utente_model visibility public


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

associations from

from Association name Autenticazione (Property3 ) Home_pv (Property7 ) Home_amministrazione (Property14 )



196

Class Home_amministrazione Property Property14 Class Home_pv Property Property7

Shown on diagram

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


197

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


198

CREAZIONE ORDINE


199

AGGIUNGI PRODOTTO


200

GESTIONE ORDINI


201

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


202

USER

Visualizzare Home page


203

Registrare punto vendita


204

Recuperare password


205

Login


206

PUNTO VENDITA

Visualizzare proprio listino


207

Filtrare prodotti (pv)


208

Gestire carrello


209

Aggiungi al carrello

Effettuare ordine


210

Confermare ordine


211

Visualizzare profilo


212

Modificare profilo


213

Visualizzare storico propri ordini


214

Filtrare storico (pv)

Valutare ordine evaso


215

Visualizzare propri ordini


216

Filtrare ordini (pv)


217

Valutare ordine pervenuto

Visualizzare ordine (pv)


218

AMMINISTRAZIONE

Gestire fornitori


219

Filtrare fornitori


220


Modificare fornitore


221

Rimuovere fornitore

Aggiungere fornitore


222

Gestire punti vendita


223

Filtrare punti vendita

Visualizzare punto vendita


224

Modificare insegna

Rimuovere punto vendita


225

Visualizzare storico ordini

Filtrare storico


226

Visualizzare ordini (amministrazione)

Filtrare ordini (amministrazione)


227

MARKETING

Gestire listini


228

Filtrare listini


229



230

Aggiungere listino


231

Modificare listino


232

Rimuovere listino


233

Gestire prodotti


234

Filtrare prodotti


235


Modificare prodotto


236

Rimuovere prodotto

Aggiungere prodotto


237

Visualizzare fornitori (marketing)

Filtrare fornitori (marketing)


238

Visualizzare fornitore (marketing)


239

LOGISTICA

Visualizzare ordini


240

Filtrare ordini


241

Visualizzare ordine


242

Aggiornare stato ordine


243

Annullare stato ordine


244

Visualizzare fornitori (logistica)

Filtrare fornitori (logistica)


245

Visualizzare fornitore (logistica)

Visualizzare prodotti (logistica)


246

Filtrare prodotti (logistica)

Visualizzare prodotto (logistica)


247

Visualizzare listini (logistica)

Filtrare listini (logistica)


248

Visualizzare listino (logistica)


249

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.


250

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.

Bavaro - Conversano - Gaeta - Gallitelli - Saponieri Fase di Test

499

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.


500

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.


501

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 revisor i, 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 dis positivo 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.


502

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 è specifi cato 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 cas o 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 com parire 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 int eragisce con un attore è

consistente con i requisiti generali? I requisiti s ono oscuri o inconsistenti circa

questa interazione?


503

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 ri levanti 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 comportamen ti e riportate le classi

necessarie?

Si veda la 8) della check list dei casi d’uso e la 1) della check list degli oggetti.


504

CHECK LIST PER I REQUISITI

◊ Omissione

1) Le funzioni descritte sono sufficienti per soddis fare 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 desid erati 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 ch e 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.


505

◊ Inconsistenza

6) Ci sono requisiti specifici in conflitto tra lor o (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 gl i 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 compon enti 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?


506

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 component i 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 apposit o 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 giustificat e adeguatamente?

Ogni scelta progettuale è stata attentamente ponderata al fine di garantire un software

funzionante, nel rispetto delle specifiche, portabile ed user friendly.


507

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 appl icativo 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 g enerali 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


508

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.

Funzionalità Front-end Content Management

Le funzioni disponibili sono usufruibili senza lasciare il sito 3 5

Le funzioni implementate sono usufruibili senza il download di plug-in

3 2

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 dei requisiti

3 5


509

Chiarezza visiva Front-end Content Management

Il layout è chiaro e gli spazi sono adeguati tra box, immagini e parti di testo

3 4

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

Controllo Front-end Content Management

L’utente può cancellare tute le operazioni 2 5

Nel caso di implementazione di funzioni come esecuzione guidata di diversi passi, l’utente può cancellare l’operazione di ogni singolo passo

2 5

C’è una chiara opzione di uscita in ogni pagina 2 4

Il peso delle pagine è adeguato 3 2

Correzione e Prevenzione degli errori Front-end Content 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 assistenza

3 3


510

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 peri colosa)?

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 compat ibili 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.


511

6) È possibile una condizione di overflow (ad esempi o 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.


512

11) È possibile che, a causa delle condizioni di in gresso, 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 corr isponde 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 para metri 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.


513

◊ 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? Contro lla la validità dell’input?

Il controllo è molto rigido ed è svolto dai metodi delle classi che effettuano le insert nel

data base.

Progetto di Ingegneria del Software

Documents

Transcript of Progetto di Ingegneria del Software