Upload
xaviera-di-mauro
View
220
Download
1
Embed Size (px)
Citation preview
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
Università degli Studi di CataniaFacoltà di Ingegneria
CdL in Ingegneria Informatica – A.A. 2006/07
Prof. Ing. Alberto Faro
Realizzato da:Bannò FilippoCarobene ElenaDi Martino Vincenzo
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
Introduzione
Entity Relation Model
Analisi dei Templates
Rete di Petri
Entity Function Matrix
Automi
Process Outline
Entity Life History
Dimensionamento
Dalle entità alle tabelle
Entity – Data-store Cross Reference
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
Il progetto consiste nella realizzazione e nell’analisi di un sistema informativo per la
gestione della fumetteria Comics & Games.
La fumetteria si occupa di:
• vendita di prodotti (Fumetti, action figures, ecc…);
• organizzazione di tornei.
Il sistema informativo fornisce due tipi di servizi:
1. Servizi dedicati agli utenti, quali l’acquisto di prodotti online, l’iscrizione ai tornei ed
il mantenimento sul server di un profilo con carriera, acquisti in corso e conclusi;
2. Servizi dedicati al gestore, quali l’organizzazione dei tornei, l’amministrazione dei
registri di acquisti e vendite e la gestione degli account utente.
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
L’analisi dei Templates e la rap-
presentazione mediante casi d’uso di un
sistema informativo è un importante
quanto semplice metodo di progettazione
in quanto ci permette di analizzare tutti
gli aspetti e i servizi per il quale il sistema
stesso è stato progettato, con la possibilità
di anticipare ed eliminare eventuali
anomalie e/o errori
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
Gestione dati utente
Gestione tornei
Vendita ad un utente
Acquisto da fornitore
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
E1.1E1.1
E1.2E1.2
E1.3E1.3
Inizio
Fine
E1.5E1.5
E1.4E1.4
WHO: Utente, Web Server, Gestore.
WHAT: Creazione, modifica ed eliminazione di un account utente.
WHEN: A seconda dello specifico episodio.
HOW:• Episodio 1.1: Registrazione nuovo utente;• Episodio 1.2: Modifica dati utente;• Episodio 1.3: Sospensione utente;• Episodio 1.4: Reinserimento utente;• Episodio 1.5: Cancellazione utente.
WHAT CAN GO WRONG: Sono specificati in ogni singolo episodio.
Ogni cliente della fumetteria può registrarsi al sito ed ottenere un account personale; i dati anagrafici inseriti sono modificabili in qualsiasi momento.
Il gestore della fumetteria può sospendere l’account in caso di comportamento scorretto dell’utente, o, dietro richiesta di quest’ultimo, eliminarlo dal database.
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
WHO: Utente, Web Server
WHAT: Registrazione nuovo Utente.
WHEN: 24 ore su 24.
HOW:
A1: L’Utente accede alla pagina di registrazione.
A2: L’Utente inserisce i propri dati.
A3: Il Web Server verifica la validità dei dati inseriti.
A4: Il Web Server inserisce i dati nell’archivio.
A5: Il Web Server notifica l’avvenuto inserimento.
WHAT CAN GO WRONG:
W1: L’Utente inserisce dati non validi o incompleti.
EH1: L’Utente inserisce di nuovo i dati.
W2: Problemi di connessione.
EH2: L’Utente prova a riconnettersi.
ASSUMPTIONS: Web Server funzionante.
A1A1
A2A2
A3A3
A4A4
W1W1
W2W2
Inizio
Fine
A5A5
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
UTENTE WEB SERVER ARCHIVIOUTENTI
A1 L’Utente accede alla pagina di registrazione.
A2 L’Utente inserisce i propri dati.
A3 Il Web Server verifica la validità dei dati inseriti.
A4 Il Web Server inserisce i dati nell’archivio.
A5 Il Web Server notifica l’avvenuto inserimento.
A1
A2 A4
A5
A3
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
WHO: Utente, Web Server.
WHAT: Modifica dati Utente.
WHEN: 24 ore su 24.
HOW:B1: L’Utente effettua il login.B2: L’Utente accede al profilo.B3: Il Web Server ricerca i dati nell’archivio.B4: Il Web Server visualizza i dati dell’utente.B5: L’Utente inserisce i nuovi dati.B6: Il Web Server verifica la validità dei dati inseriti.B7: Il Web Server aggiorna l’Archivio Utenti.B8: Il Web Server conferma l’avvenuta modifica.
WHAT CAN GO WRONG:W1: L’Utente inserisce username e password errati.EH1: L’utente reinserisce username e password.W2: L’utente inserisce dati non validi.EH3: Reinserimento dati.W3: Problemi di connessione.EH4: L’Utente prova a riconnettersi.
ASSUMPTIONS: Il Web Server è funzionante e l’Utente possiede un account valido.
Fine
Inizio
B1B1 B2B2
B4B4 B3B3
B5B5 W2W2
W3W3
B6B6
B7B7B8B8
W1W1
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
UTENTE WEB SERVER ARCHIVIOUTENTI
B1: L’Utente effettua il login.B2: L’Utente accede al profilo.B3: Il Web Server ricerca i dati nell’archivio.B4: Il Web Server visualizza i dati dell’utente.B5: L’Utente inserisce i nuovi dati.B6: Il Web Server verifica la validità dei dati inseriti.B7: Il Web Server aggiorna l’Archivio Utenti.B8: Il Web Server conferma l’avvenuta modifica.
B1
B2 B3
B4
B5 B7
B8
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
WHO: Gestore, Web Server.
WHAT: Sospensione dell’account Utente.
WHEN: 24 ore su 24.
HOW:
C1: Il Gestore accede alla sezione Utenti.
C2: Il Gestore sospende l’account.
C3: Il Web Server aggiorna gli archivi.
ASSUMPTIONS: Il Web Server è funzionante e il Gestore ha accesso al sito; l’Utente ha violato il regolamento della fumetteria.
C1C1
C2C2
C3C3
Inizio
Fine
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
UTENTE WEB SERVER ARCHIVIOUTENTI
C1: Il Gestore accede alla sezione Utenti.C2: Il Gestore sospende l’account.C3: Il Web Server aggiorna gli archivi.
C1
C2 C3
ARCHIVIOTORNEI
ARCHIVIOVENDITE
C3
C3
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
WHO: Gestore, Web Server.
WHAT: Riattivazione dell’account Utente.
WHEN: 24 ore su 24.
HOW:
D1: Il Gestore accede alla sezione Utenti.
D2: Il Gestore riattiva l’account.
D3: Il Web Server aggiorna l’Archivio Utenti.
ASSUMPTIONS: Il Web Server è funzionante e il Gestore ha accesso al sito; l’Utente ha regolarizzato la propria posizione presso il Gestore.
D1D1
D2D2
D3D3
Inizio
Fine
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
UTENTE WEB SERVER ARCHIVIOUTENTI
D1: Il Gestore accede alla sezione Utenti.D2: Il Gestore riattiva l’account.D3: Il Web Server aggiorna l’Archivio Utenti.
D1
D2 D3
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
WHO: Utente, Web Server, Gestore.
WHAT: Cancellazione dell’account Utente
WHEN: Durante l’orario di apertura della fumetteria.
HOW:
E1: L’Utente richiede l’eliminazione.
E2: L’Utente fornisce il proprio username.
E3: Il Gestore accede all’area Utenti.
E4: Il Gestore elimina l’account.
E5: Il Web Server aggiorna gli archivi.
WHAT CAN GO WRONG:
W1: Il terminale del gestore non è funzionante.
EH1: L’Utente lascia i propri dati affinché il Gestore elimini l’account non appena possibile.
W2: L’Utente non ricorda il proprio username.
EH2: L’Utente fornisce i propri dati anagrafici e il suo account viene individuato.
ASSUMPTIONS: L’Utente possiede un account presso la fumetteria.
E1E1
E2E2
E3E3
E4E4
W2W2W3W3
Inizio
Fine
E5E5
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
UTENTE WEB SERVER ARCHIVIOUTENTI
E1: L’Utente richiede l’eliminazione.E2: L’Utente fornisce il proprio username.E3: Il Gestore accede all’area Utenti.E4: Il Gestore elimina l’account.E5: Il Web Server aggiorna gli archivi.
E1
E2 E3
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
WHO: Utente, Web Server, Gestore.
WHAT: Gestione tornei.
WHEN: In occasione di ogni torneo.
HOW:
Episodio 2.1: Creazione torneo;
Episodio 2.2: Iscrizione dell’Utente al torneo;
Episodio 2.3: Cancellazione torneo;
Episodio 2.4: Modifica data torneo;
Episodio 2.5: Inserimento/modifica classifica.
WHAT CAN GO WRONG:
Sono specificati in ogni singolo episodio.
E2.1E2.1
E2.2E2.2
E2.3E2.3 E2.4E2.4
E2.5E2.5
Fine
InizioLa fumetteria organizza regolarmente tornei di vari giochi, a cui gli utenti registrati possono iscriversi online. Le classifiche dei tornei vengono tenute in memoria per un anno.
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
WHO: Web Server, Gestore.
WHAT: Creazione di un torneo.
WHEN: 24 ore su 24.
HOW:
A1: Gestore accede alla sezione tornei.
A2: Inserimento dati torneo.
A3: Il Web Server aggiorna l’Archivio Tornei.
WHAT CAN GO WRONG:
W1: Data non valida.
EH1: Reinserimento dati.
ASSUMPTIONS: Web Server funzionante.
A1A1
A2A2
W1W1
Fine
Inizio
A3A3
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
GESTORE WEB SERVER ARCHIVIOTORNEI
A1 Gestore accede alla sezione tornei.
A2 Inserimento dati torneo.
A3 Il Web Server aggiorna l’Archivio Tornei.
A1
A2 A3
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
WHO: Utente, Web Server.
WHAT: Iscrizione dell’Utente ad un torneo.
WHEN: 24 ore su 24.
HOW:
B1: L’Utente accede al sito.
B2: L’Utente accede alla sezione Tornei.
B3: Il Web Server recupera i dati dall’archivio e li presenta all’Utente.
B4: L’Utente si iscrive ad un torneo.
B5: Il Web Server aggiorna l’Archivio Tornei.
WHAT CAN GO WRONG:
W1: L’Utente non ha ancora effettuato il login.
EH1: L’Utente effettua il login.
W2: L’Utente non trova tornei che gli interessino.
ASSUMPTIONS: Web Server funzionante
B1B1
B3B3
W1W1
Fine
Inizio
B4B4
B2B2
W2W2
B5B5
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
GESTORE WEB SERVER ARCHIVIOTORNEI
B1: L’Utente accede al sito.
B2: L'Utente accede alla sezione Tornei.
B3: Il Web Server recupera i dati dall’archivio e li presenta all’Utente.
B4: L’Utente si iscrive.
B5: Il Web Server aggiorna l’Archivio Tornei.
B4B5
B3
B1
B3
B2
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
WHO: Gestore, Web Server.
WHAT: Cancellazione di un torneo.
WHEN: 24 ore su 24.
HOW:
C1: Il Gestore accede alla sezione tornei.
C2: Il Gestore cancella il torneo.
C3: Il Web Server aggiorna l’Archivio Tornei.
ASSUMPTIONS: Web Server funzionante.
C1C1
C2C2
Fine
Inizio
C3C3
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
GESTORE WEB SERVER ARCHIVIOTORNEI
C1: Il Gestore accede alla sezione Tornei.
C2: Il Gestore cancella il torneo.
C3: Il Web Server aggiorna l’Archivio Tornei.
C1
C2 C3
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
WHO: Gestore, Web Server.
WHAT: Modifica data di un torneo.
WHEN: 24 ore su 24.
HOW:
D1: Il Gestore accede alla sezione Tornei.
D2: Il Gestore inserisce la nuova data.
D3: Il Web Server aggiorna l’Archivio Tornei.
WHAT CAN GO WRONG:
W1: Data non valida.
EH1: Il Gestore reinserisce la data.
ASSUMPTIONS: Web Server funzionante.
D1D1
D2D2
Fine
Inizio
D3D3
W1W1
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
GESTORE WEB SERVER ARCHIVIOTORNEI
D1: Gestore accede alla sezione tornei
D2: Gestore modifica il torneo
D3: Il Web Server aggiorna l’Archivio Tornei.
D1
D2 D3
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
WHO: Gestore, Web Server.
WHAT: Inserimento/modifica classifica.
WHEN: 24 ore su 24.
HOW:
E1: Il Gestore accede alla sezione tornei.
E2: Il Gestore visualizza la classifica (eventualmente vuota) del torneo.
E3: Il Web Server recupera i dati dall’archivio e li presenta al Gestore.
E4: Il Gestore inserisce le posizioni dei partecipanti.
E5: Il Web Server aggiorna l’Archivio Tornei.
ASSUMPTIONS: Web Server funzionante.
E1E1
E2E2
Fine
Inizio
E3E3
E4E4
E5E5
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
GESTORE WEB SERVER ARCHIVIOTORNEI
E1: Il Gestore accede alla sezione tornei.
E2: Il Gestore visualizza la classifica (eventualmente vuota) del torneo.
E3: Il Web Server recupera i dati dall’archivio e li presenta al Gestore.
E4: Il Gestore inserisce le posizioni dei partecipanti.
E5: Il Web Server aggiorna l’Archivio Tornei.
E1
E2
E3
E4
E5
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
Il Cliente può acquistare i prodotti della fumetteria dal sito, prenotandoli e specificando il metodo di pagamento. Una volta effettuato il pagamento, i prodotti gli verranno consegnati.
WHO: Utente, Web Server, Gestore.
WHAT: L’Utente effettua un acquisto online.
WHEN: A seconda dello specifico episodio.
HOW:• Episodio 3.1: Prenotazione prodotti online;• Episodio 3.2: Pagamento e consegna prodotti.
WHAT CAN GO WRONG: Il cliente può recedere dall’acquisto.
E3.1E3.1
E3.2E3.2
Inizio
Fine
W3.1W3.1
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
WHO: Utente, Web Server.
WHAT: Ricerca prodotti, inserimento nel carrello e ordinazione.
WHEN: 24 ore su 24.
HOW: A1: L’Utente accede alla sezione Acquisti. A2: L’Utente inserisce i dati per la ricerca. A3: Il Web Server effettua la ricerca e presenta i risultati all’utente. A4: L’Utente inserisce i prodotti nel carrello. A5: L’Utente conferma la lista di prodotti. A6: L’Utente inserisce il metodo di pagamento. A7: L’Utente conferma l’acquisto. A8: Il Web Server aggiorna gli archivi Vendite e Prodotti.
WHAT CAN GO WRONG: W1: Il prodotto ricercato non c’è o non è disponibile. EH1: La ricerca verrà effettuata in un secondo momento. W2: L’Utente non ha ancora effettuato il login. EH2: L’Utente effettua il login e ritorna alla pagina di ricerca. W3: La quantità specificata non è più disponibile. EH3: L’Utente diminuisce la quantità dei prodotti. W4: Problemi di connessione. EH4: L’Utente prova a connettersi in un secondo momento.
ASSUMPTIONS: L’Utente deve essere registrato come clientee il suo account deve essere valido.
Inizio
Fine
A1A1 A2A2
A4A4 A3A3
A5A5
W4W4
W1W1W2W2
W3W3
A6A6
A7A7A8A8
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
UTENTE WEB SERVER
ARCHIVIOVENDITE
ARCHIVIOPRODOTTI
A1
A2
A3
A4
A5
A6
A7
A8
A8
A1 L’Utente accede alla sezione Acquisti.
A2 L’Utente inserisce i dati per la ricerca.
A3 Il Web Server effettua la ricerca e presenta i risultati all’utente.
A4 L’Utente inserisce i prodotti nel carrello.
A5 L’Utente conferma la lista di prodotti.
A6 L’Utente inserisce il metodo di pagamento.
A7 L’Utente conferma l’acquisto.
A8 Il Web Server aggiorna gli archivi Vendite e Prodotti.
A3
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
Inizio
Fine
B1B1
B2B2
B4B4
W1W1
WHO: Utente, Gestore, Web Server.
WHAT: Pagamento e consegna merci acquistate.
WHEN: Dopo aver effettuato l’ordinazione online.
HOW:
B1: L’Utente effettua il pagamento con il metodo da lui scelto.
B2: Il Gestore registra la vendita dei prodotti.
B3: Il Web Server aggiorna gli archivi Vendite e Prodotti.
B4: I prodotti vengono consegnati all’utente.
WHAT CAN GO WRONG:
W1: L’Utente recede dall’acquisto o non effettua il pagamento entro i termini.
EH1: Se necessario l’account dell’Utente viene sospeso.
ASSUMPTIONS: Il terminale del Gestore è funzionante.
B3B3
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
UTENTE GESTORE WEB SERVER
ARCHIVIOVENDITE
ARCHIVIOPRODOTTI
B1
B2
B3
B3B4
B1 L’Utente effettua il pagamento con il metodo da lui scelto.
B2 Il Gestore registra la vendita dei prodotti.
B3 Il Web Server aggiorna gli archivi Vendite e Prodotti.
B4 I prodotti vengono consegnati all’utente.
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
Il Gestore può tenere un archivio dei propri fornitori e degli acquisti effettuati da questi, memorizzando i vari prodotti e il loro prezzo di acquisto
WHO: Gestore, Web Server.
WHAT: Registrazione nel database di un acquisto da un fornitore.
WHEN: Ogni volta che viene effettuato un approvvigionamento.
HOW: Episodio 4.1: Inserimento dei prodotti e registrazione .
E4.1E4.1
Inizio
Fine
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
WHO: Gestore, Web Server.
WHAT: Registrazione nel database di un acquisto da un fornitore.
WHEN: Ogni volta che viene effettuato un approvvigionamento.
HOW:• A1: Il Gestore accede alla sezione Acquisti.• A2: SE il fornitore non è presente in archivio viene inserito.• A3: Il Gestore specifica la partita IVA del fornitore.• A4: Il Gestore inserisce i prodotti acquistati.• A5: Il Gestore registra l’acquisto.• A6: Il Web Server aggiorna gli archivi Acquisti e Prodotti.
WHAT CAN GO WRONG:• W1: Il Gestore inserisce un prodotto errato. EH1: Il prodotto viene rimosso.
ASSUMPTIONS: Il Gestore ha concluso l’acquisto e il suo terminale è funzionante.
A1A1
Inizio
Fine
A2A2
A3A3
A4A4
A5A5
A6A6
W1W1
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
GESTORE WEB SERVERARCHIVIOACQUISTI
ARCHIVIOPRODOTTI
A1 Il Gestore accede alla sezione Acquisti.A2 Il fornitore viene inserito in archivio.A3 Il Gestore specifica la partita IVA del fornitore.A4 Il Gestore inserisce i prodotti.A5 Il Gestore registra l’acquisto.A6 Il Web Server aggiorna la gli archivi Acquisti e Prodotti.
ARCHIVIOFORNITORI
A1
A2
A3
A4
A5
A6
A6
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
L’Entity Relation Model è un diagramma utilizzato per descrivere le
relazioni esistenti tra le diverse entità.
I suoi elementi costitutivi sono:
• Strutture dati o ENTITA’, classi di oggetti con proprietà comuni
ed esistenza autonoma;
• RELAZIONI, legami logici fra entità.
Ogni entità possiede degli attributi, fra cui un identificatore che la
individua univocamente. Le relazioni hanno una cardinalità, che
indica quante volte ogni entità possa prendere parte alla relazione.
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
FORNITORI
UTENTI
PRODOTTI
Acquisti
Vendite
F1 F2
A4A3
A1
A2
P1
P2
P3
P4
P5
V2V1
V6
V5
V3 V4U1 U2
U3
U3a
U3b
U3d
U3c U3e
U3f
U3g
(0, N)
(1, N)
(0, N)
(0, N)
TORNEI
PartecipanoP1(0, N)
(0, N)
T1
T2
T3 T4 T5
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
F1: Partita IVA
F2: Nome
FORNITORI
UTENTI
PRODOTTI
Acquisti
Vendite
F1 F2
A4A3
A1
A2
P1
P2
P3
P4
P5
V2V1
V6
V5
V3 V4
U3
U3a
U3b
U3d
U3c U3e
U3f
U3g
(0, N)
(1, N)
(0, N)
(0, N)
TORNEI
PartecipanoP1(0, N)
(0, N)
T1
T2
T3 T4 T5
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
A1: ID acquisto
A2: Data
A3: Quantità
A4: Costo unitario
U1 U2
FORNITORI
UTENTI
PRODOTTI
Acquisti
Vendite
F1 F2
A4A3
A1
A2
P1
P2
P3
P4
P5
V2V1
V6
V5
V3 V4
U3
U3a
U3b
U3d
U3c U3e
U3f
U3g
(0, N)
(1, N)
(0, N)
(0, N)
TORNEI
PartecipanoP1(0, N)
(0, N)
T1
T2
T3 T4 T5
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
P1: Nome
P2: Descrizione
P3: Tipo
P4: Costo
P5: Disponibilità
FORNITORI
UTENTI
PRODOTTI
Acquisti
Vendite
F1 F2
A4A3
A1
A2
P1
P2
P3
P4
P5
V2V1
V6
V5
V3 V4
U3
U3a
U3b
U3d
U3c U3e
U3f
U3g
(0, N)
(1, N)
(0, N)
(0, N)
TORNEI
PartecipanoP1(0, N)
(0, N)
T1
T2
T3 T4 T5
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
V1: ID vendita
V2: Data di apertura
V3: Data di chiusura
V4: Metodo di pagamento
V5: Costo unitario
V6: Quantità
FORNITORI
UTENTI
PRODOTTI
Acquisti
Vendite
F1 F2
A4A3
A1
A2
P1
P2
P3
P4
P5
V2V1
V6
V5
V3 V4
U3
U3a
U3b
U3d
U3c U3e
U3f
U3g
(0, N)
(1, N)
(0, N)
(0, N)
TORNEI
PartecipanoP1(0, N)
(0, N)
T1
T2
T3 T4 T5
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
U1: Username
U2: Password
U3: Dati anagrafici
U3a: NomeU3b: CognomeU3c: Data di nascitaU3d: IndirizzoU3e: CAPU3f: SessoU3g: E-mail
{FORNITORI
UTENTI
PRODOTTI
Acquisti
Vendite
F1 F2
A4A3
A1
A2
P1
P2
P3
P4
P5
V2V1
V6
V5
V3 V4
U3
U3a
U3b
U3d
U3c U3e
U3f
U3g
(0, N)
(1, N)
(0, N)
(0, N)
TORNEI
PartecipanoP1(0, N)
(0, N)
T1
T2
T3 T4 T5
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
P1: Posizione in graduatoria
FORNITORI
UTENTI
PRODOTTI
Acquisti
Vendite
F1 F2
A4A3
A1
A2
P1
P2
P3
P4
P5
V2V1
V6
V5
V3 V4
U3
U3a
U3b
U3d
U3c U3e
U3f
U3g
(0, N)
(1, N)
(0, N)
(0, N)
TORNEI
PartecipanoP1(0, N)
(0, N)
T1
T2
T3 T4 T5
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
T1: Data
T2: Gioco
T3: Nome
T4: Premi
T5: Arbitro
FORNITORI
UTENTI
PRODOTTI
Acquisti
Vendite
F1 F2
A4A3
A1
A2
P1
P2
P3
P4
P5
V2V1
V6
V5
V3 V4
U3
U3a
U3b
U3d
U3c U3e
U3f
U3g
(0, N)
(1, N)
(0, N)
(0, N)
TORNEI
PartecipanoP1(0, N)
(0, N)
T1
T2
T3 T4 T5
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
Il Datastore-Entity Cross Reference associa le entità introdotte nell’ ERM agli archivi introdotti nei DFD, e consente di verificare che tutte le entità siano contenute in almeno un archivio e viceversa che tutti gli archivi contengano almeno una entità.
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
UTENTI TORNEIPartecipano
ArchivioUtenti
ArchivioTornei
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
PRODOTTI UTENTIVendite
ArchivioProdotti
ArchivioVendite
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
FORNITORIAcquisti
ArchivioAcquisti
ArchivioFornitori
PRODOTTI
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
I seguenti diagrammi
mostrano come avviene il
passaggio dalle entità e dalle
relazioni dell’Entity-Relation
Model alle tabelle, che
vengono poi realmente
implementate nella creazione
del Database, su cui vengono
memorizzate le informazioni
del sistema.
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
UTENTI TORNEIPartecipano
CAMPO TIPO
Login Varchar
Cognome Varchar
Nome Varchar
Data di nascita Date
Sesso Char
Codice Postale Char
Indirizzo Varchar
E-mail Varchar
Stato Int
Password Varchar
Utente
CAMPO TIPO
Data Datetime
Gioco Varchar
Login Varchar
Posizione Int
CAMPO TIPO
Gioco Varchar
Data Datetime
Nome Varchar
Arbitro Varchar
Premi Varchar
Partecipanti
CAMPO TIPO
Gioco Varchar
Giochi
Tornei
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
UTENTI PRODOTTIVendite
CAMPO TIPO
ID Int
Login Varchar
Data di apertura Date
Data di chiusura Date
CAMPO TIPO
ID Int
Nome Varchar
Costo Int
Quantità Int
CAMPO TIPO
Tipo Varchar
CAMPO TIPO
Modo Varchar
CAMPO TIPO
Nome Varchar
Costo Int
Disponibilità Int
Tipo Varchar
Descrizione Varchar
CAMPO TIPO
ID Int
Login Varchar
Data Date
Modalità di pagamento
Varchar
Modalità di pagamento
ProdottiVendite in Corso Vendite
Vendite Prodotti
Tipi di prodotto
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
CAMPO TIPO
ID Int
Nome Varchar
Costo Int
Quantità Int
CAMPO TIPO
ID Int
Data Date
Partita IVA Varchar
CAMPO TIPO
Partita IVA Varchar
Nome Varchar
Acquisti Prodotti Acquisti Fornitori
FORNITORIPRODOTTI Acquisti
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
L’ Entity Function Matrix è una matrice che collega i processi introdotti nei
DFD con le entità prodotte nell’ERM.
Indica quali diritti hanno i processi sulle varie entità, e permette di verificare
che:
• ciascuna entità venga almeno inserita, letta e infine cancellata;
• non ci siano processi inutili, cioè che non operano su nessun dato.
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
CLIENTI TORNEI PRODOTTI FORNITORI
UTENTE I M R R M R
WEB SERVER
I D M R I D M R I D M R I D R
GESTORE D M R I D M R D M R I D R
I = Insert D = Delete M = Modify R = Read
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
L’Entity Life History è un metodo di descrizione dell’evoluzione dei dati.
Serve a verificare che:
• le istanze delle entità vengano inserite, modificate, lette e quindi cancellate dai processi nei momenti in cui essi ne hanno il diritto (System Security);
• ogni istanza non si trovi mai in uno stato di blocco (deadlock);
• ogni istanza deve prima o poi terminare cioe' deve essere cancellata;
I NODI rappresentano lo stato in cui si trova l’entità; gli ARCHI l’azione che serve a passare da uno stato all’altro e il processo che la compie.
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
CLIENTE
0
0
UTENTE
modifica
UTENTE
inserisce
1
GESTORE
sospende
GESTORE
riattivaGESTORE
legge
GESTORE
legge
elimina
GESTOREelimina
GESTORE
1
Cliente attivo
Cliente sospeso
legge
UTENTE
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
FORNITORE
0
0
inserisce
GESTORE
legge
elimina
GESTORE
Fornitore in archivio
GESTORE
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
PRODOTTO
0
0
inserisce (acquisto)
GESTORE
legge
elimina
GESTORE
Prodotto in magazzino
WEB SERVER
modifica
GESTORE
UTENTE
legge
modifica disponibilità (acquisto/vendita)
WEB SERVER
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
TORNEO
0
0
UTENTE
si iscrive
GESTORE
inserisce
1
GESTORE
legge
GESTORE
legge
elimina
GESTOREelimina
GESTORE
1
Torneo attivo
Torneo svolto
Svolgimento torneo
legge
UTENTEmodifica dataGESTORE
modifica classifica
GESTORE
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
I Process Outline sono tabelle mediante le quali i processi possono essere descritti. Su di esse vengono riportati:
• le entità su cui il processo opera;
• le azioni che il processo esegue sulle entità;
• in quale stato l’entità si trova all’inizio e alla fine del processo;
• i documenti prodotti in uscita.
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
Azione Entità Stato Iniziale Stato Finale Operazione
Registrazione Clienti Stato iniziale 0 Inserimento
Lettura dati Clienti 0 0 Lettura
Modifica dati Clienti 0 0 Modifica
Ricerca tornei Tornei 0 0 Lettura
Ricerca Prodotti Prodotti 0 0 Lettura
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
Azione Entità Stato Iniziale Stato Finale Operazione
Notifica acquisto Prodotti Stato iniziale 0 Inserimento
Modifica disponibilità Prodotti 0 0 Modifica
Eliminazione torneo (dopo 1 anno)
Tornei 1 Stato iniziale Cancellazione
Annullamento iscrizione (sospensione/eliminazione)
Tornei 0 0 Modifica
Annullamento vendita (sospensione/eliminazione)
Prodotti 0 0 Modifica
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
Azione Entità Stato Iniziale Stato Finale Azione
Visione utenti Clienti 0/1 0/1 Lettura
Sospensione Clienti 0 1 Modifica
Riattivazione Clienti 1 0 Modifica
Eliminazione Clienti 0/1 Stato iniziale Cancellazione
Inserimento Fornitori Stato iniziale 0 Inserimento
Visione fornitori Fornitori 0 0 Lettura
Eliminazione Fornitori 0 Stato iniziale Cancellazione
Visione prodotti Prodotti 0 0 Lettura
Modifica costo/descrizione
Prodotti 0 0 Modifica
Creazione torneo Tornei Stato iniziale 0 Inserimento
Visione tornei Tornei 0/1 0/1 Lettura
Modifica data Tornei 0 0 Modifica
Annullamento torneo Tornei 0 Stato iniziale Cancellazione
Modifica classifica Tornei 1 1 Modifica
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
Gli automi sono dei diagrammi che permettono di descrivere ogni processo nella sua individualità.
Ogni stato del processo e collegato ad un altro tramite degli ARCHI, che rappresentano gli ingressi e le uscite di ogni stato e i motivi della transizione.
Gli automi permettono di valutare che un processo sia:
• Live – sia produttivo;
• Safe – possa tornare allo stato iniziale senza stati di blocco (deadlock).
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
UTENTE
WEB SERVER
GESTORE
0 2
3
1i / I1
i / I2
O1 / I4
O2 / I5
i / --
i / I3
O3 / I5
01
2
O1 / I1
O3 / I3
O2 / I2
O4 / I4
0 2
3
1
4
i / I6
i / I1 i / I2
O3 / I5 O4 / --
O2 / I4
O1 / I3
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
UTENTE
WEB SERVER
GESTORE
S0 Stato iniziale[utente nel sito]
S1 Utente registrato
S2 Utente prenotato
S3 Utente in fumetteria
S4 Svolgimento torneo
O1 richiesta identificazioneO2 ora inizio torneoO3 fine sfide per l’utenteO4 data torneo
I1 invia datiI2 invia dati prenotazioneI3 dati prenotazioneI4 inizia torneoI5 finisce torneoI6 ritiro torneo
0 2
3
1i / I1
i / I2
O1 / I4
O2 / I5
i / --
i / I3
O3 / I5
01
2
O1 / I1
O3 / I3
O2 / I2
O4 / I4
0 2
3
1
4
i / I6
i / I1 i / I2
O3 / I5 O4 / --
O2 / I4
O1 / I3
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
UTENTE
WEB SERVER
GESTORE
S0 Stato iniziale [attesa]
S1 Processamento dati
S2 Accesso al database
I1 Dati ricevuti
I2 Invio dati ricevuti
I3 Messaggio d’errore
I4 Messaggio di conferma/dati recuperati dal database
O1 Riceve comando
O2 Comando valido
O3 Errore
O4 Operazioni riuscite
0 2
3
1i / I1
i / I2
O1 / I4
O2 / I5
i / --
i / I3
O3 / I5
01
2
O1 / I1
O3 / I3
O2 / I2
O4 / I4
0 2
3
1
4
i / I6
i / I1 i / I2
O3 / I5 O4 / --
O2 / I4
O1 / I3
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
UTENTE
WEB SERVER
GESTORE
S0 Stato iniziale
S1 Torneo creato
S2 Svolgimento torneo
S3 Inserimento/modifica classifica
I1 Invia dati torneoI2 Modifica data torneoI3 Cancella torneoI4 Attende partecipantiI5 Immette classificaI6 Modifica classifica
O1 Inizio torneoO2 Fine sfide torneoO3 Errore nella classifica
0 2
3
1i / I1
i / I2
O1 / I4
O2 / I5
i / --
i / I3
O3 / I5
01
2
O1 / I1
O3 / I3
O2 / I2
O4 / I4
0 2
3
1
4
i / I6
i / I1 i / I2
O3 / I5 O4 / --
O2 / I4
O1 / I3
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
Le reti di Petri sono un’estensione degli automi a stati finiti, sono un formalismo grafico; esse sono caratterizzate da:
• Un insieme di POSTI, che possono contenere o no un token;
• Un insieme di TRANSIZIONI;
• Un insieme di FLUSSI.
Un posto é uno stato parziale della rete; lo stato della rete è dato dall’unione di più stati parziali ed indipendenti.
Una transizione é una modifica di alcuni stati parziali (evento); può avere uno o più posti sia input che in output, e può evolvere solo quando ogni posto in input è marcato (cioè possiede un token). Tramite i flussi la rete indica quali transizioni sono possibili, gli stati di partenza e gli stati di arrivo: quando una transizione scatta, i token passano dai relativi posti di input ai posti di output. Non si hanno soltanto transizioni mutuamente esclusive; queste possono essere anche contemporanee.
Ogni marcatura definisce uno stato del sistema: lo stato iniziale è determinato dalla marcatura iniziale. Con questo formalismo possiamo modellare anche eventi paralleli che cambiano contemporaneamente parti diverse del sistema, e studiarne safety e liveness.
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
00 i
C
1 1
P
0
0
Stato iniziale cliente
Stato iniziale WS
i L’utente desidera effettuare un acquisto
C L’utente ricerca i prodottiP Il Web Server restituisce il risultato
2
no
no Il cliente non è soddisfatto della ricercaCliente e Web Server tornano allo stato iniziale
sì
Il cliente è soddisfatto della ricercasì Il cliente visualizza il risultato2 Il cliente visualizza il carrello3
3
Il cliente decide di inserire/rimuovere un prodottoi/r
i/r
La richiesta viene inviata al Web Server
I/R
I/R
R
Il Web Server accetta/rifiuta la richiesta e ritorna in attesa di input
R
4
ok
Il cliente ha inserito tutti i prodottiok
OK
Il cliente conferma la lista dei prodottiOK
2
CC
Il Web Server chiede il metodo di pagamento e la conferma dell’acquisto
CC
5a
Il cliente cambia idea e annulla l’acquisto
a
A
Il cliente torna indietro alla pagina di ricerca
A Il cliente conferma l’acquistoc
c
6
C
Il cliente invia la confermaC
3
Alcuni dei prodotti non sono più disponibili
no
no
NO
Il Web Server lo notifica e il cliente torna alla pagina di ricerca
NO
sì
I prodotti sono disponibilisì aggIl Web Server aggiorna il databaseaggSI’
Il Web Server comunica l’aggiornamento e torna allo stato iniziale
SI’
Il cliente torna allo stato iniziale
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
Lo scopo del dimensionamento è calcolare il tempo di servizio Ts e il tempo di risposta Tr del sistema informativo, e verificare se siano o no adatti alle esigenze dei suoi utenti.
Il sistema è costituito da:
• un Web Server connesso ad Internet 24 ore su 24 tramite una linea ADSL, che gestisce le richieste degli utenti relative alla gestione dell’account, all’iscrizione ai tornei e alla vendita online;
• il Gestore della fumetteria, che effettua le vendite al banco registrandole tramite il proprio terminale (che comunica anch’esso con il Web Server tramite WAN).
HDCPUWANCLIENTI
GESTORESERVER
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
Supponiamo che il sistema sia di tipo M/M/1, cioè:
• le richieste di accesso al sistema siano di tipo Poissoniano, cioè abbiano una distribuzione nel tempo di tipo esponenziale;
• i tempi di servizio del sistema siano anch’essi di tipo Poissoniano;
• vi sia un solo servente (nello specifico il nostro Web Server).
Per il teorema di Jackson possiamo dedurre che anche i flussi di dati uscenti hanno distribuzione esponenziale.Per semplicità studieremo il sistema nel periodo della giornata di maggior traffico, cioè nelle 10 ore in cui la fumetteria è aperta (supponendo che apra alle 8:00 e chiuda alle 20:00, con 2 ore di pausa-pranzo, è possibile considerare ridotto il traffico al di fuori dell’orario di apertura).
Poiché il volume di traffico generato dalle operazioni di gestione è irrilevante rispetto a quello generato dalle richieste degli utenti, tali operazioni possono essere considerate trascurabili ai fini del dimensionamento.
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
Consideriamo che, in un lasso di tempo totale di 10 ore = 600 minuti, vi siano:
• ~ 60 vendite al banco;
• ~ 200 accessi al sito per ricerche, acquisti, ecc..
Il flusso totale in ingresso al server sarà quindi:
λgestore = 60/600 min = 0.1 accessi/min = 0.0017 accessi/sec
λesterna = 200/600 min = 0.33 accessi/min = 0.006 accessi/sec
λtot = λgestore + λesterna = 0.43 accessi/min = 0.0077 accessi/sec
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
Per calcolare il tempo di risposta del Web Server dobbiamo considerare:
• tempo di risposta della WAN Tr_WAN;
• tempo di risposta della CPU Tr_CPU;
• tempo di risposta dell’hard disk Tr_HD.
Per il teorema di Jackson avremo λWAN = λCPU = λHD = λtot.
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
Calcolo di Tr_WAN
Considerando che la velocità della connessione sia di 4 Mbps e che il path length sia di 4 KB; il tempo di servizio sarà:
Ts_WAN = (path length)/VWAN = 4 * 8 * 1024 / (4 * 106) = 0.008 secondi.
Il coefficiente di utilizzazione della WAN sarà quindi:
ρWAN = Ts_WAN * λWAN = 0.006 % << ρcritico = 30 %.
e il tempo di risposta Tr_WAN:
Tr_WAN = Ts_WAN / (1 - Ts_WAN * λWAN ) 0.008 secondi.
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
Calcolo di Tr_CPU
Assumendo un path length di 200000 istruzioni e che la CPU del server sia in grado di eseguire 40 MIPS (Millions of Instructions Per Second), otterremo:
Ts_CPU = (path length) / IPS = 200 * 103 / (40 * 106) = 0.005 secondi.
da cui si ricava:
ρCPU = Ts_CPU * λCPU = 0.036 % << ρcritico e:
Tr_CPU = Ts_CPU / (1 - Ts_CPU * λCPU ) 0.005 secondi.
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
Calcolo di Tr_HD
Considerando le prestazioni di un HD di nuova generazione, avremo:
• Tempo d’accesso: Tseek = 0,006 sec
• Tempo di rotazione: Trot = 0,008 secondi ( 7200 RPM )
• Velocità di trasferimento: 30 MB/sec
• Dati da trasferire = 1024 byte
da cui:
Ts_HD = Tseek + Trot / 2 + dati / Vtrasf = 0.01 secondi
ρHD = Ts_HD * λHD = 0.073 % << ρcritico
Tr_CPU = Ts_CPU / (1 - Ts_CPU * λCPU ) 0.01 secondi.
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
Possiamo quindi calcolare il tempo di risposta totale:
Tr = 2 * Tr_WAN + Tr_CPU + Tr_HD = 0.031 secondi.
Per il teorema di Jackson, in un sistema M/M/1 il tempo di risposta nel 95% dei casi è pari a:
T95% = 3 * Tr = 0.093 secondi.
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
Analizziamo infine il tempo di risposta nel caso delle vendite al banco.
Il tempo di servizio sarà la somma dei tempi parziali:
• Richiesta verbale: T1 = 10 sec
• Controllo archivio T2 = 15 sec
• Inserimento dati T3 = 50 sec
• Saldo T4 = 30 sec
Ts = 105 secondi.
ρ = Ts * λ = 17.85 % << ρcritico
Tr = Ts / (1 - Ts * λ) = 127.8 secondi 2 minuti.
T95% = 3 * Tr = 383.4 secondi 6-7 minuti.
Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5
Concludendo, siamo in grado di affermare che le prestazioni del sistema sono ottimali, in quanto:
• I tempi di risposta hardware sono ben al di sotto del secondo;
• I coefficienti di utilizzo sono tutti abbondantemente al di sotto del valore critico ρ=30%
• Il tempo di risposta medio e quello nel 95 % dei casi sono ampiamente ragionevoli, nel caso dell’accesso diretto al Web Server come nel caso della vendita al banco;
• Considerando che attualmente il taglio minimo di un disco rigido è oltre 20 GB, non ci sono problemi di dimensionamento dell’hard disk.