vuoi
o PayPal
tutte le volte che vuoi
INDIVIDUAZIONE DEI REQUISITI FUNZIONALI
Requisiti funzionali
- Il sistema dovrà gestire operazioni CRUD sugli utenti;
- Il sistema dovrà gestire operazioni CRUD sulle transazioni;
- Il sistema dovrà permettere ai Clienti soltanto la gestione dei propri dati;
- Il sistema dovrà prevedere un meccanismo d'accesso e autenticazione all'area riservata distinta per ruolo dell'utente loggato;
- Il sistema dovrà permettere, ad applicazioni terze, il pagamento di beni e servizi richiamando i suoi web services di tipo REST;
- Il sistema espone un web service di pagamento che a partire da alcuni dati della richiesta, risponde con l'avvenuto pagamento o con il fallimento del pagamento; l'accesso al WEB è sottoposto all'autenticazione dell'utente;
- Deve gestire due tipologie di utenti: utenti convenzionali che acquistano servizi e prodotti ed esercenti che ricevono pagamenti ed effettuano transazioni in uscita verso altri.
- Il sistema avrà due distinte aree private: una per l'utente convenzionale per permettergli di esplorare i propri dati ed eventualmente modificare i dati anagrafici e di Carta di credito;
- All'esercente permette di autorizzare pagamenti dal suo conto ad un altro conto;
- L'utente visitatore, ovvero non registrato e non loggato, non può altro che visitare la homepage e registrarsi al servizio.
Requisiti non funzionali
La progettazione e la realizzazione della Web application prevede il rispetto dei seguenti requisiti non funzionali che potremmo anche sintetizzare come semplificazioni e controlli utili per rispettare i requisiti del progetto.
- Nella Web app PAY STEAM è previsto un unico campo sia per la carta di credito che per il conto corrente;
- Per l'utente con profilo "utente" sarà da considerarsi una carta da 16 cifre, per l'utente con profilo "esercente" sarà da intendersi come IBAN;
modo che possano comunicareinsieme.
WEB Un Web Service facilita l'interazione tra dueSERVICE macchine su una rete. Possiamo semplicementedire che tutti i WEB SERVICES sono API ma non tutteele API sono servizi web. I termini WEB SERVICE APIvengono utilizzati in modo intercambiabile. Tuttavia,le API sono la categoria più ampia. I servizi Websono un tipo speciale di API.
API REST Le richieste REST vengono inviate utilizzando verbiGET POSTHTTP come (Ottieni) e (Pubblica). Lerisposte della REST API sono generalmente in JSON,ma possono anche essere in un formato di datidiverso.
TRANSAZIO Rappresenta l'operazione di pagamento del titolo diNE viaggio sulla piattaforma PAYSTEAMCARTA E' un campo unico che contiene i dati della carta dicredito (16 cifre) dell'utente oppure l'IBAN del contocorrente dell'utente (stringa di 27 caratteri)
CASI D'USOESERCENTE:
- login
- accede ad area privata;
- visualizza i suoi movimenti in uscita;
- modifica i propri
dati personali;
5. modifica o inserisce i dati della carta di credito o dell'IBAN; può autorizzare transazioni in uscita verso altri conti o carte di credito.
6. UTENTE REGISTRATO:
- login
- accede ad area privata;
- visualizza i suoi movimenti in uscita;
- modifica i propri dati personali;
- modifica o inserisce i dati della carta di credito o dell'IBAN;
UTENTE NON REGISTRATO (VISITATORE)
- visita sito internet e accede alle pagine informative;
- si può registrare;
UTENTE M2M (WEB API)
- url inviante, url diespone un servizio che riceve chiamate cosi formattate: risposta, id esercente, id transazione, descrizione del bene, prezzo transazione;
- Risponde alle chiamate con dei messaggi così formattati: url inviante, id transazione, esito transazione (possibili riposte OK, KO).
PROGETTAZIONE CONCETTUALE
La progettazione concettuale ci permette di rappresentare il nostro sistema mediante un insieme di concetti e relazioni tra concetti.
Diagramma
Descrizione delle entità presenti nello schema E/R
Entità: PAY_UTENTE
Rappresenta gli utenti che interagiscono con l'applicazione di pagamento, siano essi utenti utilizzatori della piattaforma o esercenti registrati per poter ricevere pagamenti. Contiene i dati anagrafici, di contatto e dei metodi di pagamento dell'utente. L'attributo email è definito come UNIQUE all'interno della tabella in quanto gli utenti sulla piattaforma non possono avere la stessa mail.
Attributi:
- id_utente
- username
- nome
- cognome
- password
- ruolo
- carta
Entità: PAY_TRANSAZIO
Questa entità è necessaria per poter registrare le transazioni avvenute con successo sulla piattaforma. Contiene i dati di tracciamento della transazione, ovvero l'utente, l'esercente, i dettagli dell'acquisto e un numero univoco che identifica la transazione.
Attributi:
- idNI
- id_cliente
- id_esercente
- id_transazione
descrizionedata Dizionario delle relazioni
Procediamo descrivendo le relazioni.
Relazione Descrizione Entità coinvolte Attributi
EFFETTUA_RIC Necessaria a rappresentare il legame tra i PAY_UTENTE (0,N) / /EVE vari attori dello schema proposto: PAY_TRANSAZIONI(1pay_utente (sia esso esercente che utente) ,1)e pay_transazioni
Dizionario dei vincoli
Descriviamo i vincoli.
Vincolo Regola
V1 Un utente deve registrarsi se vuole utilizzare la piattaforma di pagamento.
V2 Un utente non può controllare i propri dati se non accede all'area riservata.
V3 Non è possibile acquistare se non si registra la carta di credito.
V4 Solo utenti con profilo "esercente" possono effetuare transazioni verso altre IBAN
PROGETTAZIONE LOGICA
Ristrutturazione del modello E/R
Prevede sei trasformazioni da apportare al modello E/R per renderlo compatibile con il modello logico, procediamo con la descrizione delle singole operazioni da
compiere:Analisi delle ridondanzeIn questo caso, non essendo presente alcuna ridondanza, non dobbiamo apportare alcuna modifica al modello E/R.
Eliminazione delle generalizzazioniNel nostro caso non sono presenti generalizzazioni, dunque non è necessario apportare modifiche.
Partizionamento o accorpamento dei concettiNello schema E/R non occorre effettuare partizionamenti o accorpamenti delle entità.
Eliminazione degli attributi multivaloreNel modello logico sussiste l'impossibilità di avere attributi multivalore, quindi, andremo ad eliminare gli attributi di questo tipo presenti per sostituirli con un'entità apposita.
Eliminazione degli attributi compostiNel modello logico sussiste l'impossibilità di avere attributi composti, quindi, andremo ad eliminare gli attributi di questo tipo presenti per sostituirli con attributi semplici.
Scelta degli identificatori principaliNel passaggio al modello relazionale è importante e necessaria la
scelta degli identificatori principali. Traduzione verso il modello logico Adesso dobbiamo esaminare la traduzione verso il modello logico, che nel nostro caso è un modello relazionale, andiamo quindi a tradurre tutte le relazioni. Relazione EFFETTUA_RICEVE (0,N) e (1,1): Questa è un'associazione uno a molti, quindi applicheremo le dovute regole e lo schema relazionale che ne deriva sarà: a. (id, id_cliente, id_esercente, id_transazione, pay_transazione, total_sum, descrizione, data) b. (id_utente, username, nome, cognome, password, ruolo, pay_utente_carta, email) Possiamo quindi definire adesso il vincolo d'integrità referenziale che coinvolge id_utente l'attributo della relazione pay_transazioni e l'attributo id_utente di pay_utente. SCHEMA RELAZIONALE Con le traduzioni apportate per la trasformazione otteniamo il seguente schema relazionale: PAY_TRANSAZIONI Campo Tipo Vincolo Descrizione id int NOT NULL, PRIMARY Identificatore univoco della transazione id_cliente int NOT NULL, FOREIGN KEY Riferimento all'identificatore del cliente id_esercente int NOT NULL, FOREIGN KEY Riferimento all'identificatore dell'esercente id_transazione int NOT NULL, FOREIGN KEY Riferimento all'identificatore della transazione pay_transazione int NOT NULL, FOREIGN KEY Riferimento all'identificatore del pagamento total_sum decimal NOT NULL Importo totale della transazione descrizione varchar(255) NOT NULL Descrizione della transazione data date NOT NULL Data della transazione PAY_UTENTE Campo Tipo Vincolo Descrizione id_utente int NOT NULL, PRIMARY Identificatore univoco dell'utente username varchar(50) NOT NULL Username dell'utente nome varchar(50) NOT NULL Nome dell'utente cognome varchar(50) NOT NULL Cognome dell'utente password varchar(50) NOT NULL Password dell'utente ruolo varchar(50) NOT NULL Ruolo dell'utente pay_utente_carta int NOT NULL, FOREIGN KEY Riferimento all'identificatore della carta di pagamento dell'utente email varchar(100) NOT NULL Email dell'utente| Campo | Tipo | Vincolo | Descrizione |
|---|---|---|---|
| transazioneKEYid_utente | int | NOT NULL | Identificativo dell'utente che ha effettuato la transazione |
| id_esercen | varchar(1) | NOT NULL | Identificativo dell'esercente destinatario dell'operazione economica |
| id_transaz | varchar(2) | UNIQUE | Identificatore unico della transazione, generato a partire dal timestamp e da unione 50 |
| numero | pseudocasuale generato | KEY | E' l'identificativo ritornato all'applicazione chiamante |
| total_sum | decimal(8,0) | NOT NULL | Descrizione del bene acquistato |
| descrizione | varchar(250) | Timestamp della transazione | |
| data | datetime | NOT NULL DEFAULT CURRENT_TIMESTAMP | |
| PAY_UTENTE | |||
| Id_uten | int | UNSIGNED NOT NULL | Identificatore univoco dell'utente |
| varchar(userna | NOT NULL | Username dell'utenza creata, deve essere unico | |
| varchar(nome | NOT NULL | Nome dell'utenza creato | |
| varchar(cognom | NOT NULL | Cognome dell'utenza creato | |
| varchar(passwo |
<input type="password" name="password" required>
NOT NULL Ruolo dell'utenza che può essere utente o esercente
<select name="ruolo" required>
<option value="utente">Utente</option>
<option value="esercente">Esercente</option>
</select>
NOT NULL Stringa che rappresenta o una carta di credito o un Iban
<input type="text" name="carta" required>
NOT NULL, UNIQUE KEY Email di contatto dell'utenza creata. Deve essere unica
<input type="email" name="email" required>
REALIZZAZIONE DELL'APPLICAZIONE
La home si presenta in questo modo ad un utente loggato. Vedrà un menù...
Accedi a tutti gli appunti
Tutor AI: studia meglio e in meno tempo
