Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato...

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


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.


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


Gestione dati utente

Gestione tornei

Vendita ad un utente

Acquisto da fornitore


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.


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


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


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



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


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



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



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



D1: Il Gestore accede alla sezione Utenti.D2: Il Gestore riattiva l’account.D3: Il Web Server aggiorna l’Archivio Utenti.

D1

D2 D3



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



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



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.


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.


A1A1

A2A2

W1W1

Fine

Inizio

A3A3


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



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



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



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.


C1C1

C2C2

Fine

Inizio

C3C3



C1: Il Gestore accede alla sezione Tornei.

C2: Il Gestore cancella il torneo.

C3: Il Web Server aggiorna l’Archivio Tornei.

C1

C2 C3



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.


D1D1

D2D2

Fine

Inizio

D3D3

W1W1



D1: Gestore accede alla sezione tornei

D2: Gestore modifica il torneo

D3: Il Web Server aggiorna l’Archivio Tornei.

D1

D2 D3



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.


E1E1

E2E2

Fine

Inizio

E3E3

E4E4

E5E5



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


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.


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



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


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


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


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.


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


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



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


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


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.


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


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


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


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


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


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


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


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


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


UTENTI TORNEIPartecipano

ArchivioUtenti

ArchivioTornei


PRODOTTI UTENTIVendite

ArchivioProdotti

ArchivioVendite


FORNITORIAcquisti

ArchivioAcquisti

ArchivioFornitori

PRODOTTI


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.


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


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


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


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.


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


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.


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


FORNITORE

0

0

inserisce

GESTORE

legge

elimina

GESTORE

Fornitore in archivio

GESTORE


PRODOTTO

0

0

inserisce (acquisto)

GESTORE

legge

elimina

GESTORE

Prodotto in magazzino

WEB SERVER

modifica

GESTORE

UTENTE

legge

modifica disponibilità (acquisto/vendita)

WEB SERVER


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


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.


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


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


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


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


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


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


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


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


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.


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


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


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.


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


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.


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.


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.


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.


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.


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.


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.

Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato...

Documents

Transcript of Copyright 2007 Filippo Bannò, Elena Carobene, Vincenzo Di Martino. Questo lavoro è rilasciato...