Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5 Università degli Studi di Catania Facoltà di Ingegneria CdL in Ingegneria Informatica – A.A. 2006/07 Prof. Ing. Alberto Faro Realizzato da: Bannò Filippo Carobene Elena Di Martino Vincenzo

Copyright 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.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.5 Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5 Il progetto consiste nella realizzazione e nellanalisi 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 lacquisto di prodotti online, liscrizione ai tornei ed il mantenimento sul server di un profilo con carriera, acquisti in corso e conclusi; 2. Servizi dedicati al gestore, quali lorganizzazione dei tornei, lamministrazione 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.5 Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5 Lanalisi dei Templates e la rap- presentazione mediante casi duso 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.5 Copyright 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.1 E1.2 E1.3 Inizio Fine E1.5 E1.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 laccount in caso di comportamento scorretto dellutente, o, dietro richiesta di questultimo, 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: LUtente accede alla pagina di registrazione. A2: LUtente inserisce i propri dati. A3: Il Web Server verifica la validità dei dati inseriti. A4: Il Web Server inserisce i dati nellarchivio. A5: Il Web Server notifica lavvenuto inserimento. WHAT CAN GO WRONG: W1: LUtente inserisce dati non validi o incompleti. EH1: LUtente inserisce di nuovo i dati. W2: Problemi di connessione. EH2: LUtente prova a riconnettersi. ASSUMPTIONS: Web Server funzionante. A1 A2 A3 A4 W1 W2 Inizio Fine A5

Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5 UTENTEWEB SERVER ARCHIVIO UTENTI A1 LUtente accede alla pagina di registrazione. A2 LUtente inserisce i propri dati. A3 Il Web Server verifica la validità dei dati inseriti. A4 Il Web Server inserisce i dati nellarchivio. A5 Il Web Server notifica lavvenuto inserimento. A1 A2A4 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: LUtente effettua il login. B2: LUtente accede al profilo. B3: Il Web Server ricerca i dati nellarchivio. B4: Il Web Server visualizza i dati dellutente. B5: LUtente inserisce i nuovi dati. B6: Il Web Server verifica la validità dei dati inseriti. B7: Il Web Server aggiorna lArchivio Utenti. B8: Il Web Server conferma lavvenuta modifica. WHAT CAN GO WRONG: W1: LUtente inserisce username e password errati. EH1: Lutente reinserisce username e password. W2: Lutente inserisce dati non validi. EH3: Reinserimento dati. W3: Problemi di connessione. EH4: LUtente prova a riconnettersi. ASSUMPTIONS: Il Web Server è funzionante e lUtente possiede un account valido. Fine Inizio B1 B2 B4 B3 B5 W2 W3 B6 B7 B8 W1

Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5 UTENTEWEB SERVER ARCHIVIO UTENTI B1: LUtente effettua il login. B2: LUtente accede al profilo. B3: Il Web Server ricerca i dati nellarchivio. B4: Il Web Server visualizza i dati dellutente. B5: LUtente inserisce i nuovi dati. B6: Il Web Server verifica la validità dei dati inseriti. B7: Il Web Server aggiorna lArchivio Utenti. B8: Il Web Server conferma lavvenuta modifica. B1 B2B3 B4 B5B7 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 dellaccount Utente. WHEN: 24 ore su 24. HOW: C1: Il Gestore accede alla sezione Utenti. C2: Il Gestore sospende laccount. C3: Il Web Server aggiorna gli archivi. ASSUMPTIONS: Il Web Server è funzionante e il Gestore ha accesso al sito; lUtente ha violato il regolamento della fumetteria. C1 C2 C3 Inizio Fine

Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5 UTENTEWEB SERVER ARCHIVIO UTENTI C1: Il Gestore accede alla sezione Utenti. C2: Il Gestore sospende laccount. C3: Il Web Server aggiorna gli archivi. C1 C2C3 ARCHIVIO TORNEI ARCHIVIO VENDITE 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 dellaccount Utente. WHEN: 24 ore su 24. HOW: D1: Il Gestore accede alla sezione Utenti. D2: Il Gestore riattiva laccount. D3: Il Web Server aggiorna lArchivio Utenti. ASSUMPTIONS: Il Web Server è funzionante e il Gestore ha accesso al sito; lUtente ha regolarizzato la propria posizione presso il Gestore. D1 D2 D3 Inizio Fine

Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5 UTENTEWEB SERVER ARCHIVIO UTENTI D1: Il Gestore accede alla sezione Utenti. D2: Il Gestore riattiva laccount. D3: Il Web Server aggiorna lArchivio Utenti. D1 D2D3

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 dellaccount Utente WHEN: Durante lorario di apertura della fumetteria. HOW: E1: LUtente richiede leliminazione. E2: LUtente fornisce il proprio username. E3: Il Gestore accede allarea Utenti. E4: Il Gestore elimina laccount. E5: Il Web Server aggiorna gli archivi. WHAT CAN GO WRONG: W1: Il terminale del gestore non è funzionante. EH1: LUtente lascia i propri dati affinché il Gestore elimini laccount non appena possibile. W2: LUtente non ricorda il proprio username. EH2: LUtente fornisce i propri dati anagrafici e il suo account viene individuato. ASSUMPTIONS: LUtente possiede un account presso la fumetteria. E1 E2 E3 E4 W2 W3 Inizio Fine E5

Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5 UTENTEWEB SERVER ARCHIVIO UTENTI E1: LUtente richiede leliminazione. E2: LUtente fornisce il proprio username. E3: Il Gestore accede allarea Utenti. E4: Il Gestore elimina laccount. E5: Il Web Server aggiorna gli archivi. E1 E2E3

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 dellUtente 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.1 E2.2 E2.3 E2.4 E2.5 Fine Inizio La 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 lArchivio Tornei. WHAT CAN GO WRONG: W1: Data non valida. EH1: Reinserimento dati. ASSUMPTIONS: Web Server funzionante. A1 A2 W1 Fine Inizio A3

Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5 GESTOREWEB SERVER ARCHIVIO TORNEI A1 Gestore accede alla sezione tornei. A2 Inserimento dati torneo. A3 Il Web Server aggiorna lArchivio 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 dellUtente ad un torneo. WHEN: 24 ore su 24. HOW: B1: LUtente accede al sito. B2: LUtente accede alla sezione Tornei. B3: Il Web Server recupera i dati dallarchivio e li presenta allUtente. B4: LUtente si iscrive ad un torneo. B5: Il Web Server aggiorna lArchivio Tornei. WHAT CAN GO WRONG: W1: LUtente non ha ancora effettuato il login. EH1: LUtente effettua il login. W2: LUtente non trova tornei che gli interessino. ASSUMPTIONS: Web Server funzionante B1 B3 W1 Fine Inizio B4 B2 W2 B5

Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5 GESTOREWEB SERVER ARCHIVIO TORNEI B1: LUtente accede al sito. B2: L'Utente accede alla sezione Tornei. B3: Il Web Server recupera i dati dallarchivio e li presenta allUtente. B4: LUtente si iscrive. B5: Il Web Server aggiorna lArchivio Tornei. B4 B5 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 lArchivio Tornei. ASSUMPTIONS: Web Server funzionante. C1 C2 Fine Inizio C3

Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5 GESTOREWEB SERVER ARCHIVIO TORNEI C1: Il Gestore accede alla sezione Tornei. C2: Il Gestore cancella il torneo. C3: Il Web Server aggiorna lArchivio Tornei. C1 C2C3

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 lArchivio Tornei. WHAT CAN GO WRONG: W1: Data non valida. EH1: Il Gestore reinserisce la data. ASSUMPTIONS: Web Server funzionante. D1 D2 Fine Inizio D3 W1

Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5 GESTOREWEB SERVER ARCHIVIO TORNEI D1: Gestore accede alla sezione tornei D2: Gestore modifica il torneo D3: Il Web Server aggiorna lArchivio Tornei. D1 D2D3

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 dallarchivio e li presenta al Gestore. E4: Il Gestore inserisce le posizioni dei partecipanti. E5: Il Web Server aggiorna lArchivio Tornei. ASSUMPTIONS: Web Server funzionante. E1 E2 Fine Inizio E3 E4 E5

Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5 GESTOREWEB SERVER ARCHIVIO TORNEI E1: Il Gestore accede alla sezione tornei. E2: Il Gestore visualizza la classifica (eventualmente vuota) del torneo. E3: Il Web Server recupera i dati dallarchivio e li presenta al Gestore. E4: Il Gestore inserisce le posizioni dei partecipanti. E5: Il Web Server aggiorna lArchivio 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: LUtente 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 dallacquisto. E3.1 E3.2 Inizio Fine W3.1

