VIDEO RENTAL MANAGEMENT SYSTEM
Ingegneria del Software, A.A. 2010 – 2011
Università degli Studi dell’Aquila – D.I.S.I.M.
Docente : Chia.mo Prof. Serafino Cicerone
Alessio D’Alessio, Filippo Mortari, Davide Russo
Indice:• FastVid Rentals: introduzione al problema• Business modeling• Requirements: i casi d’uso• Analysis & Design: SSD e Contratti delle operazioni• Human Computer Interaction• Analysis & Design: Architettura, package, classi e SD• Analysis & Design: I design Patterns GoF• Implementazione: Tecnologie Hibernate, RMI• Implementazione: il codice• FastVid Rentals: conclusioni
2
Richiesta del committenteSviluppo di un sistema software di gestione di una azienda di video-noleggi:
Video Rental Management System
3
Funzionalità:• Gestire il catalogo dei film;• gestire clienti e tessere servizi;• gestire il noleggio ed il reso di film;• gestire la prenotazione di film in maniera flessibile;• gestire politiche di sconto e promozione in maniera flessibile;• gestire il magazzino della filiale;• gestire la comunicazione con i clienti mediante sms • flessibilità ad eventuali nuovi canali di comunicazione;• flessibilità in ottica di una fruizione futura di servizi su piattaforma
web e Video-On-Demand• gestire il reporting dell’attività della filiale.
4
Strumenti per lo sviluppo sw• IDE: Eclipse Juno Service Release 1
• RMI Plug-in for Eclipse version 2.0 (applicazione distribuita)• Window Builder Editor (per la gestione grafica delle Swing)• Subversive SVN Team Provider (versionamento)
• Case: Visual Paradigm UML EE 8.0• Librerie: Java JRE 1.7, Hibernate ORM Libraries, • Server di versionamento:
• XP-Dev con supporto a SVN (per il progetto .vpp)• Google Code (per il codice Java)
• DBMS: MySQL tramite XAMPP
5
Il versionamento: Xp-Dev e GoogleCode6
Il processo di riferimento: UP7
Il processo di riferimento: UP
8
Ogni iterazione produce un’executable release
L’iterazione time-boxedAbbiamo cercato di rispettare le scadenze e assegnare le responsabilità con una sorta di diagramma di Gantt
9
Legenda10
Iterazione cui si riferisce il contenuto analizzato nella slide
Disciplina di UP, contenuto in esame nella slide corrente, sezione relativa a un particolare concetto..
Inception
Elaborazione – Iterazione 1
Elaborazione – Iterazione 2
Elaborazione – Iterazione 3
FASTVID RENTALS: BUSINESS MODELING
11
Business Modeling“One of the major problems with most business engineering efforts, is that the software engineering and the business engineering community do not communicate properly with each other.
This leads to the output from business engineering is not being used properly as input to the software development effort, and vice-versa.
The Unified Process addresses this by providing a common language and process for both communities, as well as showing how to create and maintain direct traceability between business and software models.”
12
La struttura aziendaleLa macrostruttura:
13
La struttura aziendaleL’organigramma aziendale della singola divisione:
14
Prospettiva dell’utenteSi mostrano i possibili punti di accesso fisici all’applicativo
15
Business rules salientiIl costo dei noleggi dipende da:• il tipo di supporto desiderato
• VHS: 0.5€ al giorno• CD / DVD : 1€ al giorno• BlueRay: 1.5€ al giorno
• la durata del noleggio• film novità: +10% sul prezzo originale
16
Business rules salientiLe politiche di sconto:• 10% ai clienti che hanno già noleggiato almeno un film
entro le 24h precedenti;• ogni 20 noleggi effettuati si ha diritto a 1 noleggio
gratuito;• 5% di sconto per noleggi Lun-Ven dalle h20.00 alle
h8.00 del giorno successivo;• 5% di sconto per clienti con età < 21 anni;
17
Il modello di dominio (Business Object Model)
18
Il modello di dominio (Business Object Model)
19
REQUIREMENTS – I CASI D’USO
20
Requirements“The goal of the Requirements workflow is to describe what the system should do and allows the developers and the customer to agree on that description.
Actors are identified, representing the users, and any other system that may interact with the system being developed. Use cases are identified, representing the behavior of the system.”
21
Use Case Diagram
22
Casi d’uso analizzati: • Tutti
Casi d’uso dettagliati: • UCRicercaFilm• UCNoleggia• UCPrenota• UCRestituisci
Use Case Diagram23
Casi d’uso analizzati: • Tutti
Casi d’uso dettagliati: • UCRicercaFilm• UCNoleggia• UCPrenota• UCRestituisci
UCRicercaFilm – DettagliIl Cliente, una volta recatosi presso una delle filiali FastVid Rentals può cercare un film di suo interesse. La ricerca può essere effettuata sia presso lo sportello esterno, sia presso lo sportello interno. Per effettuare una ricerca non è necessario utilizzare la tessera servizi. Il Cliente può inserire o il nome preciso di un film o cercare tramite tag come il genere, l'anno di produzione etc..
Se la ricerca viene effettuata presso lo sportello interno il sistema permette di stampare uno scontrino promemoria da poter presentare all'operatore di cassa per procedere con un noleggio.
24
UCRicercaFilm - Flow of events1. Il Cliente arriva al terminale FastVid
2. Il Cliente seleziona la ricerca film
3. Il Sistema mostra l'interfaccia di ricerca
4. Il Cliente inserisce delle parole chiave per il film da ricercare
5. Il Cliente avvia la ricerca
6. Il Sistema presenta un elenco di film
7. if Il Cliente è soddisfatto della ricerca
7.1. Il Cliente sceglie un film dalla lista
7.2. Il Sistema mostra i dettagli del film
7.3. if Il Cliente è soddisfatto del film selezionato
7.3.1. Il Cliente seleziona il supporto desiderato
7.3.2. Il sistema visualizza la disponibilità del supporto selezionato
7.3.3. if Il Cliente è soddisfatto
7.3.3.1. Il sistema mostra le azioni disponibili
7.3.3.2. Il Cliente sceglie l'opzione desiderata
25
UCNoleggiaFilm – DettagliIl Cliente, una volta recatosi presso una delle filiali FastVid Rentals, può effettuare un noleggio. La prima operazione che deve fare per poter noleggiare un film è la ricerca. Una volta trovato il film, il Cliente deve scegliere le opzioni di noleggio, il tipo di supporto/formato desiderati, e, se il supporto è disponibile, il sistema propone un quadro riassuntivo del noleggio. Se il cliente vuole procedere, deve scorrere la propria tessera servizi dalla quale verrà scalato l'importo pari al prezzo di noleggio. Il cliente può ritirare il prodotto.
26
UCNoleggiaFilm - Flow of events1. Il Cliente effettua una Ricerca film
2. Il Sistema richiede al Cliente l'autenticazione tramite lettura della tessera servizi
3. Il Cliente legge la sua tessera servizi presso il lettore
4. Il Sistema autentica il Cliente attraverso la tessera servizi e applica le politiche di prezzo
5. Il Sistema mostra al Cliente la relativa politica di prezzo
6. Il Cliente imposta la durata desiderata per il noleggio
7. Il Sistema mostra il riepilogo di prezzo e le condizioni di noleggio, richiedendo conferma
8. Il Cliente conferma la sua scelta
9. Il Sistema addebita l'importo del noleggio, registra il noleggio per il prodotto selezionato al Cliente
corrente e aggiorna la disponibilità del prodotto
10. Il Sistema notifica la transazione al Sistema contabilità
11. Il Sistema stampa la ricevuta e la consegna al Cliente unitamente al supporto noleggiato
12. Il Cliente ritira ricevuta e prodotto
27
Il riscontro del committenteL’incontro con il committente a valle dell’ideazione ha confermato il corretto rilevamento dei casi d’uso, nonché della realtà aziendale cui si fa riferimento (documento di visione e regole di business)
Il committente ha tuttavia preferito che l’autenticazione del cliente fosse la prima operazione necessaria ad avviare il caso d’uso di Noleggio.
28
UCPrenota - DettagliIl Cliente può effettuare una prenotazione. Quest'ultima può essere dovuta sia al fatto che non è disponibile al momento nessuna copia fisica del supporto/formato richiesto per il film di interesse, sia al fatto che il cliente vuole bloccare un film per una determinata data. L'SMS service è un servizio esterno che permette di avvisare al Cliente la disponibilità di un supporto/formato e consente al cliente di poter avviare una pratica di prenotazione anche mediante SMS.
Allo stato attuale le politiche di prenotazione non sono completamente definite: diverse filiali potrebbero adottare politiche locali guidate dall'andamento del mercato locale. Le politiche di prenotazione possono cambiare arbitrariamente secondo scelte avanzate dalla Sede centrale. La gestione delle politiche di prenotazione pertanto deve essere molto flessibile.
29
UCPrenota – Flow of Events 1. Il Cliente effettua una Ricerca film
2. Il sistema richiede al Cliente l'autenticazione tramite lettura della tessera servizi
3. Il Cliente legge la sua tessera servizi presso il lettore
4. Il Sistema autentica il Cliente attraverso la tessera servizi
5. Il Sistema aggiorna il prezzo relativamente alle politiche sulla tessera servizi corrente
6. Il Cliente indica la data di prenotazione voluta
7. Il sistema notifica la avvenuta disponibilità per tale giorno
8. Il Cliente indica la durata del noleggio prenotato
9. Il sistema mostra il riepilogo e le condizioni di prenotazione, richiedendo conferma
10. Il Cliente conferma la sua scelta
11. Il Sistema addebita l'importo della prenotazione, registra la prenotazione per il prodotto selezionato e aggiorna la disponibilità del prodotto
12. Il Sistema notifica la transazione al Sistema contabilità
13. Il Sistema stampa la ricevuta e la consegna al Cliente
14. Il Cliente ritira ricevuta
30
UCRestituisci - DettagliIl Cliente può recarsi presso una filiale di FastVid Rentals e restituire un prodotto sia allo sportello esterno, sia all'interno del punto vendita. All'interno del punto vendita può decidere se restituire il prodotto tramite sportello o fisicamente all'operatore di cassa.
31
UCRestituisci – Flow of events 1. Il Cliente si reca presso una filiale con un prodotto da restituire
2. Il Cliente informa il Sistema di voler restituire un prodotto precedentemente noleggiato
3. Il Sistema richiede al Cliente di depositare il prodotto nell'apposita feritoia
4. Il Cliente deposita il prodotto secondo le indicazioni ricevute
5. Il Sistema legge l'ID del prodotto depositato
6. Il Sistema recupera le informazioni sul Cliente tramite l'assocazione dello stesso ad un noleggio e quindi all'ID del supporto noleggiato e appena restituito
7. Il Sistema mostra al Cliente la conferma con riserva di controllo supporto per l'avvenuta restituzione
8. Il Sistema stampa la ricevuta cartacea attestante la restituzione
9. Il Sistema propone al Cliente di effettuare una nuova Ricerca film
10. Il Cliente rifiuta la proposta di cercare un nuovo film
11. Il Cliente si allontana con la ricevuta
32
ANALYSIS & DESIGNSSD e Contratti delle operazioni
33
Analysis & Design“The goal of the Analysis & Design workflow is to show how the system will be realized in the implementation phase.”
“The analysis model is a platform independent model (PIM), which means that it does not contain technology-based decisions.”
“The design model consists of design classes structured into design packages and design subsystems with well-defined interfaces, representing what will become components in the implementation. It is a PSM”
34
Use Case Driven!!!In UP, i casi d'uso sono utilizzati per catturare i requisiti funzionali e di definire i contenuti delle iterazioni.
Ogni iterazione prende in considerazione un set di casi d’uso o scenari dai requisiti sino all’implementazione, test e deploy.
35
UCRicercaFilm - SSD 36
UCRicercaFilm - SSD 37
UCRicercaFilm - I contrattiCercaFilm
Operazione: CercaFilm(chiaveRicerca).
Riferimenti casi d'uso: RicercaFilm, Prenota, Noleggia.
Pre-condizioni: esiste un'istanza della classe terminale connessa al client, esiste un catalogoFilm con almeno un film.
Post-condizioni: è stata creata una istanza di Lista di film popolata con i film che corrispondono alla ricerca.
38
UCRicercaFilm - I contrattiVisualizzaFilm
Operazione: visualizzaFilm(IDFilm)
Riferimenti casi d'uso: RicercaFilm, Noleggia, Prenota
Pre-condizioni: si conosce l'ID del film da visualizzare, l'istanza del film con tale ID è presente sul client, il magazzino è avviato.
Post-condizioni: il magazzino ha creato una Map < supporto; booleano disponibile; prezzo>.
39
UCRicercaFilm - I contrattiScegliSupporto
Operazione: scegliSupporto(supporto)
Riferimenti casi d’uso: Noleggia
Pre-condizioni: Il cliente ha già scelto il film da una ricerca
Post-condizioni: Un supporto per il film di interesse è stato selezionato.
40
UCNoleggiaFilm - SSD41
UCNoleggiaFilm - I contrattiNotificaIdentità
Operazione: notificaIdentita(IdTesseraCliente)
Riferimenti casi d’uso: Noleggia, GestisciTessera , Prenota
Pre-condizioni: è stata effettuata una ricerca film con successo, si ha a disposizione un Film ed un tipo di supporto selezionato, disponibile in Magazzino
Post-condizioni: la tessera cliente è stata riconosciuta, è stata memorizzata nell'istanza del terminale la tessera cliente, è stata creata una istanza di noleggio
42
UCNoleggiaFilm - I contrattiSetDurata
Operazione: setDurata(giorni)
Riferimenti casi d’uso: Noleggia, Prenota
Pre-condizioni: un'istanza di terminale è avviata, il cliente è autenticato, è stata creata un istanza di noleggio
Post-condizioni: l'istanza di noleggio contiene informazioni sulla durata del noleggio.
43
UCNoleggiaFilm - I contrattiConcludiNoleggio
Operazione: concludiNoleggio()
Riferimenti casi d’uso: Noleggia
Pre-condizioni: un'istanza di terminale è avviata, il cliente è autenticato, è stata creata un istanza di noleggio con tutti gli attributi.
Post-condizioni: l'istanza di noleggio è stata finalizzata, gli attributi temporanei dell'istanza terminale sono stati resettati, il prodotto nel magazzino è settato su "noleggiato".
44
UCPrenota – SSD45
UCPrenota – i contratti SetDataInizio
Operazione: setDataInizio(data)
Riferimenti: useCase: Prenota
Pre-condizioni: un'istanza di terminale è avviata, il cliente è autenticato, è stata creata un istanza di Prenotazione.
Post-condizioni: l'istanza di Prenotazione contiene
informazioni sulla data di inizio effettivo del noleggio.
46
UCPrenota – i contratti CheckPrenotazione
Operazione: checkPrenotazione()
Riferimenti: useCase: Prenota
Pre-condizioni: un'istanza di terminale è avviata, il cliente è autenticato, è stata memorizzata in sessione la data inizioe la durata prevista della prenotazione.
Post-condizioni: un prodotto è stato trovato corrispondente alle richieste di prenotazione dell'utente ed è stato memorizzato in sessione.
47
UCPrenota – i contratti ConfermaPrenotazione
Operazione: confermaPrenotazione()
Riferimenti: useCase: Prenota
Pre-condizioni: un'istanza di terminale è avviata, il cliente è autenticato, è stato trovato un prodotto corrispondente alle richieste del cliente, memorizzato in sessione con tutti gli attributi necessari alla prenotazione.
Post-condizioni: l'istanza di Prenotazione è stata creata, gli attributi temporanei, il prodotto nel magazzino è stato prenotato.
48
UCRestituisci – SSD49
UCRestituisci – i contratti Restituisci
Operazione: restituisci(IdProdotto)
Riferimenti: useCase: Restituisci
Pre-condizioni: un'istanza di terminale è avviata, il cliente dispone di un Prodotto fisico da restituire alla filiale di interesse.
Post-condizioni: Lo stato dell’istanza dell’oggetto “Prodotto” il cui ID corrisponde a IdProdotto cambia da “Noleggiato” a “Magazzino”
50
HUMAN - COMPUTER INTERACTIONCome è stata realizzata l’interfaccia grafica
Interfaccia grafica – Paper sketches52
Interfaccia grafica – MockUp53
Interfaccia grafica – Swing54
Interfaccia grafica – Swing55
Interfaccia grafica – Swing56
Interfaccia grafica – scelte su Swing57
Il riscontro del committente - graficaL’incontro con il committente a valle della prima Iterazione della fase di Elaborazione ha sostanzialmente confermato il corretto avanzamento del lavoro.
Il committente ha tuttavia segnalato:• la poca intuitività dell’interfaccia relativa alla ricerca di un film (o
meglio, si aspettava che l’interfaccia fosse corredata di parametri per la ricerca avanzata).
• sempre per quanto riguarda l’interfaccia, ha suggerito di migliorare la schermata di risultati della ricerca, in parte povera di contenuti (oltre al titolo film, dettagli come genere, regia, etc..)
58
La ristrutturazione di UCRicerca59
La ristrutturazione di UCRicerca60
La ristrutturazione di UCRicerca61
La ristrutturazione di UCRicerca62
La ristrutturazione di UCRicerca63
Paginazione gestitasul client, con limitazioni lato server sul numero max di risultati
Il riscontro del committente - graficaL’incontro con il committente a valle della seconda Iterazione della fase di Elaborazione ha sostanzialmente confermato il corretto avanzamento del lavoro.
Il committente ha tuttavia segnalato:• Al runtime deve essere possibile modificare i Generi film
della ricerca avanzata• Il campo “Nazione” della ricerca avanzata deve essere
un menù a tendina e non un campo di testo vuoto
64
La ristrutturazione di UCRicerca
Generi e colori caricati a runtime, eSelect sulle Nazioni
65
ANALYSIS & DESIGNArchitettura, package, classi, SD
Architettura softwareLa scelta architetturale:
MVA (Model – View – Adapter/Control)
• “The view is completely decoupled from the model such that view and the model can interact only via the mediating controller or adapter in between the view and the model”.
• “Only the adapter or mediating controller has knowledge of both the model and the view, because it is the responsibility of solely the adapter or mediating controller to adapt or mediate between the model and the view” [Wikipedia]
67
Architettura software“The model and view are kept intentionally oblivious of each other”
68
Il diagramma dei package69
Il diagramma dei package70
Il diagramma di Deployment71
Il diagramma delle classi – Il Client72
Il diagramma delle classi – Il Client73
Il diagramma delle classi – Il Server74
Il diagramma delle classi – Il Server75
Il diagramma delle classi – Il server76
Il diagramma delle classi – Il server77
Il diagramma ER78
Il diagramma ER79
Il diagramma ER80
Communication Diagram81
SD diagram: cercaFilm()82
SD diagram: cercaFilm()83
SD diagram: cercaFilm()84
SD diagram: cercaFilm()85
SD diagram: cercaFilm()86
SD diagram: cercaFilm()
SD diagram: cercaFilm()88
SD diagram: cercaFilm()89
SD diagram: cercaFilm()90
SD diagram: cercaFilm()91
SD diagram: cercaFilm()92
SD diagram: cercaFilm()93
SD diagram: cercaFilm()94
Diagramma degli stati: Noleggio 95
Diagramma degli stati: Prodotto96
ANALYSIS & DESIGNI DESIGN PATTERNS GoF
I Design Patterns GoF
…un momento importante durante il corso del design!
98
I Design Patterns GoF99
Scopo
Raggio d’azione
Design Patterns: SingletonIl Singleton è un design pattern creazionale che ha lo scopo di garantire che di una determinata classe venga creata una e una sola istanza, e di fornire un punto di accesso globale a tale istanza.
100
• Costruttore privato• metodo "getter"
statico che restituisce una istanza della classe
DA NON CONFONDERE!!!
Design Patterns: Singleton101
Design Patterns: Mediator• pattern comportamentale
basato su oggetti, ossia operante nel contesto delle interazioni tra oggetti, che ha l'intento di disaccoppiare entità del sistema che devono comunicare fra loro.
• Il pattern fa in modo che queste entità non si riferiscano reciprocamente, agendo da "mediatore" fra le parti.
102
Design Patterns: Mediator sul Client103 UNIFIED PROCESS – DESIGN PATTERNS
• Low coupling• Indirection
Design Patterns: State• pattern comportamentale
basato su oggetti che viene utilizzato quando il comportamento di un oggetto deve cambiare in base al suo stato.
• Questo pattern trova applicazione quando abbiamo a che fare con una “Macchina a Stati Finiti” ossia siamo in presenza di un sistema dinamico in cui i valori di ingresso, uscita e stato sono un insieme finito.
104 UNIFIED PROCESS – DESIGN PATTERNS
Design Patterns: Adapter• pattern strutturale basato
su classi o su oggetti in quanto è possibile ottenere entrambe le rappresentazioni.
• Viene utilizzato quando si intende utilizzare un componente software ma occorre adattare la sua interfaccia per motivi di integrazione con l’applicazione esistente.
105 UNIFIED PROCESS – DESIGN PATTERNS
Design Patterns: State+Adapter sul Client106 UNIFIED PROCESS – DESIGN PATTERNS
• Protected variations
• Indirection• Low Coupling
Design Patterns: Adapter (DTO) sul Server
107
Design Patterns: Facade• pattern strutturale basato su
oggetti che viene utilizzato per nascondere la complessità del sistema e ridurre la comunicazione e la dipendenza del Client.
• L’utilizzo di questo pattern prevede di esporre una interfaccia per l’invocazione di un Sistema tale da semplificare l’invocazione ad opera del Client.
108 UNIFIED PROCESS – DESIGN PATTERNS
Design Patterns: Terminale come ControllerFacade visibile al Client
109 UNIFIED PROCESS – DESIGN PATTERNS
• Controller Facade• Protected
Variations
Design Patterns: Strategypattern comportamentale basato su oggetti utilizzato per definire una famiglia di algoritmi, incapsularli e renderli intercambiabili.
Il client definisce l’algoritmo da utilizzare, incapsulandolo in un contesto, il quale verrà utilizzato nella fase di elaborazione.
Il contesto detiene i puntamenti alle informazioni necessarie al fine della elaborazione, cioè dati e funzione: solita equazione y=f(x)!
110 UNIFIED PROCESS – DESIGN PATTERNS
Design Patterns: Strategy (sulla ricercaFilm) - Server
111 UNIFIED PROCESS – DESIGN PATTERNS
• Polymorphism• Protected
Variations
Design Patterns: Strategy sulle prenotazioni - Server
112 UNIFIED PROCESS – DESIGN PATTERNS
Design Patterns: Compositepattern strutturale basato su oggetti che viene utilizzato quando si ha la necessità di realizzare una gerarchia di oggetti in cui l’oggetto contenitore può detenere oggetti elementari e/o oggetti contenitori.
L’obiettivo è di permettere al Client che deve navigare la gerarchia, di comportarsi sempre nello stesso modo sia verso gli oggetti elementari e sia verso gli oggetti contenitori.
113 UNIFIED PROCESS – DESIGN PATTERNS
Design Patterns: Strategy+Composite per i prezzi- Server
114
IMPLEMENTAZIONETECNOLOGIE:HIBERNATE & JAVA RMI
115
Hibernate: Object-Relational Mapping
• piattaforma middleware open source che fornisce un servizio di Object-Relational mapping (ORM) per lo sviluppo di applicazioni Java
• Consiste di una tecnica per la mappatura della struttura di oggetti Java su di un database relazionale
• Fornisce un’interfaccia Object-Oriented per la persistenza degli oggetti, nascondendo la logica relazionale sottostante
116
Hibernate: Object-Relational Mapping• Architettura Middleware
• L’applicazione costruisce la sua SessionFactory
• La SessionFactory costruisce e gestisce Sessioni, oggetti leggeri facade verso gli strati sottostanti
• La Sessione costruisce Transazioni e gli oggetti necessari al querying
117
Hibernate: Object-Relational Mapping• Fase di setup:
• Installazione R-DBMS, definizione DB e utente con privilegi • Inclusione delle librerie Hibernate (rel. 4.1) • Definizione file hibernate.cfg.xml con i parametri di connessione al
DBMS e la lista dei files di mapping• Definizione file .hbm.xml per ogni classe persistente(best practice)
• Definisce la mappatura effettiva attributo-colonna
• Una classe di utility per l’inizializzazione della SessionFactory • Costruisce l’oggetto SessionFactory composto• Dichiara un’interfaccia facade per il sistema verso persistenza
118
Hibernate: Object-Relational Mapping• XML che definisce i parametri per la costruzione della SessionFactory
119
Hibernate: Object-Relational Mapping• Mappatura della classe POJO su tabella relazionale
120
Hibernate: Object-Relational Mapping• Mappatura dell’ereditarietà di tipo
“Table Per Class”
• Un’unica tabella per mappare l’intera gerarchia di classi
• I campi della tabella mappano l’unione degli attributi delle classi della gerarchia
• Un campo Discriminator determina la classe di appartenenza dell’oggetto mappato nel relativo record
121
Hibernate: Object-Relational Mapping• La classe Facade Persistence
• Classe Singleton per la visibilità• Costruisce la SessionFactory
all’interno del costruttore, richiamato al primo accesso al metodo getInstance()
• Dichiara un’intercaccia Facade per la nostra applicazione verso le principali funzionalità dello strato di persistenza
• Può essere interpretata come una classe Adapter, in quanto rappresenta un livello di indirezione rispetto all’interfaccia del livello sottostante
122
Hibernate: Object-Relational Mapping• Features adottate: HQL
• Linguaggio di interrogazione ispirato ad SQL
• Classi anziché Tabelle• Oggetti anziché Campi
123
Hibernate: Object-Relational Mapping• Features adottate: Queries polimorfiche
• “from java.lang.Object”
• Recupera tutti gli oggetti della classe Object e della sue sottoclassi, presenti in persistenza. Abbiamo quindi tutti gli oggetti nel DB
• “from model.Noleggio”
• Recupera gli oggetti delle classi Noleggio e Prenotazione
• “from model.Noleggio where Discriminator=‘Prenotazione’”
• Recupera i soli oggetti della classe Prenotazione
124
Hibernate: Object-Relational Mapping• Features adottate: Queries by Criteria
125
Hibernate offre una API di interrogazione integralmente basata su paradigma ad oggetti
Java Remote Method Invocation (RMI)Indice:• A cosa serve• Come funziona• L’interfaccia RMI del server di filiale e suo utilizzo• L’interfaccia RMI Terminale e sua implementazione• L’interfaccia RMI di un oggetto del model: Film
126
Java RMI: a cosa server?• Si può avere un vero e proprio riferimento all’oggetto
remoto, anche se esso si trova su una Java Virtual Machine diversa dalla nostra
• Si può utilizzare la sintassi Java e tutte le potenzialità offerte dalla progettazione O.O. anche quando si invocano i metodi appartenenti agli oggetti remoti
• In questo modo è possibile progettare in maniera distribuita un'applicazione decomponendo la logica della nostra applicazione in diversi componenti
127
Java RMI: come funziona?1. Viene creata sul server un’istanza
dell'oggetto remoto e passata in forma di stub al rmi registry. Tale stub viene inserito all'interno del registry stesso.
2. Il client richiede al registry una copia dell'oggetto remoto da utilizzare.
3. Il registry restituisce una copia serializzata dello stub al client
4. Il client invoca uno dei metodi dell'oggetto remoto utilizzando la classe "clone“ fornita dallo stub
128
Java RMI: come funziona?5. Lo stub richiama lo skeleton che si
trova sul server chiedendogli di invocare sull'oggetto remoto lo stesso metodo che il client ha invocato sullo stub
6. Lo skeleton invoca il metodo richiesto sull'oggetto remoto
7. L'invocazione del metodo sull'oggetto remoto restituisce il risultato allo skeleton
8. Lo skeleton comunica il risultato allo stub sul client
9. Lo stub fornisce il risultato all'applicazione client iniziale
129
Java RMI: l’interfaccia server di filiale
Il progetto common è puntato sia dal progetto client che dal progetto server
130
Java RMI: l’interfaccia server di filiale131
Java RMI: chiamata al server di filiale132
Java RMI: chiamata al server di filiale133
Java RMI: il terminale134
Il progetto common è puntato sia dal progetto client che dal progetto server
Java RMI: il terminale135
Java RMI: il film DTO136
Il progetto common è puntato sia dal progetto client che dal progetto server
Java RMI: il film DTO137
Java RMI: il film DTO138
IMPLEMENTAZIONEIL CODICE
139
Listener sulle view140
Timer sul listener dello SpinnerDate141
Timer sul listener dello SpinnerDate142
Sessione sul server
Model
Controller CRUD
Facade Terminale
143
Sessione sul serverFacade Terminale
Model
Controller CRUD
144
Sessione sul serverFacade Terminale
Controller CRUD
Model
145
FASTVID RENTALS: CONCLUSIONII PUNTI DI FORZA DEL PROGETTO, GLI SVILUPPI FUTURI
146
I punti di forza• Flessibilità software:
• Gerarchia Terminali• Ogni Terminale specializza alcune particolari funzionalità• Il Client conosce il tipo di Terminale che gli serve e al run-time lo
richiede al server
• Client Multi-Piattaforma• Il Client è di tipo thin, tutta la computazione e la logica applicativa si
trovano lato Server• Con costi di progettazione e sviluppo sw bassi (sufficiente affiancare
un server Java e tecnologie Servlet) si può pensare di coprire anche il mercato del web
CONCLUSIONI147
I punti di forza• Sessione
• Fondamentale: classe altamente coesa che tiene traccia di tutte le operazioni compiute dall’utente sul Client
• Si trova sul server per cui garantisce all’utente di potersi muovere tra più macchine client mediante la propria tessera
• Politiche prezzo e sconti• Orientate al cambiamento• Componibili al run-time• Parametri modificabili al run-time
• Politiche prenotazioni• Orientate al cambiamento
148
I punti di forza• Tipologia ricerca
• Semplice o avanzata; anche in questo caso è facile aggiungere nuove tipologie ricerca senza troppa difficoltà
• Transizioni di stato sul client• Il terminale è il punto di accesso al server, gli stati sul client
proteggono il sistema da chiamate inappropriate sul server
• Gestione complessa stati di un prodotto sul server• Si è fatta un’analisi attenta di tutto il ciclo di vita del prodotto, dal
magazzino fino ad eventuali guasti per cogliere tutte le criticità nei processi di: acquisizione in magazzino / prenotazione / noleggio / restituzione, evitando così la generazione di inconsistenze
149
I punti ancora da migliorare• Multi-threading• Ottimizzare gestione temporale dei prodotto e noleggi
• Manca una vision sulla gestione delle prenotazioni: per adesso si recupera il primo prodotto disponibile ad essere prenotato / noleggiato.
• Se fosse gestito un “Calendario” vero e proprio sui prodotti, si potrebbe pensare a curare l’allocazione ottima di risorse
• ProxyImages sul client• Caricamento delle immagini sul client mediante pattern Proxy
150
I punti ancora da migliorare• Gestione del ripristino dello stato delle View
• La sessione sul server si occupa di tenere traccia delle azioni compiute dall’utente sul client (il film selezionato, il risultato di una ricerca), tuttavia non si cura di memorizzare lo stato della View
• A costi bassi (è sufficiente memorizzare quale è il caso d’uso attivo e quale view corrente gestita da quel caso d’uso) è possibile ripristinare completamente lo stato dell’applicazione, così da permettere ad un utente di muoversi da un Client ad un altro
151
I punti ancora da migliorare• Permettere all’admin di creare strategie sconti al runtime
tramite pannello amministrazione del back-end• Le strategie per ora sono selezionabili e componibili al run-time,
non creabili tuttavia• Abbiamo notato che la strategia è costituita da alcuni
macroblocchi:• condizione: dall’AND o l’OR di un insieme di proposizioni del tipo:
Object.property Operation Condition
(ad esempio: cliente.età < 25)• Percentuale sconto• Periodo di applicabilità
152
I punti ancora da migliorare• Si potrebbe pensare di implementare un motore di interpretazione
di proposizioni tale da consentire all’utente la definizione di proposizioni (si pensa anche al pattern Interpreter)
• l’assegnazione della percentuale, come il periodo di applicabilità sono banali
• Segue che l’utente può costruire strategie al run-time senza ricompilazione!
153
Statistiche sul codice del progetto:154
Progetto N° Classi Linee di codice
Linee di codice (eseguibile)
Peso file (KByte)
Client 50 6312 3876 170
Common 15 409 235 36,5
Server 77 5139 2496 153
TOTALE: 142 11860 6607 360
Report software: http://www.locmetrics.com/index.html
Altri dati rilevanti sul progetto:155
Risorse umane impiegate 3
Iterazioni completate 3
Giorni utili di lavoro 60
Ore lavoro 480h / pp = 1440h complessive
Commit SVN effettuate 500
Alessio D’Alessio, Filippo Mortari, Davide Russo
VI RINGRAZIAMO PER L’ATTENZIONE