Elaborato Guida Progettazione del Software SW Di Lucca

ATTORE PRIMARIO/SECONDARIO DESCRIZIONE DEL RUOLO

Operatore iTaxi Primario Richiede i dati al Cliente. Gestisce la

prenotazione. Associa il cliente al Taxi in

fase di Prenotazione. Interagisce con il

Tassista.

Banca Secondario Permette di effettuare il pagamento

tramite account bancario

PayPal Secondario Permette di effettuare il pagamento

tramite PayPal

 SCHEMA ATTORI/SISTEMA Pag. | 3

 TABELLA DEI REQUISITI

R1 - Registrazione del Cliente

L’Operatore iTaxi registra le informazioni di Registrazione ottenute dal Cliente

R1.1 F

Il Sistema conferma l’avvenuta registrazione

R1.2 L’Operatore iTaxi riceve il codice univoco di Registrazione e il Codice della TT

R1.3 F

Fidelity Card da fornire al Cliente

L’Operatore iTaxi può annullare su commissione del Cliente la procedura di

R1.4 F

Registrazione in qualsiasi momento

R2 – Prenotazione

L’Operatore iTaxi registra il codice univoco ricevuto dal Cliente

R2.1 F

L’Operatore iTaxi seleziona il Tipo di Itinerario scelto dal Cliente

R2.2 F

L’Operatore iTaxi registra il punto di partenza scelto dal Cliente

R2.3 F

L’Operatore iTaxi registra le scelte del Cliente in merito ai Servizi Speciali

R2.4 F

usufruibili

L’Operatore iTaxi può fornire al Sistema ulteriori informazioni ricevute dal

R2.5 F

Cliente per l’Itinerario di Gruppo

L’Operatore iTaxi associa il Cliente ad un Tassista ,in base a punto di partenza

R2.6 F

desiderato e Servizi Speciali scelti

Il Sistema conferma il successo dell’operazione fornendo le informazioni di

R2.7 F

prenotazione all’Operatore iTaxi

L’Operatore iTaxi può annullare su commissione del Cliente o del Tassista la

R2.8 F

procedura di Prenotazione in qualsiasi momento Pag. | 4

R3 – Corsa

L’Operatore iTaxi registra i dati di Corsa ottenuti dal Tassista.

R3.1 F

L’Operatore iTaxi può registrare il numero di punti della TT Fidelity Card da

R3.2 F

utilizzare per uno sconto su commissione del Cliente

L’Operatore iTaxi registra i dati di Pagamento ricevuti dal Cliente.

R3.3 F

L’Operatore iTaxi può ricevere il responso sulla transazione da parte dei servizi

R3.4 NF

esterni di pagamento

Il Sistema conferma l’avvenuta registrazione della Corsa

R3.5 F

 TABELLA DELLE MACROFUNZIONALITA’

Identificativo Nome Attore Attivante Requisiti interessati

R1.1 , R1.2 , R1.3 ,

MF1 Registrare Cliente Operatore iTaxi R1.4

Effettuare R2.1 , R2.2 , R2.3 ,

MF2 Operatore iTaxi R2.4 , R2.5 , R2.6 ,

Prenotazione R2.7, R2.8

R3.1 , R3.2 , R3.3 ,

MF3 Registrare Corsa Operatore iTaxi R3.4 , R3.5 Pag. | 5

 IDENTIFICAZIONE DEGLI USE CASES

Nome Use Case Registrare Cliente

Descrive il processo di Registrazione del Cliente

Descrizione Il sistema è Operativo , mostra il Form di scelta operazione all’Operatore

Precondizione iTaxi che è registrato nel sistema

Il sistema è Operativo , mostra il Form di scelta operazione all’Operatore

Postcondizione iTaxi che è registrato nel sistema

Operatore iTaxi

Attori Sistema

1. L’Operatore iTaxi sceglie il

Main Scenario Form di Registrazione