Copyright 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.5 WHO: Utente, Web Server. WHAT: Ricerca prodotti, inserimento nel carrello e ordinazione. WHEN: 24 ore su 24. HOW: A1: LUtente accede alla sezione Acquisti. A2: LUtente inserisce i dati per la ricerca. A3: Il Web Server effettua la ricerca e presenta i risultati allutente. A4: LUtente inserisce i prodotti nel carrello. A5: LUtente conferma la lista di prodotti. A6: LUtente inserisce il metodo di pagamento. A7: LUtente conferma lacquisto. 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: LUtente non ha ancora effettuato il login. EH2: LUtente effettua il login e ritorna alla pagina di ricerca. W3: La quantità specificata non è più disponibile. EH3: LUtente diminuisce la quantità dei prodotti. W4: Problemi di connessione. EH4: LUtente prova a connettersi in un secondo momento. ASSUMPTIONS: LUtente deve essere registrato come cliente e il suo account deve essere valido. Inizio Fine A1 A2 A4 A3 A5 W4 W1 W2 W3 A6 A7 A8

Copyright 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.5 UTENTEWEB SERVER ARCHIVIO VENDITE ARCHIVIO PRODOTTI A1 A2 A3 A4 A5 A6 A7 A8 A1 LUtente accede alla sezione Acquisti. A2 LUtente inserisce i dati per la ricerca. A3 Il Web Server effettua la ricerca e presenta i risultati allutente. A4 LUtente inserisce i prodotti nel carrello. A5 LUtente conferma la lista di prodotti. A6 LUtente inserisce il metodo di pagamento. A7 LUtente conferma lacquisto. 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.5 Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5 Inizio Fine B1 B2 B4 W1 WHO: Utente, Gestore, Web Server. WHAT: Pagamento e consegna merci acquistate. WHEN: Dopo aver effettuato lordinazione online. HOW: B1: LUtente 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 allutente. WHAT CAN GO WRONG: W1: LUtente recede dallacquisto o non effettua il pagamento entro i termini. EH1: Se necessario laccount dellUtente viene sospeso. ASSUMPTIONS: Il terminale del Gestore è funzionante. B3

Copyright 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.5 UTENTEGESTOREWEB SERVER ARCHIVIO VENDITE ARCHIVIO PRODOTTI B1 B2 B3 B4 B1 LUtente 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 allutente.

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.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 lacquisto. 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 lacquisto e il suo terminale è funzionante. A1 Inizio Fine A2 A3 A4 A5 A6 W1

Copyright 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.5 GESTOREWEB SERVER ARCHIVIO ACQUISTI ARCHIVIO PRODOTTI 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 lacquisto. A6 Il Web Server aggiorna la gli archivi Acquisti e Prodotti. ARCHIVIO FORNITORI A1 A2 A3 A4 A5 A6

Copyright 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.5 LEntity 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 F1F2 A4 A3 A1 A2 P1 P2 P3 P4 P5 V2V1 V6 V5 V3V4 U1U2 U3 U3a U3b U3d U3c U3e U3f U3g (0, N) (1, N) (0, N) TORNEI Partecipano P1 (0, N) T1 T2 T3T4T5

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 F1F2 A4 A3 A1 A2 P1 P2 P3 P4 P5 V2V1 V6 V5 V3V4 U3 U3a U3b U3d U3c U3e U3f U3g (0, N) (1, N) (0, N) TORNEI Partecipano P1 (0, N) T1 T2 T3T4T5

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 U1U2 FORNITORI UTENTI PRODOTTI Acquisti Vendite F1F2 A4 A3 A1 A2 P1 P2 P3 P4 P5 V2V1 V6 V5 V3V4 U3 U3a U3b U3d U3c U3e U3f U3g (0, N) (1, N) (0, N) TORNEI Partecipano P1 (0, N) T1 T2 T3T4T5

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 F1F2 A4 A3 A1 A2 P1 P2 P3 P4 P5 V2V1 V6 V5 V3V4 U3 U3a U3b U3d U3c U3e U3f U3g (0, N) (1, N) (0, N) TORNEI Partecipano P1 (0, N) T1 T2 T3T4T5

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 F1F2 A4 A3 A1 A2 P1 P2 P3 P4 P5 V2V1 V6 V5 V3V4 U3 U3a U3b U3d U3c U3e U3f U3g (0, N) (1, N) (0, N) TORNEI Partecipano P1 (0, N) T1 T2 T3T4T5

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: Nome U3b: Cognome U3c: Data di nascita U3d: Indirizzo U3e: CAP U3f: Sesso U3g: { FORNITORI UTENTI PRODOTTI Acquisti Vendite F1F2 A4 A3 A1 A2 P1 P2 P3 P4 P5 V2V1 V6 V5 V3V4 U3 U3a U3b U3d U3c U3e U3f U3g (0, N) (1, N) (0, N) TORNEI Partecipano P1 (0, N) T1 T2 T3T4T5

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 F1F2 A4 A3 A1 A2 P1 P2 P3 P4 P5 V2V1 V6 V5 V3V4 U3 U3a U3b U3d U3c U3e U3f U3g (0, N) (1, N) (0, N) TORNEI Partecipano P1 (0, N) T1 T2 T3T4T5

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 F1F2 A4 A3 A1 A2 P1 P2 P3 P4 P5 V2V1 V6 V5 V3V4 U3 U3a U3b U3d U3c U3e U3f U3g (0, N) (1, N) (0, N) TORNEI Partecipano P1 (0, N) T1 T2 T3T4T5

Copyright 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.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.5 Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5 UTENTI TORNEI Partecipano Archivio Utenti Archivio Tornei

Copyright 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.5 PRODOTTI UTENTI Vendite Archivio Prodotti Archivio Vendite

Copyright 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.5 FORNITORI Acquisti Archivio Acquisti Archivio Fornitori PRODOTTI

Copyright 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.5 I seguenti diagrammi mostrano come avviene il passaggio dalle entità e dalle relazioni dellEntity-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.5 Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5 UTENTITORNEI Partecipano CAMPOTIPO LoginVarchar CognomeVarchar NomeVarchar Data di nascitaDate SessoChar Codice PostaleChar IndirizzoVarchar Varchar StatoInt PasswordVarchar Utente CAMPOTIPO DataDatetime GiocoVarchar LoginVarchar PosizioneInt CAMPOTIPO GiocoVarchar DataDatetime NomeVarchar ArbitroVarchar PremiVarchar Partecipanti CAMPOTIPO GiocoVarchar Giochi Tornei

Copyright 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.5 UTENTIPRODOTTI Vendite CAMPOTIPO IDInt LoginVarchar Data di aperturaDate Data di chiusuraDate CAMPOTIPO IDInt NomeVarchar CostoInt QuantitàInt CAMPOTIPO TipoVarchar CAMPOTIPO ModoVarchar CAMPOTIPO NomeVarchar CostoInt DisponibilitàInt TipoVarchar DescrizioneVarchar CAMPOTIPO IDInt LoginVarchar DataDate 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.5 Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5 CAMPOTIPO IDInt NomeVarchar CostoInt QuantitàInt CAMPOTIPO IDInt DataDate Partita IVAVarchar CAMPOTIPO Partita IVAVarchar NomeVarchar Acquisti Prodotti Acquisti Fornitori FORNITORI PRODOTTI Acquisti

Copyright 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.5 L Entity Function Matrix è una matrice che collega i processi introdotti nei DFD con le entità prodotte nellERM. 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.5 Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5 CLIENTITORNEIPRODOTTIFORNITORI UTENTE I M RI M RR MR WEB SERVER I D M R I D R GESTORE D M RI D M RD M RI D R I = InsertD = DeleteM = ModifyR = Read

Copyright 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.5 LEntity Life History è un metodo di descrizione dellevoluzione 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 lentità; gli ARCHI lazione che serve a passare da uno stato allaltro e il processo che la compie.

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

Copyright 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.5 CLIENTE 0 0 UTENTE modifica UTENTE inserisce 1 GESTORE sospende GESTORE riattiva GESTORE legge GESTORE legge elimina GESTORE elimina 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.5 Copyright 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.5 Copyright 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.5 Copyright 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 GESTORE elimina GESTORE 1 Torneo attivo Torneo svolto Svolgimento torneo legge UTENTE modifica data GESTORE modifica classifica GESTORE

Copyright 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.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 lentità si trova allinizio 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.5 Copyright 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.5 Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5 AzioneEntitàStato InizialeStato FinaleOperazione RegistrazioneClientiStato iniziale0Inserimento Lettura datiClienti00Lettura Modifica datiClienti00Modifica Ricerca torneiTornei00Lettura Ricerca ProdottiProdotti00Lettura

Copyright 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.5 AzioneEntitàStato InizialeStato FinaleOperazione Notifica acquistoProdottiStato iniziale0Inserimento Modifica disponibilitàProdotti00Modifica Eliminazione torneo (dopo 1 anno) Tornei1Stato inizialeCancellazione Annullamento iscrizione (sospensione/eliminazione) Tornei00Modifica Annullamento vendita (sospensione/eliminazione) Prodotti00Modifica

Copyright 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.5 AzioneEntitàStato InizialeStato FinaleAzione Visione utentiClienti0/1 Lettura SospensioneClienti01Modifica RiattivazioneClienti10Modifica EliminazioneClienti0/1Stato inizialeCancellazione InserimentoFornitoriStato iniziale0Inserimento Visione fornitoriFornitori00Lettura EliminazioneFornitori0Stato inizialeCancellazione Visione prodottiProdotti00Lettura Modifica costo/descrizione Prodotti00Modifica Creazione torneoTorneiStato iniziale0Inserimento Visione torneiTornei0/1 Lettura Modifica dataTornei00Modifica Annullamento torneoTornei0Stato inizialeCancellazione Modifica classificaTornei11Modifica

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 i / I1 i / I2 O1 / I4 O2 / I5 i / -- i / I3 O3 / I O1 / I1 O3 / I3 O2 / I2 O4 / I 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 identificazione O2 ora inizio torneo O3 fine sfide per lutente O4 data torneo I1 invia dati I2 invia dati prenotazione I3 dati prenotazione I4 inizia torneo I5 finisce torneo I6 ritiro torneo i / I1 i / I2 O1 / I4 O2 / I5 i / -- i / I3 O3 / I O1 / I1 O3 / I3 O2 / I2 O4 / I 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 derrore I4 Messaggio di conferma/dati recuperati dal database O1 Riceve comando O2 Comando valido O3 Errore O4 Operazioni riuscite i / I1 i / I2 O1 / I4 O2 / I5 i / -- i / I3 O3 / I O1 / I1 O3 / I3 O2 / I2 O4 / I 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 torneo I2 Modifica data torneo I3 Cancella torneo I4 Attende partecipanti I5 Immette classifica I6 Modifica classifica O1 Inizio torneo O2 Fine sfide torneo O3 Errore nella classifica i / I1 i / I2 O1 / I4 O2 / I5 i / -- i / I3 O3 / I O1 / I1 O3 / I3 O2 / I2 O4 / I 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 Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5 Le reti di Petri sono unestensione 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 dallunione 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.5 Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons i C 1 1 P 0 0 Stato iniziale cliente Stato iniziale WS i Lutente desidera effettuare un acquisto C Lutente ricerca i prodotti P Il Web Server restituisce il risultato 2 no Il cliente non è soddisfatto della ricercaCliente e Web Server tornano allo stato iniziale sì Il cliente è soddisfatto della ricerca sì Il cliente visualizza il risultato 2 Il cliente visualizza il carrello 3 3 Il cliente decide di inserire/rimuovere un prodotto i/r La richiesta viene inviata al Web Server 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 prodotti ok OK Il cliente conferma la lista dei prodotti OK 2 CC Il Web Server chiede il metodo di pagamento e la conferma dellacquisto CC 5 a Il cliente cambia idea e annulla lacquisto a A Il cliente torna indietro alla pagina di ricerca A Il cliente conferma lacquisto c c 6 C Il cliente invia la conferma C 3 Alcuni dei prodotti non sono più disponibili no NO Il Web Server lo notifica e il cliente torna alla pagina di ricerca NO sì I prodotti sono disponibili sì agg Il Web Server aggiorna il database agg SI Il Web Server comunica laggiornamento 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.5 Copyright 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 T s e il tempo di risposta T r 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 dellaccount, alliscrizione ai tornei e alla vendita online; il Gestore della fumetteria, che effettua le vendite al banco registrandole tramite il proprio terminale (che comunica anchesso con il Web Server tramite WAN). HD CPU WAN CLIENTI GESTORE SERVER

Copyright 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.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 anchessi 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 dellorario 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.5 Copyright 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 = accessi/sec λ esterna = 200/600 min = 0.33 accessi/min = accessi/sec λ tot = λ gestore + λ esterna = 0.43 accessi/min = accessi/sec

Copyright 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.5 Per calcolare il tempo di risposta del Web Server dobbiamo considerare: tempo di risposta della WAN T r_WAN ; tempo di risposta della CPU T r_CPU ; tempo di risposta dellhard disk T r_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.5 Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato sotto licenza Creative Commons 2.5 Calcolo di T r_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à: T s_WAN = (path length)/V WAN = 4 * 8 * 1024 / (4 * 10 6 ) = secondi. Il coefficiente di utilizzazione della WAN sarà quindi: ρ WAN = T s_WAN * λ WAN = % << ρ critico = 30 %. e il tempo di risposta T r_WAN : T r_WAN = T s_WAN / (1 - T s_WAN * λ WAN ) secondi.

Copyright 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.5 Calcolo di T r_CPU Assumendo un path length di istruzioni e che la CPU del server sia in grado di eseguire 40 MIPS (Millions of Instructions Per Second), otterremo: T s_CPU = (path length) / IPS = 200 * 10 3 / (40 * 10 6 ) = secondi. da cui si ricava: ρ CPU = T s_CPU * λ CPU = % << ρ critico e: T r_CPU = T s_CPU / (1 - T s_CPU * λ CPU ) secondi.

Copyright 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.5 Calcolo di T r_HD Considerando le prestazioni di un HD di nuova generazione, avremo: Tempo daccesso: T seek = 0,006 sec Tempo di rotazione: T rot = 0,008 secondi ( 7200 RPM ) Velocità di trasferimento: 30 MB/sec Dati da trasferire = 1024 byte da cui: T s_HD = T seek + T rot / 2 + dati / V trasf = 0.01 secondi ρ HD = T s_HD * λ HD = % << ρ critico T r_CPU = T s_CPU / (1 - T s_CPU * λ CPU ) 0.01 secondi.

Copyright 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.5 Possiamo quindi calcolare il tempo di risposta totale: T r = 2 * T r_WAN + T r_CPU + T r_HD = secondi. Per il teorema di Jackson, in un sistema M/M/1 il tempo di risposta nel 95% dei casi è pari a: T 95% = 3 * T r = secondi.

Copyright 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.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: T 1 = 10 sec Controllo archivio T 2 = 15 sec Inserimento dati T 3 = 50 sec Saldo T 4 = 30 sec T s = 105 secondi. ρ = T s * λ = % << ρ critico T r = T s / (1 - T s * λ) = secondi 2 minuti. T 95% = 3 * T r = secondi 6-7 minuti.

Copyright 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.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 dellaccesso 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 dellhard disk.