Cliente 2. Il Sistema mostra

all’Operatore il Form di

Registrazione

3. L’Operatore iTaxi compila il

Form di Registrazione

inserendo i seguenti dati

del Cliente: nome,

cognome, data di nascita,

luogo di nascita, codice

fiscale, indirizzo email e

recapito telefonico. 4. Il Sistema mostra il Codice

Univoco di Registrazione e il

Codice della TT Fidelity Card

da comunicare al Cliente.

Registra le credenziali

inserite.

A1.*(<4) L’Operatore iTaxi può

Alternative annullare la procedura di

Scenario (A1) Registrazione in qualsiasi Pag. | 6

momento. A2.*(<4) Il Sistema resetta

Alternative l’operazione dopo 10 minuti di

Scenario (A2) inattività.

Nome Use Case Effettuare Prenotazione

Descrive la procedura di Prenotazione

Descrizione Il sistema è Operativo , mostra il Form di scelta operazione all’Operatore

Precondizione iTaxi che è registrato nel sistema

Il sistema è Operativo , mostra il Form di scelta operazione all’Operatore

Postcondizione iTaxi che è registrato nel sistema

Operatore iTaxi

Attori Sistema

1. L’Operatore iTaxi sceglie il

Main Scenario Form di Prenotazione. 2. Il Sistema propone la scelta

del Tipo di Itinerario.

3. L’Operatore iTaxi seleziona il

Tipo di Itinerario Standard

su commissione del Cliente. 4. Il Sistema mostra il Form di

prenotazione per l’Itinerario

Standard .

5. L’Operatore iTaxi introduce

punto di partenza e

seleziona i Servizi Speciali

richiesti dal Cliente. 6. Il Sistema mostra la lista dei

Pag. | 7

Taxi compatibili in base a

punto di partenza e servizi

speciali richiesti.

7. L’Operatore iTaxi sceglie una

soluzione dalla lista. 8. Il Sistema conferma

l’operazione fornendo

all’Operatore iTaxi i dati di

Prenotazione.

A1.3 L’Operatore iTaxi seleziona il

Alternative Tipo di Itinerario di Gruppo su

Scenario (A1) commissione del Cliente. A1.4 Il Sistema mostra il Form di

prenotazione per l’Itinerario di

Gruppo.

A1.5 L’Operatore iTaxi introduce

punto di partenza e seleziona i

Servizi Speciali richiesti dal Cliente.

Introduce i codici dei Clienti invitati

e la destinazione. RITORNO AL MAIN SCENARIO ALLO

STEP 6

A2.8 Il Sistema comunica

Alternative all’Operatore iTaxi che l’operazione

Scenario (A2) non è andata a buon fine.

A3.*(<8) L’Operatore iTaxi può

Alternative annullare la procedura di

Scenario (A3) Prenotazione in qualsiasi momento. Pag. | 8

Nome Use Case Registrare Corsa

Descrive il processo di Registrazione Corsa

Descrizione Il sistema è Operativo , mostra il Form di scelta operazione all’Operatore

Precondizione iTaxi che è registrato nel sistema

Il sistema è Operativo , mostra il Form di scelta operazione all’Operatore

Postcondizione iTaxi che è registrato nel sistema

Operatore iTaxi

Attori Sistema Banca PayPal

1. L’Operatore

Main Scenario iTaxi sceglie il

(M1) Form di

Registrazione

Corsa. 2. Il Sistema

mostra il

Form di

Registrazi

one

Corsa.

3. L’Operatore

iTaxi compila il

Form di

Registrazione

Corsa

introducendo:

punto di

partenza,

destinazione,

km percorsi ,

valore punti

TT Fidelity

Card da usare

per sconto. 4. Il Sistema

mostra il

prezzo Pag. | 9

per la

Corsa

effettuata

in base ai

dati

immessi.

5. L’Operatore

iTaxi seleziona

il pagamento

in Contanti. 6. Il Sistema

conferma

la

registrazi

one ed

emette i

dati di

Fatturazio

ne;

mostra i

punti

maturati

sulla TT

Fidelity

Card dal

Cliente.

A1.5 L’Operatore

Alternative iTaxi seleziona il

Scenario (A1) pagamento tramite

Carta di Credito. A1.6 Il Sistema

chiede validità

delle credenziali

immesse alla

Banca. P a g . | 10

A1.7 La Banca

da un responso

positivo.

RITORNO AL

MAIN

SCENARIO ALLO

STEP 6

A2.5 L’Operatore

Alternative iTaxi seleziona il

Scenario (A2) pagamento tramite

PayPal. A2.6 Il Sistema

chiede validità

delle credenziali

immesse a

PayPal. A2.7 PayPal da

un responso

positivo.

RITORNO AL

MAIN

SCENARIO ALLO

STEP 6

A3.6 Il Sistema

Alternative comunica

Scenario (A3) all’Operatore

iTaxi che

l’operazione

non è andata a

buon fine. P a g . | 11

 DIAGRAMMA dei Casi d’Uso P a g . | 12

 DOMAIN Class Diagram P a g . | 13

 Model View Controller PATTERN (MVC)

CONTESTO:

L’operatore interagisce in maniera diretta con un’interfaccia composta da una

schermata principale ( il main menu ) che permette la scelta delle operazioni da

intraprendere; le operazioni possibili sono 3 ognuna delle quali riporta ad una

schermata relativa per la successiva gestione. I dati dell’utenza sono salvati su una

base di dati permanente e accessibili per le operazioni di routine.

PROBLEMA:

Appare chiaro il bisogno di un’architettura che permetta la separazione tra le

componenti software che interagiscono in modo da garantire le corrette operazioni per

la gestione del servizio .

SOLUZIONE E STRUTTURA:

Si vuole effettuare la separazione delle componenti software che implementano il

modello delle funzionalità più interne ( quelle di business ) da quelle che si

preoccupano della presentazione d’interfaccia e quelle che si preoccupano del

controllo. Le tre componenti che soddisfano i suddetti requisiti sono:



1) il Model che implementa proprio le funzionalità interne ( quelle di business )



2) la View che si preoccupa della presentazione



3) il Controller effettua il controllo

Ognuna delle 3 componenti avrà pertanto una propria responsabilità. P a g . | 14

 ACCESSO AI DATI con PATTERN DAO

CONTESTO:

Il sistema deve poter accedere in modo sistematico alla sorgente dati per interagire con

le informazioni in essa presenti.

PROBLEMA:

Appare chiara una separazione della parte logica applicativa che implementa le

funzionalità del programma dalla parte relativa alla persistenza e all’accesso dati

nell’ambito di una sorgente dati .

SOLUZIONE E STRUTTURA:

Il pattern Data Access Object permette di effettuare tale separazione in maniera

semplificata. Infatti esso implementa il meccanismo di accesso richiesto per lavorare

con la sorgente dei dati: la componente che richiede l’accesso ai dati persistenti si

comporta come “Client”. Il Client utilizza l’interfaccia esposta dal DAO, che nasconde

completamente i dettagli implementativi relativi all’origine dei dati. Il DAO funge

quindi da “ADAPTER” tra la componente CORE legata al programma e la sorgente dei

dati persistenti. Le classi del model che fanno richiesta di accesso al DB, interagiscono

per mezzo del DAO; esse contengono quindi ( implicitamente ) tutte le operazioni

elementari per l’accesso richiesto. P a g . | 15

 DESIGN CLASS DIAGRAM P a g . | 16

 PARTECIPANTI E RESPONSABITA’

 MVC

MODEL: implementa il core del programma; incapsula lo stato dell’applicazione, definisce i dati e le

operazioni che possono essere eseguite su di essi. Espone alla View e al Controller le funzionalità per

l’accesso.

VIEW: si