Progettazione della Web Application Niente di Nuovo Mercatino dell Usato

Transcript

1 Università del Salento Facoltà di Ingegneria Corso di Laurea in Ingegneria dell Informazione Progetto del corso di Ingegneria del Software Progettazione della Web Application Niente di Nuovo Mercatino dell Usato Docenti Prof. Luca Mainetti Studenti Luisa Vittoria Bruno matr Marco Grazioli matr A.A. 2011/2012

2 2

3 Sommario Introduzione Descrizione dei requisiti Analisi dei requisiti Stakeholder Casi d Uso Diagrammi dei casi d uso Utente Carrello e Acquisti Inserzioni Funzionalità dell amministratore Tecnologie Utilizzate Struts Pattern Model-View-Control Il funzionamento del framework Apache Tiles Apache Tomcat L architettura di Tomcat MySQL MySQL Workbench Hibernate JavaMAIL Eclipse Tecnologie per la condivisione del codice Modellazione del Database Diagramma Entità-Relazione Diagramma Relazionale Progettazione UML dell architettura

4 5.1 Diagramma dei package Diagrammi di stato Diagrammi delle classi e Design Pattern Utilizzati Diagrammi delle classi in the large Hibernate, Design Pattern DAO Le classi Util, Design Patter Facade Le classi Util, Design Patter Singleton Il Catalogo, Design Pattern Composite Aggiornamento di Stato e Invio , Design Pattern Command Calcolo del Prezzo Totale del Carrello, Design Pattern Strategy Creazione del path per le immagini del Catalogo, Design Pattern Strategy Diagrammi di sequenza Cambio di Stato di una Registrazione, Design Pattern Command Cambio di stato di una Richiesta di Acquisto, Design Pattern Command Creazione di una nuova inserzione Modifica di un inserzione esistente Calcolo del Prezzo Totale del Carrello, Design Pattern Strategy Diagramma di Deployment Implementazione dell Applicazione Contenuti Statici Navigazione del Catalogo Effettuare un ordine Inserzioni Gestione Dati Utente Gestione Categorie Gestione Utenti Gestione Acquisti Test di Unità

5 7.1 Test relativi ai pattern Altri Test Scrum Spint backlog Burndown chart

6 Introduzione Il presente progetto consiste nella realizzazione di un mercatino dell usato online, le cui caratteristiche principali sono emerse dall analisi dei requisiti e dalla visione di numerosi siti di e-commerce. L applicazione, realizzata sotto forma di web application, è composta da contenuti statici come le pagine di dettaglio dei prodotti in vendita, degli ordini effettuati dagli utenti, del contenuto del carrello, dei dati relativi agli utenti registrati o quelle relative alla descrizione del regolamento del mercatino. La parte più ricca e interessante dell applicazione però sono i suoi contenuti dinamici, come le diverse pagine che permettono di sfogliare il catalogo, di riempire il carrello e fare gli acquisti, di mettere nuove inserzioni e modificarle, di modificare i dati personali o tutta la parte di amministrazione riservata al gestore del servizio. 1 Descrizione dei requisiti L obiettivo principale di questo progetto è la realizzazione di un applicazione che permetta a un utente di completare un acquisto, scegliendo tra quelli presenti nel catalogo e permettere all amministratore del sistema di gestire queste richieste di acquisto. E necessario quindi differenziare gli utenti in generici, loggati e amministratore e il sistema deve poter fornire funzionalità diversificate a ciascuno di essi. Fondamentali per effettuare questa diversificazione sono le aree per la Registrazione, per il Login e per il Logout. Un utente generico che voglia effettuare la registrazione, deve inviare una richiesta attraverso l apposito form e attenderne l autorizzazione da parte dell amministratore. Quest ultimo infatti ha un apposita sezione in cui può visionare tutte le richieste di registrazione, autorizzarle o rifiutarle. Il sistema notificherà, con un automatica all utente, eventuali cambiamenti di stato della sua richiesta di registrazione. Come specificato nei requisiti, questa modalità di registrazione, insieme alle altre modalità di accesso ai contenuti, sono descritte nel regolamento. I dati inseriti nel corso della registrazione possono essere modificati dall utente, attraverso un opportuno form accessibile dopo aver effettuato il login. Il sistema deve permettere a un utente generico di accedere al catalogo attraverso il form di ricerca o attraverso la navigazione per categoria o per inserzionista. Gli articoli visualizzati potranno essere ordinati per nome, prezzo, inserzionista. Ogni articolo inoltre avrà una scheda con i relativi dettagli e da questa sarà possibile aggiungerlo nel carrello, specificandone la quantità desiderata. L acquisto è consentito solo agli utenti loggati, un utente generico infatti può solo prendere visione dei contenuti del catalogo e inserire i prodotti nel carrello, di cui il sistema terrà traccia nel momento in cui l utente dovesse effettuare il login. 6

7 Il sistema deve dare la possibilità di apportare modifiche al contenuto del carrello, aggiungendo o eliminando prodotti e modificandone la quantità per quelli selezionati. Inoltre è indispensabile che il sistema sia in grado di differenziare i carrelli di utenti diversi che accedono contemporaneamente all applicazione. Il sistema deve richiedere la conferma del contenuto del carrello prima di procedere all'acquisto e deve dare la possibilità all'utente di confermare le proprie generalità, di specificare un nominativo e un indirizzo di spedizione diversi dai propri e i dati di pagamento. Il sistema invierà automaticamente un di notifica della memorizzazione della richiesta di acquisto all utente e a tutti i venditori coinvolti nell ordine. Per avere una corretta associazione tra ordini e articoli acquistati, considerando che le inserzioni possono essere modificate, è necessario conservare uno storico degli articoli del catalogo che sono stati acquistati. Il gestore del servizio dovrà poter visionare tutte le nuove richieste di acquisto per approvarle o rifiutarle. Il sistema notificherà, con un automatica, all utente e agli inserzionisti dei prodotti presenti nell ordine eventuali cambiamenti di stato della richiesta di acquisto. Un utente loggato deve avere la possibilità di visionare tutti i dettagli relativi ai suoi ordini. Infine il sistema deve permettere a un utente loggato di pubblicare inserzioni di vendita e di modificarle. 2 Analisi dei requisiti In questo capitolo saranno descritti nel dettaglio le tipologie di utente che abbiamo preso in considerazione nello sviluppo dell applicazione e verranno esposti i possibili casi d uso del sistema, derivati direttamente dalla raccolta dai requisiti. 2.1 Stakeholder Le principali categorie di utilizzatori dell applicazione sono: Utente Generico: si tratta di un utente non loggato che attraverso il browser può principalmente accedere ai contenuti statici dell applicazione, ovvero alla navigazione del catalogo attraverso il form di ricerca o attraverso la navigazione per categorie e per inserzionista, alle schede descrittive dei prodotti, alla pagina del regolamento. Inoltre può inserire i prodotti d interesse nel carrello, può accedere al contenuto del carrello e modificarlo aggiungendo prodotti, eliminandoli o cambiandone la quantità scelta, ma non può completare l acquisto, perché per fare ciò è necessario effettuare il login. Infine può accedere al form di registrazione. Utente loggato: è il principale utilizzatore dell applicazione perché è considerato come il legittimo cliente del servizio. Un utente loggato infatti, oltre a poter visionare il catalogo, aggiungere i prodotti d interesse al carrello e modificare il contenuto di quest ultimo può completare le richieste di acquisto dei prodotti inseriti nel carrello, può verificare i dettagli e lo stato degli acquisti già 7

8 completati. Può inoltre proporre degli oggetti da vendere pubblicando nuove inserzioni e può prendere visione delle inserzioni già inserite e modificarle. A queste stesse inserzioni potrà anche accedervi attraverso la navigazione del catalogo, ma non potrà ovviamente effettuare l acquisto dei relativi prodotti in quanto ne è esso stesso il venditore. Può accedere ai suoi dati personali inseriti nel momento della registrazione per visionarli ed eventualmente apportarvi delle modifiche. Gestore del Sistema: è la figura che corrisponde all amministratore del mercatino. Infatti a lui spetta il compito di approvare tutte le nuove richieste, siano queste di registrazione di nuovi utenti o di acquisto. Per svolgere questo incarico ha due apposite sezioni una relativa alle richieste di registrazione e una relativa alle richieste di acquisto. Nella prima può prendere visione di tutte le nuovo richieste di utenti che vogliono registrarsi e dopo averne visto i dettagli può approvarle o rifiutarle completando un apposito modulo con la motivazione del rifiuto. Inoltre ha a disposizione anche l elenco di tutte le richieste di registrazione rifiutate delle quali può decidere di modificarne nuovamente lo stato approvandole. Nella pagina relativa alle richieste di acquisto ha a disposizione un elenco con tutte le nuove richieste di acquisto delle quali anche qui può visionare i dettagli e metterle in spedizione o rifiutarle. Poi ha un elenco di tutti gli ordini già in spedizione e infine ha la possibilità di accedere all elenco degli ordini evasi e degli ordini rifiutati. Il gestore del sistema non ha la possibilità di effettuare acquisti, né di riempire o accedere ad un suo carrello, però può prendere visione del catalogo e di tutte le pagine di dettaglio dei prodotti contenuti in questo. Inoltre ha una sezione per la gestione delle categorie del catalogo, all interno della quale può crearne di nuove o modificare quelle già esistenti. 8

9 2.2 Casi d Uso I casi d uso elencati di seguito sono una panoramica dei principali casi d interazione tra le diverse tipologie d utente considerate e il sistema Diagrammi dei casi d uso Attività in comune Nel seguente diagramma dei casi d uso sono presenti solo le attività compiute da almeno due utenti, più la registrazione che è riservata ad un utente non loggato. Figura 1: Diagramma dei casi d'uso "Attività in comune" 9

10 Attività di un utente loggato Nel seguente diagramma sono rappresentati i casi d uso strettamente riservati ad un utente che non sia il gestore del sistema, la cui registrazione sia già stata approvata e che abbia effettuato il login. Attività del Gestore del Servizio Figura 2: Diagramma dei casi d'uso "Utente Loggato" In questo diagramma c è un overview di tutte le attività che può compiere l amministratore del sistema. Conferma nuova richiesta di registrazione Conferma registrazione di un utente rifiutato Verifica Richieste d acquisto Evasione di una richiesta di acquisto Login Amministratore Aggiunta di una categoria Modifica di una categoria Eliminazione di una categoria Figura 3: Diagramma dei casi d'uso "Amministratore" 10

11 2.2.2 Utente In questa sezione saranno descritti i casi d uso che riguardano l interazione di un utente con il sistema per l inserimento e la memorizzazione dei suoi dati personali. Richiesta di registrazione di un nuovo utente 1. L utente accede alla Home. 2. L utente accede alla pagina con il form di registrazione. 3. L utente inserisce i propri dati e conferma. 4. Il sistema, dopo aver eseguito le opportune verifiche di correttezza di formato e di univocità del campo Username, memorizza la richiesta. Estensioni: 4a: Uno o più campi non sono stati compilati correttamente. 4.1 Il sistema, dopo aver eseguito le verifiche di correttezza di formato, rileva gli errori, li segnala e invita l utente a reinserire i dati non corretti. (Passo 3 del caso d uso principale) 4b: Username scelto già in uso. 4.1 Il sistema, dopo aver effettuato la verifica di univocità del campo Username, rileva l errore, lo segnala e invita l utente a inserire un altro Username. (Passo 3 del caso d uso principale) Login 1. L utente accede alla Home. 2. L utente inserisce le proprie credenziali di Login. 3. Il sistema, dopo aver verificato la presenza dell utente nel database, consente l accesso. Estensioni: 3a: Username o password errate. 3.1 Il sistema visualizza un messaggio di errore e invita l utente a inserirle nuovamente. (Passo 2 del caso d uso principale) Modifica del profilo Utente 1. L utente effettua il Login. 2. L utente accede alla pagina di modifica dei suoi dati. 3. L utente effettua le modifiche ai dati. 4. L utente conferma le modifiche effettuate. 5. Il sistema, dopo aver eseguito le verifiche di correttezza di formato, memorizza le modifiche. Estensioni: 6a: Uno o più campi non sono stati compilati correttamente. 6.1 Il sistema, dopo aver eseguito le verifiche di correttezza di formato, rileva gli errori, li segnala e invita l utente a reinserire i dati non corretti. (Passo 4 del caso d uso principale) 11

12 2.2.3 Carrello e Acquisti In questa sezione sono presenti tutti i casi d uso relativi all interazione di un utente generico con il sistema per: la navigazione del catalogo, il riempimento del carrello, il completamento e la visualizzazione delle richieste di acquisto. Navigazione del Catalogo per Categoria 1. L utente accede alla Home. 2. L utente accede alle categorie principali del catalogo (es. mobili, abbigliamento, telefonia, ecc.). 3. L utente sceglie le categorie e le sottocategorie d interesse. 4. Il sistema visualizza l elenco degli articoli delle categorie e sottocategorie scelte dall utente. 5. L utente può ordinare gli articoli per prezzo, nome o per inserzionista. 6. L utente può visualizzare la scheda relativa al prodotto d interesse. Navigazione del Catalogo per Inserzionista 1. L utente accede alla Home. 2. L utente accede all elenco degli inserzionisti. 3. L utente sceglie l inserzionista d interesse. 4. Il sistema visualizza l elenco degli articoli pubblicati dall inserzionista scelto dall utente. 5. L utente può ordinare gli articoli per prezzo, nome o per inserzionista. 6. L utente può visualizzare la scheda di dettaglio del prodotto d interesse. Ricerca nel Catalogo 1. L utente accede alla home. 2. L utente accede alle funzionalità di ricerca. 3. L utente valorizza uno o più dei campi del form di ricerca (nome, prezzo, categoria, inserzionista). 4. Il sistema visualizza i risultati della ricerca. 5. L utente può ordinare i risultati per prezzo, nome o per inserzionista. 6. L utente può visualizzare la scheda relativa al prodotto d interesse. Estensioni: 4a: La ricerca non ha prodotto risultati. 4.1 Il sistema visualizza un messaggio di errore 4.2 L utente può inserire altri criteri di ricerca. (Passo 3 del caso d uso principale) Aggiunta di un prodotto al carrello 1. L utente visiona il catalogo o effettua una ricerca. 2. L utente visualizza la scheda del prodotto d interesse. 3. L utente sceglie di aggiungere il prodotto al carrello. 4. Il sistema memorizza l inserimento e visualizza il contenuto del carrello. 12

13 Modifica del contenuto del carrello Precondizione: Il carrello deve contenere almeno un articolo. 1. L utente accede al carrello. 2. Il sistema presenta un prospetto con il contenuto complessivo del carrello. 3. L utente può eliminare un prodotto dal carrello. 4. L utente può modificare la quantità di un prodotto dal carrello. Acquisto di prodotti 1. L utente aggiunge tutti i prodotti d interesse al carrello. 2. L utente accede al carrello. 3. Il sistema presenta un prospetto con il contenuto complessivo del carrello. 4. L utente può modificare il contenuto del carrello. 5. L utente conferma il contenuto del carrello. 6. Il sistema verifica che l utente sia loggato e presenta un prospetto per la conferma o modifica dei dati personali, dei dati di spedizione e per l inserimento dei dati di pagamento. 7. L utente fornisce tutte le informazioni necessarie. 8. L utente conferma l acquisto. 9. Il sistema invia all utente un di conferma di memorizzazione della richiesta di acquisto. 10. Il sistema invia agli inserzionisti coinvolti nella richiesta di acquisto un di notifica della richiesta di acquisto. Estensioni: 6a: L utente non è loggato. 6.1 Il sistema invita l utente a effettuare il Login e riprovare. 6.2 L utente se registrato effettua il Login, altrimenti effettua la registrazione. Verifica dello stato degli acquisti 1. L utente effettua il Login. 2. L utente accede all elenco dei suoi ordini. 3. Il sistema visualizza tutti gli ordini effettuati dall utente, suddivisi per stato. 4. L utente può visualizzare i dettagli di un ordine Inserzioni Questa sezione contiene i casi d uso che riguardano l interazione tra il sistema e un utente loggato per l inserimento di nuove proposte di vendita e la modifica di proposte già inserite. Pubblicazione di una nuova Proposta di Vendita 1. L utente effettua il Login. 2. L utente accede alla pagina per la gestione delle proposte di vendita. 13

14 3. L utente accede alla sezione relativa all aggiunta di una nuova inserzione. 4. L utente inserisce i dati relativi alla nuova inserzione. 5. L utente conferma i dati inseriti. 6. Il sistema, dopo aver eseguito le verifiche di correttezza di formato, memorizza la nuova inserzione. Estensioni: 6a: Uno o più campi non sono stati compilati correttamente. 6.1 Il sistema, dopo aver eseguito le verifiche di correttezza di formato, rileva gli errori, li segnala e invita l utente a reinserire i dati non corretti. (Passo 4 del caso d uso principale) Modifica di una proposta di vendita 1. L utente effettua il Login. 2. L utente accede alla pagina per la gestione delle proposte di vendita. 3. L utente sceglie un inserzione da modificare. 4. L utente può modificare le informazioni relative all inserzione. 5. L utente conferma i dati inseriti. 6. Il sistema, dopo aver eseguito le verifiche di correttezza di formato, memorizza le modifiche. Estensioni: 6a: Uno o più campi non sono stati compilati correttamente. 6.1 Il sistema, dopo aver eseguito le verifiche di correttezza di formato, rileva gli errori, li segnala e invita l utente a reinserire i dati non corretti. (Passo 4 del caso d uso principale) Funzionalità dell amministratore In questa sezione sono raccolti tutti i casi d uso che riguardano l interazione tra il gestore del sistema e il sistema stesso al fine di fargli adempiere tutti i suoi incarichi amministrativi. Conferma registrazione di un nuovo utente 1. Il gestore del servizio accede alla Home. 2. Il gestore del servizio effettua il Login. 3. Il gestore del servizio accede alla pagina di gestione degli utenti. 4. Il sistema presenta l elenco delle nuove richieste di registrazione. 5. Il gestore del servizio visualizza i dati di una richiesta. 6. Il gestore del servizio conferma la richiesta di registrazione. 7. Il sistema invia all utente un di conferma dell avvenuta registrazione. Estensioni: 6a: Il gestore del servizio ha motivo di rifiutare la richiesta di registrazione. 6.1 Il gestore del servizio rifiuta la richiesta di registrazione e inserisce la motivazione del rifiuto. 14

15 6.2 Il sistema invia all utente un per comunicare il rifiuto della registrazione e la relativa motivazione. Conferma registrazione di un utente rifiutato 1. Il gestore del servizio accede alla Home. 2. Il gestore del servizio effettua il Login. 3. Il gestore del servizio accede alla pagina per la registrazione degli utenti e richiede l elenco degli utenti rifiutati. 4. Il sistema presenta l elenco delle richieste di registrazione rifiutate. 5. Il gestore del servizio visualizza i dati di una richiesta. 6. Il gestore del servizio conferma la richiesta di registrazione. 7. Il sistema invia al nuovo utente un di avvenuta registrazione. Verifica Richieste d acquisto 1. Il gestore del servizio effettua il Login. 2. Il gestore del servizio accede alla pagina di gestione degli ordini raggruppati per stato. 3. Seleziona un ordine non confermato. 4. Il sistema visualizza i dettagli dell ordine selezionato. 5. Il gestore del servizio verifica i dati di pagamento e le opzioni di spedizione. 6. Il gestore del servizio può confermare o rifiutare l ordine. 7. Il sistema invia un all acquirente e all inserzionista per informarli delle modifiche allo stato dell ordine. Evasione di una richiesta di acquisto 1. Il gestore del servizio effettua il Login. 2. Il gestore del servizio accede alla pagina di gestione degli ordini raggruppati per stato. 3. Seleziona un ordine in spedizione. 4. Il sistema visualizza i dettagli dell ordine selezionato. 5. Il gestore del servizio può chiudere l ordine. 6. Il sistema invia un all acquirente e ad ogni venditore per informarli delle modifiche allo stato dell ordine. Aggiunta di una categoria 1. Il gestore del servizio effettua il Login. 2. Il gestore del servizio accede alla pagina per la gestione delle categorie. 3. Il gestore del servizio inserisce nell apposita sezione il nome della nuova categoria. 4. Il gestore del servizio conferma i dati inseriti. 15

16 5. Il sistema, dopo aver eseguito le verifiche di correttezza di formato e di univocità del nome, memorizza la nuova categoria. Estensione: 5a: Esiste già una categoria con il nome specificato. 5.1 Il sistema segnala l errore e invita il gestore a inserire un nuovo nome. (Passo 3 del caso d uso principale) 5b: Uno o più campi non sono stati compilati correttamente. 5.1 Il sistema, dopo aver eseguito le verifiche di correttezza di formato, rileva gli errori, li segnala e invita il gestore del servizio a reinserire i dati non corretti. (Passo 3 del caso d uso principale) Modifica di una categoria 1. Il gestore del servizio effettua il Login. 2. Il gestore del servizio accede alla pagina per la gestione delle categorie. 3. Il gestore del servizio sceglie una categoria da modificare e accede all apposita sezione. 4. Il gestore del servizio modifica le informazioni relative alla categoria scelta. 5. Il gestore del servizio conferma i dati inseriti. 6. Il sistema, dopo aver eseguito le verifiche di correttezza di formato e di univocità del nome, memorizza le modifiche alla categoria. Estensione: 6a: Esiste già una categoria con il nuovo nome specificato. 6.1 Il sistema segnala l errore e invita a inserire un nuovo nome. (Passo 4 del caso d uso principale) 6b: La nuova categoria padre scelta è una sottocategoria di quella che si sta modificando. 6.1 Il sistema segnala l errore e invita a scegliere un'altra categoria. (Passo 4 del caso d uso principale) 6c: Uno o più campi non sono stati compilati correttamente. 6.1 Il sistema, dopo aver eseguito le verifiche di correttezza di formato, rileva gli errori, li segnala e invita il gestore del servizio a reinserire i dati non corretti. (Passo 4 del caso d uso principale) 6d: Esiste già una categoria con il nome specificato per la nuova sottocategoria. 6.1 Il sistema segnala l errore e invita a inserire un nuovo nome. (Passo 4 del caso d uso principale) Eliminazione di una categoria 1. Il gestore del servizio effettua il Login. 2. Il gestore del servizio accede alla pagina per la gestione delle categorie. 3. Il gestore del servizio sceglie una categoria da eliminare e accede alla relativa sezione di modifica. 4. Il gestore elimina la categoria. 5. Il sistema memorizza l eliminazione della categoria. 16

17 Estensione: 5a: La categoria non può essere eliminata perché contiene articoli, ma non ha una categoria padre in cui questi possono essere inseriti. 5.1 Il sistema impedisce l eliminazione. 17

18 3 Tecnologie Utilizzate Le tecnologie utilizzate per lo sviluppo di un applicazione influenzano in maniera determinante tutti gli aspetti principali della progettazione, per questo meritano un capitolo dedicato. 3.1 Struts 2 Le tecnologie utilizzate per lo sviluppo di questa web-application sono diverse, ma la più importante è stata Struts2, un framework open source per Web application. Nasce nel 2008, con il nome di WebWork, che non ha nessun legame particolare con la versione 1 di Struts, per poi passare, dopo una prima fase di analisi e sviluppo, al nome Struts2. La versione 1 di Struts nasce nel 2000 per opera di Craig R. McClanahan, ma la popolarità del framework è cresciuta enormemente nel corso degli ultimi anni. Dopo il rilascio di Struts 1.1, nel giugno 2003, Struts è diventato uno degli scenari più importanti per lo sviluppo di complesse applicazioni web basate su JSP. Struts2 si differenzia molto dalla prima versione in quanto non si tratta di una semplice evoluzione, ma di una trasformazione radicale di alcuni aspetti caratteristici di questo framework, per questo motivo la migrazione tra le due versioni non è semplice. Le principali differenze sono le seguenti: web.xml o o Struts: Il controllo viene affidato ad una Servlet. Di default alla ActionServlet, ma è possibile definire una Action personalizzata; Struts 2: Il controllo viene affidato ad un Filter. Di default al FilterDispatcher, ma è possibile definire un Filtro personalizzato; URI pattern o o Struts: Di default viene utilizzato il pattern *.do per identificare una richiesta che la ActionServlet prenderà in carico; Struts 2: Di default viene utilizzato il pattern *.action per identificare una richiesta che il FiltroDispatcher prenderà in carico; File di configurazione o o Struts: Di default il nome del file di configurazione è struts-config.xml che va posizionato allo stesso livello del file web.xml; Struts 2: Di default il nome del file di configurazione è struts.xml che va posizionato in una directory del classpath; Mapping delle Action o Struts: Il mapping di una Action viene definito nel file di configurazione mediante il tag action-mapping; 18

19 o Struts 2: Il mapping di una Action viene automaticamente generato dalla concatenazione "package-nome della action", entrambi definiti nel file di configurazione; Proprietà di una Action o o Struts: Le proprietà necessarie ad una Action vengono definite in una classe ActionForm, nella quale occorre definire anche i metodi get e set; Struts 2: Le proprietà necessarie vengono definite direttamente nella Action nella quale occorre definire anche i metodi get e set; Action o o Struts: Una Action deve estendere la classe org.apache.struts.action.action; Struts 2: Una Action deve implementare l'interfaccia com.opensymphony.xwork2.action oppure estendere la classe com.opensymphony.xwork2.actionsupport che, a sua volta, è un'implementazione di Action; Metodo execute o o Struts: Il metodo execute di una Action restituisce un ActionForward; Struts 2: Il metodo execute di una Action restituisce una stringa. Il Controller stabilisce, in base alla stringa restituita, qual è la vista da richiamare; TagLibrary o o Struts: Sono disponibili diverse taglibrary, suddivise per tipo di argomento trattato (logic, bean, HTML); Struts 2: È disponibile un'unica taglibrary che mette a disposizione sia operazioni di logica che di rendering HTML. Il framework è basato sulla struttura Model-View-Controller (MVC) e fa uso di altre tecnologie come Servlet e JSP; l applicazione Struts, quindi, è una pura Web application che dovrebbe essere eseguita in qualsiasi Sevlet container inclusi tutti i server J2EE. 19

20 3.1.1 Pattern Model-View-Control Le componenti base del pattern MVC sono le seguenti: Componente Model View Controller Descrizione Rappresenta i dati, persistenti su database, attraverso oggetti. Questa forma permette di manipolare il modello dei dati in modo semplificato. È il livello di presentazione. È qui che definiamo l'interfaccia utente, forniamo una rappresentazione del modello dei dati e riceviamo richieste dall'esterno. È il componente che contiene la logica di business. Qui gestiamo le interazioni con l'interfaccia, istradiamo le richieste, preleviamo i dati dal Model e stabiliamo quale View dovrà rappresentarli e come. Tabella 1 - Pattern Model-View-Control Questo approccio si preoccupa di separare la responsabilità nelle web application. Una richiesta client viene intercettata dal Controller, attraverso il Model vengono forniti tutti i metodi per accedere ai dati dell'applicazione e quindi per elaborare la risposta e visualizzarla nel View. L'utilizzo del pattern MVC offre quindi molteplici vantaggi tra i quali una separazione tra i livelli di presentazione e di transazione; ciò permette di cambiare il look and feel di un'applicazione senza ricompilare il codice del Modello o del Controller. In secondo luogo il tempo di sviluppo può essere significativamente ridotto, perché gli sviluppatori possono pensare alle transazioni, mentre i View programmers (HTML e JSP) si concentrano sull'interfaccia. L'ultimo beneficio è la separazione della logica di presentazione da quella di business che rende più facile mantenere e modificare un'applicazione Web struts-based Il funzionamento del framework Questo framework semplifica notevolmente sia la fase di sviluppo, che di revisione e di configurazione di un applicazione. L'utilizzo di Struts supporta infatti vantaggi significativi per il progetto in termini di: Modularità e Riusabilità: i diversi ruoli dell'applicazione sono affidati a diversi componenti. Ció consente di sviluppare codice modulare e più facilmente riutilizzabile; Manutenibilità: l'applicazione è costituita da livelli logici ben distinti. Una modifica in uno dei livelli non comporta necessariamente modifiche negli altri; Rapidità di sviluppo: è possibile sviluppare in parallelo le varie parti dell'applicazione, logica di business e di view. 20

21 Struts fornisce le componenti View e Controller e si integra con altre tecnologie per fornire il modello. Il Controller del framework agisce come un ponte fra il Model e la View, divenendo la parte fondamentale del framework. Quando viene ricevuta una richiesta, il Controller (Filter Dispatcher) richiama una Action sulla base di un mapping definito nel file di configurazione struts.xml. Figura 4: Architettura Struts2 L Action esamina o aggiorna lo stato dell'applicazione consultando il modello (o, preferibilmente, una interfaccia che rappresenta il modello) e, al termine dell elaborazione, viene presentata una vista a ppropriata in base all esito dell esecuzione della Action e al mapping tra risultato e view nel file di configurazione. Per trasferire i dati tra il modello e la vista, possono essere settate delle proprietà nella Action o in un JavaBean. Per rendere più facile presentare i dati dinamici, il framework include una libreria di tag di markup, di logica o di rendering, capace di interagire, ad esempio, con le funzionalità di validazione e di internazionalizzazione. Uno dei concetti nuovi di Struts 2 è rappresentato dagli Interceptor, classi stateless (che non mantengono uno stato tra invocazioni successive) che possono essere invocate prima e dopo una Action, o un insieme qualuque di Action. Usando questi interceptors è possibile, per esempio, validare l'input o intercettare eccezioni. Il framework dispone di numerosi interceptor predefiniti, ciascuno dei quali può essere inserito in uno stack. L'ordine di esecuzione dei diversi interceptors è dato dal loro ordine di dichiarazione nello stack. La filosofia utilizzata è quella FIFO, chi è dicharato per primo, viene eseguito per primo. 21

22 3.1.3 Apache Tiles Struts2 può interagire con altri framework grazie a numerosi plugin, il gruppo più importante utilizzato all interno di questo progetto è Tiles 2. Apache Tiles è un framework di templating costruito per semplificare lo sviluppo delle interfacce utente nelle applicazioni web. Tiles permette agli sviluppatori di definire dei frammenti di pagina che possono essere assemblati in una pagina completa a runtime. Questi frammenti, o tiles, possono essere utilizzati come semplici inclusioni, al fine di ridurre la duplicazione degli elementi in comune della pagine o incorporati all'interno di altri tiles per sviluppare una serie di modelli riutilizzabili. 3.2 Apache Tomcat Per quanto riguarda il web server è stato utilizzato Tomcat, un web Servlet container sviluppato dalla Apache Software Foundation. E distribuito gratuitamente da Apache ( e fa parte del progetto Jakarta (jakarta.apache.org), che ha come obiettivo lo sviluppo, la manutenzione e la distribuzione di server basati su Java. Implementa le specifiche JavaServer Pages (JSP) e Servlet di Sun Microsystems, fornendo quindi una piattaforma per l'esecuzione di applicazioni Web sviluppate nel linguaggio Java. Tomcat è scritto interamente in Java, può quindi essere eseguito su qualsiasi architettura su cui sia installata una JVM. Tomcat può funzionare fondamentalmente in due modalità distinte: Modalità Stand Alone: gestisce la pubblicazione di pagine statiche, JSP e supporta le Servlet funzionando come un server web Java enabled; Modalità di supporto ad altro server web: fornisce l infrastruttura di gestione JSP e Servlet ad un server web che ne è sprovvisto. Le modalità di funzionamento di Tomcat come supporto ad un server web esterno sono le seguenti: In Process: la JVM che supporta JSP e le Servlet è nello stesso spazio di indirizzamento del server web, la comunicazione avviene via JNI (Java Native Interfaces); Out of Process: la JVM che supporta JSP e le Servlet è in uno spazio di indirizzamento separato, la comunicazione avviene tramite socket TCP/IP L architettura di Tomcat L architettura interna di Tomcat si articola in: Connettori, Engine, Hosts e Contesti. Connettore Definisce un interfaccia di comunicazione standard fra Tomcat ed il mondo esterno. Sebbene sia in grado di ricevere le richieste direttamente dalla rete, i connettori permettono a Tomcat di riceverle in un livello inferiore. In questo modo, sia le richieste di un browser che quelle di gestione di file JSP o Servlet di un server web passano per un connettore. Sono previsti connettori in grado di ricevere richieste da server web 22

23 (ad esempio, Apache HTTP Server), server proxy e sistemi di bilanciamento del carico che supportano i protocolli AJP. Engine Tomcat 6.0 utilizza Jasper 2 JSP Engine per l implementazione delle specifiche JavaServer Pages 2.0. Le caratteristiche di tale engine comprendono la compilazione in background delle pagine dinamiche di tipo JSP e la ricompilazione automatica delle pagine modificate al momento del loro caricamento. A tale scopo viene utilizzato, nella versione 6.0, il compilatore Java Eclipse JDT, ma è ancora possibile utilizzare Ant e javac. Contesto Un contesto è un componente che rappresenta l applicazione web in esecuzione all interno dell host. Esso funge da contenitore per l applicazione, viene generato all'avvio di Tomcat e rimane attivo anche negli intervalli di tempo in cui non è interrogato. In funzione delle richieste ricevute, il suo contenuto cambia ed ogni elemento contribuisce a definire l'ambiente di tutta la sezione. 3.3 MySQL I DataBase Management System (DBMS) sono i prodotti software in grado di gestire i database. Le loro caratteristiche sono: capacità di gestire grandi quantità di dati condivisione dei dati fra più utenti e applicazioni utilizzo di sistemi di protezione e autorizzazione per l'accesso ai dati stessi Possiamo identificare diversi tipi di database, in base alla loro struttura logica: database gerarchici database reticolari database relazionali database ad oggetti MySql, che organizza i dati in tabelle. I database relazionali si basano sulle relazioni fra i dati, i quali vengono presentati come un insieme di tabelle ciascuna composta da righe e colonne. Possiamo affermare che: ogni tabella contiene i dati relativi ad una entità; le colonne della tabella rappresentano i campi, ovvero le proprietà o attributi dell'entità; le righe della tabella esprimono le ricorrenze dell'entità. MySQL appartiene al modello relazionale ed è un Relational database management system (RDBMS), composto da un client con interfaccia a caratteri e un server, entrambi disponibili sia per sistemi Unix come GNU/Linux che per Windows, anche se prevale un suo utilizzo in ambito Unix. 23

24 3.3.1 MySQL Workbench Per l utilizzo di MySql ci siamo avvalsi di MySQL Workbench, uno strumento visuale di progettazione per database, che integra sviluppo SQL, gestione, modellazione dati, creazione e manutenzione di database MySQL all'interno di un unico ambiente sinergico. In particolare ho utilizzato MySQL Workbench 5.2. In questa versione l applicazione si è evoluta in un completo strumento visuale per database. Oltre alla modellazione dati, essa è dotata di un editor SQL ed una interfaccia di amministrazione del database server. 3.4 Hibernate L' Object-Relational Mapping (ORM) è una tecnica di programmazione che favorisce l'integrazione di sistemi software aderenti al paradigma della programmazione orientata agli oggetti con sistemi RDBMS (Relational Database Management System). Un prodotto ORM fornisce, mediante un'interfaccia orientata agli oggetti, tutti i servizi inerenti alla persistenza dei dati, astraendo nel contempo le caratteristiche implementative dello specifico RDBMS utilizzato. L'uso di un ORM favorisce il raggiungimento di più alti standard qualitativi software, migliorando in particolare le caratteristiche di correttezza, manutenibilità, evolvibilità e portabilità. Hibernate è una libreria open source per lo sviluppo di applicazioni Java che fornisce un servizio di Object Relational Mapping (ORM), ovvero che gestisce la rappresentazione e il mantenimento su database relazionale di un sistema di oggetti Java. Hibernate è distribuito in licenza LGPL. Lo scopo principale di Hibernate è quello di fornire un mapping delle classi Java in tabelle di un database relazionale; sulla base di questo mapping Hibernate gestisce il salvataggio degli oggetti di tali classi su database. Si occupa inoltre del reperimento degli oggetti da database, producendo ed eseguendo automaticamente le query SQL necessarie al recupero delle informazioni e la successiva reistanziazione dell'oggetto precedentemente mappato su database. L'obiettivo di Hibernate è quello di esonerare lo sviluppatore dall'intero lavoro relativo alla persistenza dei dati. Hibernate si adatta al processo di sviluppo del programmatore, sia se si parte da zero sia se si ha un database già esistente. Hibernate genera le chiamate SQL e solleva lo sviluppatore dal lavoro di recupero manuale dei dati e dalla loro conversione, mantenendo l'applicazione portabile in tutti i database SQL. Hibernate fornisce una persistenza trasparente per "Plain Old Java Object"; l'unica grossa richiesta per la persistenza di una classe è la presenza di un costruttore senza argomenti. Oggetti correlati possono essere configurati per effettuare operazioni a cascata gli uni sugli altri. Ciò può ridurre il tempo di sviluppo e assicurare l'integrità referenziale. Una funzionalità di dirty checking evita azioni di scrittura sul database non necessarie, effettuando update SQL solo sui campi modificati sugli oggetti persistenti. Hibernate fornisce inoltre un linguaggio ispirato all'sql chiamato Hibernate Query Language (HQL), che permette di scrivere queries SQL-like sugli oggetti. 24

25 3.5 JavaMAIL JavaMail API è un package della Sun Microsystems arrivato alla versione che fornisce le classi necessarie ad implementare applicazioni per la posta elettronica in linguaggio Java completamente funzionanti. Non contiene componenti per la GUI, per cui l'interfaccia è a pieno carico del programmatore e questo la rende utilizzabile sia in applicazioni desktop che sul lato server, ad esempio per implementare una WebMail. JavaMail Supporta tutti i protocolli di posta elettronica, anche nelle diverse versioni, ma i principali sono: POP (Post Office Protocol) permette di ricevere la posta da un server remoto(server POP), è necessario per le persone non connesse in permanenza in internet a consultare la posta anche in modalità offline. Ci sono due versioni di questo protocollo, pop2 e POP3, e sono assegnate rispettivamente le porte 109 e 110. IMAP (Internet Message Access Protocol) costituisce un'alternativa al protocollo POP e possiede maggiori funzionalità: permette la gestione di accessi simultanei, la gestione di più caselle elettroniche, offre anche un criterio di selezione dei messaggi di posta SMTP (Simple Mail Transfer Protocol) è il protocollo standard per il trasferimento della posta da un server ad un altro in modalità point-to-point. E' un protocollo orientato alla connessione, incapsulato all'interno di un pacchetto TCP/IP. La posta è consegnata direttamente al server del destinatario (porta default 25). MIME (Multipurpose Internet Mail Extensions). Le specifiche di base del protocollo SMTP richiedono che i caratteri trasmessi siano codificati in codici ASCII su 7 bits Questo di fatto limita le a messaggi che, quando trasmessi, includono solo i caratteri sufficienti per scrivere in un numero limitato di lingue. Il MIME definisce meccanismi atti a spedire altri tipi di informazione con l' , potendo includere testo scritto in lingue diverse dall'inglese usando codifiche diverse dall'ascii, e contenuti binari come immagini, suoni e filmati, oppure programmi. Attualmente le versioni più diffuse sono la 3 per POP e la 4 per IMAP. JavaMail supporta tutti questi protocolli, ma non ne è limitato, in quanto implementa un'architettura a provider, che consente di svincolare le applicazioni dal reale protocollo utilizzato, creando una astrazione di un completo sistema di posta elettronica. In modo similare a quanto avviene in JDBC, dove la comunicazione effettiva al database avviene tramite driver specifici, allo stesso modo JavaMail si astrae dai protocolli specifici, che sono comunque forniti assieme al package principale. 25

26 3.6 Eclipse L ambiente di sviluppo utilizzato per questo progetto è Eclipse IDE for Java EE Dvelopers, nella versione Helios, uno dei più noti Ambienti di Sviluppo Integrati basati sul concetto di Open Source. Eclipse è un ambiente di sviluppo integrato multi-linguaggio e multipiattaforma. Ideato da un consorzio di grandi aziende chiamato Eclipse Foundation, viene sviluppato da una comunità strutturata sullo stile dell'open source. Nella home page di Eclipse viene specificato lo scopo della comunità di Eclipse che è, appunto, quello di fornire una piattaforma di sviluppo ed un framework applicativo per lo sviluppo di software. Ecco uno stralcio di quanto riportato sul sito: «Eclipse is an open source community whose projects are focused on providing a vendorneutral open development platform and application frameworks for building software.» Il componente base è l'eclipse SDK, disponibile per tutte le piattaforme (Windows, Linux, Solaris, ecc.). A tale componente è poi possibile aggiungere parecchi strumenti e plugin, delle componenti software ideate per uno specifico scopo che chiunque può realizzare, che forniscono ulteriori potenzialità ad Eclipse. Eclipse non necessita di installazione, per avviarlo è sufficiente eseguire il file eclipse.exe. Fornisce numerosi strumenti di supporto allo sviluppo che aiutano a velocizzare le operazioni ripetitive e permette di inserire in modo automatico parti di codice standard. Ma gli aiuti più immediati li offre l interfaccia attraverso le sue sezioni: PERSPECTIVE PACKAGE EXPLORER OUTLINE EDITOR CONSOLE Figura 5: Sezioni di Eclipse 26

27 Outline View: mostra i metodi implementati e le variabile definite. Navigator View: mostra i progetti e tutti i file appartenenti ad essi. Perspectives: sono raggruppamenti di funzionalità dell IDE, fatti in base ad una specifica operazione di sviluppo. La Java perspective ad esempio riunisce strumenti di stesura e organizzazione del codice mentre la Debug perspective fornisce strumenti in fase di debug. Console: Serve a visualizzare immediatamente e nel dettaglio tutti gli eventuali errori che si verificano in seguito all esecuzione di un progetto o di un file. Ovviamente le funzionalità che quest IDE offre sono molto più numerose di quelle citate e diversificate a seconda della tecnologia che si sta utilizzando e della versione di Eclipse, in ogni caso costituisce sempre un ottimo punto di partenza per lo sviluppo delle più variegate applicazioni. 3.7 Tecnologie per la condivisione del codice Per poter lavorare in gruppo senza dover perdere tempo per integrare le parti di codice realizzare da ciascun componente, abbiamo utilizzato il servizio di hosting dell applicazione offerto da Google code integrato con un software che effettuava il controllo sul versioning e l integrazione. Google Code E un servizio di hosting di progetti che è disponibile gratuitamente per tutti i progetti Open Source approvati dall'organizzazione Open Source Initiative. Il sito limita il numero di progetti che una persona può avere a 25. Inoltre c'è un limite al numero di progetti che possono essere creati in un giorno, ma per le nostre necessità offriva tutte le risorse di cui avevamo bisogno. TotrtoiseSVN Per il controllo del versioning e per l integrazione delle parti di codice abbiamo utilizzato TortoiseSVN, è un client grafico, scritto per girare come un'estensione di Microsoft Windows. È un programma gratuito rilasciato sotto GNU General Public License che nel 2007 TortoiseSVN ha vinto il premio di SourceForge.net per il più utile strumento per gli sviluppatori, votato dalla comunità. Grazie a TortoiseSVN è possibile lavorare sui file in locale e trasferire il lavoro eseguito su un repository online, che nel nostro caso era costituito da Google Code. Per condividere parti di codice realizzate in locale, utilizzando TortoiseSVN, quanto realizzato deve essere semplicemente committato e cioè inviato al server SVN centrale. Allo stesso modo per aggiungere le modifiche effettuate dagli altri partecipanti al progetto bisogna solo fare l update e tutte le modifiche presenti nel repository on line verranno integrate nel nostro progetto. Inoltre ha le funzionalità per il controllo e la gestione dei conflitti, ovvero per gestire delle modifiche effettuate su stesse parti di codice. 27

28 4 Modellazione del Database Il database costituisce una parte fondamentale dell applicazione web perche fornisce un punto di appoggio per tutti i dati che vengono trattati, sia quelli che servono ai clienti per avere informazioni sui loro dati personali, sui prodotti presenti nel catalogo, sugli ordini effettuati in passato. Ma serve anche per conservare tutti i dati che vengono inseriti dal cliente in seguito alla sua registrazione o all inserimento di una nuova proposta di vendita. 4.1 Diagramma Entità-Relazione Nel diagramma ER vengono illustrate le entità del Database a cui la web application si connette per: Ricavare le informazioni riguardanti i prodotti disponibili nel catalogo; Memorizzare le informazioni di un utente che effettua una nuova registrazione e accedervi poi per la verifica del login e per la ricapitolazione dei relativi dati personali; Memorizzare le nuove richiesta di acquisto e per visualizzarle in seguito; Memorizzare le informazioni relative ad una nuova inserzione e per accedervi. Memorizzare nuove categorie e modificarle. Figura 6: Diagramma ER Da rilevare in questo diagramma è l apparente ciclo che si crea tra le entità Utente, Articolo e Ordine. La connessione ciclica è dovuta alla necessità che ogni articolo avesse un inserzionista e che ogni ordine avesse un acquirente, ma nell implementazione opportuni controlli impediscono che un inserzionista acquisti un prodotto inserito da lui impedendo così il verificarsi di comportamenti ciclici. 28

29 4.2 Diagramma Relazionale Nel seguente diagramma Relazionale sono rappresentate tutte le entità e le relazioni del database sotto forma di tabelle, con i relativi attributi. Figura 7: Diagramma Relazionale L utente assume il ruolo principale all interno del database, perché ha molteplici possibilità di azione. Infatti può sia essere un acquirente, motivo per cui la tabella ordine ha come chiave esterna l Id dell utente, ma può essere anche un inserzionista e tutti gli articoli presenti nella relativa tabella hanno un riferimento all Id dell inserzionista, che è ovviamente un campo univoco come lo username. Inoltre tra le tabelle Articolo e Ordine esiste una relazione M-N che nel diagramma relazionale è mappata attraverso la relazione composizione ordine, questa scelta è stata fatta perché si suppone che un ordine possa essere composto da più articoli e un articolo possa appartenere a più ordini. Infine la tabella Categoria ha una relazione ciclica su se stessa in quanto abbiamo implementato la possibilità per ogni categoria di avere delle sottocategorie. 29

30 5 Progettazione UML dell architettura In questo capitolo verrà presentata l architettura dell applicazione avvalendosi della metodologia UML. 5.1 Diagramma dei package Il diagramma dei package è una rappresentazione ad alto livello dell architettura della Web Application. Figura 8: Diagramma dei Package 30

31 I package rappresentati si trovano tutti all interno del package it.mercatino. Le funzionalità della web application sono distribuite tra i vari package, non ne esiste uno principale, ma ve ne sono più di uno con un ruolo maggioritario nella struttura. Il package hibernate contiene tutte le classi che abbiamo generato automaticamente attraverso le funzionalità di reverse engineering di MyEclipse. In particolare ci sono tutte le classi DAO che contengono le query che servono ad accedere direttamente al database, poi ci sono tutte le classi che rappresentano le entità e i file di mapping di hibernate con le entità. A questo package si devono connettere tutti gli atri package che devono effettuare gli accessi al database e in più è connesso anche il package composite che contiene solo l interfaccia per l implementazione del pattern composite. Il package utente contiene solo la classe UtenteUtil, però si è ritenuto necessario crearlo in quanto questa classe contiene tutte le funzioni che si occupano degli opportuni controlli per la gestione degli utenti, interfacciandosi direttamente con le opportuni classi presenti nel package hibernate. Utilizzano la classe UtenteUtil le classi contenute nei package autenticazione per effettuare le opportune verifiche sull esistenza dell utente che ha inserito le proprie credenziali in fase di Login, in datiutente dove sono implementate tutte le funzionalità che permettono ad un utente di vedere la ricapitolazione dei suoi dati persona e di modificarli, in registrazione per le funzionalità di memorizzazione delle informazioni relative ai nuovi utenti, ma anche per le funzionalità riservate al gestore del servizio, per il cambio di stato delle richieste di registrazione. Un altro package molto importante è catalogo, in queste sono implementate tutte le funzionalità per la visualizzazione del catalogo, per effettuare la ricerca al suo interno e per visualizzare i dettagli degli articoli in esso contenuti. È connesso ad utenti in quanto ogni articolo ha un inserzionista e la connessione è necessaria per recuperare questa informazione, da usare nella visualizzazione del catalogo organizzato per inserzionisti e nel dettaglio degli articoli. E connesso con categorie, per permettere la visualizzazione del catalogo per categorie e per sottocategorie. E connesso a ordini perché è presente un aggiornamento sulla quantità disponibile dei prodotti presenti che viene effettuato al completamento di ogni ordine. Al package catalogo, fa riferimento carrello. In quest ultimo sono implementate le funzionalità per la creazione del carrello e per la modifica e l eliminazione del suo contenuto. Ovviamente tutti i prodotti inseriti nel carrello, provengono dal catalogo, ecco il motivo della connessione citata prima. Nel processo di acquisto, dopo il riempimento del carrello si passa alla conferma dell ordine. Queste funzionalità, comprese quelle di memorizzazione nel database, sono incluse nel package ordine, che si interfaccia con catalogo e utenti per avere tutte le informazioni che compongono un ordine. Inoltre è connesso con command, in quanto sfrutta le funzionalità, riservate all amministratore di modifica dello stato delle richieste di acquisto. 31

32 Il package command deve il suo nome al fatto che contiene l implementazione del pattern command, per la modifica dello stato delle richieste di acquisto appena descritta e per la modifica dello stato delle richieste di registrazione descritta in precedenza. Al suo interno è anche implementato il pattern composite associato al command per formare un macro-command. Questa integrazione è stata realizzata per abbinare alle funzionalità del cambio di stato quelle di invio di informative agli interessati. Ultimo package di tipo implementativo è inserzioni, caratterizzato dalle funzionalità per la creazione e la modifica delle inserzioni da parte degli utenti. Infine c è il package test, dove sono implementate tutte le classi di test. 5.2 Diagrammi di stato In questo paragrafo si presentano i diagrammi di stato, per descrivere il comportamento dell applicazione in alcune situazioni che prevedono dei cambiamenti di stato. Richiesta di registrazione Figura 9: Diagramma di stato "Richiesta di registrazione" Dall analisi dei requisiti è emerso che bisognava fare in modo che la registrazione di un nuovo utente fosse soggetta all approvazione da parte del gestore del sistema. Per questa ragione abbiamo previsto una prima fase in cui ogni richiesta di registrazione da parte di un nuovo utente venisse memorizzata sul database, settando il campo Stato Registrazione a 0, ovvero in attesa di conferma. Ovviamente un utente che abbia la sua richiesta di registrazione in attesa di conferma, se prova ad effettuare il login viene riconosciuto dal sistema come tale e gli viene segnalato che deve attendere la conferma dell approvazione della registrazione, che gli verrà notificata per . Fino a quel momento ha i diritti di accesso di qualsiasi altro utente non registrato. 32

33 Dopo l approvazione della richiesta da parte dell amministratore, l utente avrà tutti i diritti di accesso all applicazione di un utente registrato. Una richiesta rifiutata può essere approvata dall amministratore in un secondo momento, perché abbiamo ritenuto che l amministratore possa entrare in possesso di nuove informazioni sull utente la cui richiesta di registrazione è stata rifiutata, considerando che nel momento in cui effettua il cambio di stato in Rifiutato, deve compilare un apposito modulo in cui specifica la motivazione. Invece le registrazioni approvate non possono più essere soggette a cambi di stato. Richiesta di acquisto Da confermare [Ordine confermato] In spedizione [Ordine rifiutato] [Ordine evaso] Rifiutato Evaso Figura 10: Diagramma di stato: Richiesta di acquisto Tra i controlli che i requisiti imponevano di attribuire al gestore del servizio vi erano anche quelli di verificare ed evadere le richieste di acquisto, ovvero di approvarle mettendole in spedizione oppure rifiutarle e di chiudere gli ordini quando le spedizioni sono state completamente effettuate. Per questo è stato previsto un cambio di stato per gli ordini. Un ordine appena effettuato dall utente è considerato in sospeso, ovvero in attesa di verifica da parte dell amministratore. Appena questa verifica viene effettuata lo stato della richiesta di acquisto può cambiare in approvato, ovvero messo in spedizione, oppure in rifiutato. Infine l amministratore, che attraverso un apposita sezione può accedere all elenco di tutti gli ordini raggruppati per stato, può visualizzare i dettagli di gli ordini in spedizione e convertirne il loro stato in evasi. Da notare è che un ordine rifiutato non può esser approvato in un secondo momento come invece accade per le richieste di registrazione. 33

34 5.3 Diagrammi delle classi e Design Pattern Utilizzati In questo paragrafo si presentano i diagrammi delle classi dell applicazione Diagrammi delle classi in the large Di seguito sono riportati i diagrammi delle classi in the large che permettono di avere una panoramica generale dell applicazione in quanto contengono tutte le classi che appartengono all applicazione e le interconnessioni tra queste. In particolare sono stati realizzati due diagrammi, uno riservato alle classi generate da Hibernate e uno per tutte le altre classi dell applicazione. Classi Hibernate Legenda Figura 11: Diagramma delle classi in the large "Classi Hibernate" Categoria Utente Ordine Articolo Le classi sono colorate con colori diversi a seconda delle entità del database a cui si riferiscono, come indicato nella Legenda. E importante osservare come le classi di tipo DAO si interfacciano solo con le classi Util, permettendo una netta suddivisione tra il livello implementativo e quello delle action. Di seguito è possibile osservare il diagramma in the large di tutte le altre classi che appartengono all applicazione. 34

35 35

36 5.3.2 Hibernate, Design Pattern DAO Tra i diagrammi delle classi in the small che servono a far vedere i dettagli d implementazione della web application particolarmente interessante è quello relativo alle classi di accesso al Database. Volendo utilizzare le funzionalità di hibernate è stato necessario implementare il pattern DAO generando, a partire dalla struttura del database, le classi DAO (Data Access Object), di cui nel seguito è possibile vederne struttura e connessioni. Figura 12: Diagramma delle classi "Hibernate, Design Pattern Dao" Le classi che appartengono a questo diagramma sono l esatta trasposizione delle tabelle del Database. In ognuna di queste è possibile osservare la presenza delle funzioni di save(), delete() e merge(), ovvero di salvataggio, cancellazione e aggiornamento dei dati sul database. In ognuna di queste classi inoltre vi sono le funzioni, generate automaticamente, di ricerca per ogni colonna della relativa tabella. A queste si aggiungono poi delle funzioni che abbiamo creato in fase di sviluppo, per ricavare dati nel database secondo particolari criteri di ricerca. 36

37 5.3.3 Le classi Util, Design Patter Facade Figura 13: Diagramma delle classi "Le classi Util, Design Patter Singleton" La struttura dell applicazione è stata progettata utilizzando delle classi di utilità che sono le uniche ad interfacciarsi con le classi DAO. Quindi le Action del sistema possono evolvere indipendentemente dalle classi che si interfacciano con il database in quanto le classi Util ne nascondono la loro presenza. Considerando che il Design Pattern Facade ha tra i suoi obiettivi quello di minimizzare la comunicazione e le dipendenze tra i diversi sottosistemi, creando un interfaccia unificata e semplificata per accedere alle funzionalità offerte da un sottosistema, lo abbiamo implementato facendo in modo che le classi Util fornissero l interfaccia tra i due sottosistemi costituiti rispettivamente dalle Action del sistema e dalle classi che si interfacciano con il Database. 37

38 5.3.4 Le classi Util, Design Patter Singleton Le classi che si interfacciano con i Dao sono quelle che abbiamo indicato con il suffisso Util. La prima che andiamo ad analizzare è la classe UtenteUtil. Figura 14: Diagramma delle classi UtenteUtil In questa classe sono implementate funzioni che servono soprattutto per prelevare informazione dal database interfacciandosi con la classe UtenteDAO. Le informazioni ottenute vengono poi utilizzate per effettuare controlli ad esempio sull esistenza di un particolare utente come fanno le classi verificaesistenzausername() e verificaesistenzautente(), oppure per fornire informazioni ad una particolare pagina. Ad esempio la funzione getutentebyusername() viene utilizzata nella pagina di ricapitolazione dei dati personali di un utente, invece le funzioni getutentinonconfermati() e getutentirifiutati sono utilizzate nella pagina che l amministratore usa per visualizzare tutte le richieste di registrazione, raggruppate per stato. In questa classe sono implementate però anche delle funzioni che servono a memorizzare, aggiornare o eliminare dati dal database. Alcuni esempi sono le funzioni inserisci Utente() e update Utente() che servono rispettivamente a memorizzare le informazioni di un utente in fase di registrazione e in fase di modifica dei dati. E presente anche elimina Utente() che viene richiamata dall Amministratore quando vuole eliminare una richiesta di registrazione rifiutata. 38

39 La seconda classe Util particolarmente interessante è CatalogoUtil. Figura 15: Diagramma delle classi "CatalogoUtil" Anche in questa classe come nella precedente è possibile trovare tutte le funzioni che richiedono una connessione ad una classe Dao, che in questo caso è ArticoloDAO. Infatti qui sono implementate le funzioni che servono alla visualizzazione di tutti gli articoli del catalogo, che può essere fatta prelevando le relative informazioni dal Database, usando funzioni come getarticoliutente() o getarticolicategoria che servono rispettivamente a prendere tutti gli articoli appartenenti ad una particolare categoria o inseriti da un particolare utente. La funzione newarticolo() serve a memorizzare una nuova inserzione nel catalogo. Più numerose sono invece le funzioni che permettono di aggiornare le inserzioni in modo fa poterne modificare tutti i campi, come richiesto dai requisiti. Un'altra classe Util utilizzata è CategoriaUtil. Figura 16: Diagramma delle classi "CategoriaUtil" Questa classe contiene tutte le funzioni che servono per la creazione, l aggiornamento e l eliminazione delle categorie. L amministratore infatti ha a disposizione una particolare sezione per queste operazioni. 39

40 In particolare può creare una nuova catagoria, richiamando quindi la funzione newcategoria(), può modificarne il nome con modifyname(), può cambiarne la categoria padre con updatefather(), che memorizza il cambiamento dopo che è stata richiamata la funzione getcatchildren() per verificare che la nuova categoria scelta come genitore non sia un figlio della stessa, per evitare cicli. Inoltre le categorie possono essere eliminate, attraverso la funzione delete(), a condizione che la categoria in questione non sia nella condizione di contenere articoli e di non avere una categoria padre diversa nella quale questi articoli possono essere spostati. Infine ci sono tutte le funzioni che servono per la navigazione del catalogo per categorie. L ultima classe Util particolarmente rilevante è OrdineUtil. Figura 17: Diagramma delle classi "OrdineUtil" Questa è l unica delle classi Util ad interfacciarsi con tre classi Dao, ovvero con ArticoloDAO, OrdineDAO e ComposizioneOrdineDAO. Queste connessioni sono dovuta al fatto che un ordine è costituito da articoli e un articolo può appartenere a più ordini e in questo modo si possono ricavare tutte le informazioni necessarie alla composizione di un ordine, sia per crearlo nella tabella ordine, ma anche per visualizzarlo e aggiornarne lo stato. Non sono presenti funzioni che permettono di eliminare gli ordini dal database e questo è dovuto a una scelta progettuale di mantenere lo storico degli ordini. Inoltre per gestire la storicizzazione degli articoli relativi agli ordini, considerando che un articolo acquistato può essere modificato dall'inserzionista, è stato previsto uno stato per l'entità Articolo, che distinguerà se esso è relativo al catalogo, oppure se è relativo ad un ordine. 40

41 Quando viene effettuato un ordine vengono salvate tutte le entry del carrello come articoli il cui stato sarà relativo all ordine e all'ordine stesso saranno associati questi nuovi articoli. In questo modo, ogni volta che vengono richiamati i dettagli dell'ordine, si ricavano le informazioni riguardanti gli articoli al momento del loro acquisto e non le informazioni (eventualmente modificate) dell'articolo attuale (se ancora presente nel catalogo). Da osservare per tutte le classi Util è l implementazione del pattern Singleton. Infatti a ognuna di queste classi è stata data la responsabilità di creare le proprie istanze controllando che non vi sia più di una istanza contemporaneamente. Le classi Util servono a fornire delle funzionalità, senza memorizzare informazioni di stato, pertanto è stato possibile implementarle con il Pattern Singleton, in modo tale che le altre classi potessero accedere sempre alla stessa istanza di queste Il Catalogo, Design Pattern Composite Il catalogo è stato progettato come una struttura composita, costituita da categorie e articoli che si combinano rispettando opportune dipendenze. Il Design Pattern Composite che serve a comporre oggetti in strutture ad albero per rappresentare gerarchie parte-tutto e consentire ai client di trattare oggetti singoli e composizioni in modo uniforme, in fase di progettazione è stato considerato il modo più adatto per implementare le funzionalità del catalogo. «exception» SinglePartException «interface» ElementoCatalogo +add(in e : ElementoCatalogo) +remove(in e : ElementoCatalogo) +getchild(in i : int) : ElementoCatalogo +getfather() : ElementoCatalogo +iscomposite() : bool +getnumeroelementi() : int * Articolo -idarticolo : int -categoria : Categoria -utente : Utente -nome : string -descrizione : string -foto : string -prezzo : float -data : Date -quantità : int -quantitàresidua : int +add(in e : ElementoCatalogo) +remove(in e : ElementoCatalogo) +getchild() : ElementoCatalogo +getfather() : ElementoCatalogo +iscomposite() : bool +getnumeroelementi() : int Categoria -idcategoria : int -nome : string -categoria : Categoria +add(in e : ElementoCatalogo) +remove(in e : ElementoCatalogo) +getchild(in i : int) : ElementoCatalogo +getfather() : ElementoCatalogo +iscomposite() : bool +getnumeroelementi() : int -initchildren() +getchildrencategories() +getallchildrencategories() -children 1 per tutti gli e in children: e.getnumeroelementi() e restituisci la somma Figura 18: Diagramma delle classi "Il Catalogo, Design Pattern Composite" Come previsto dal Pattern Composite, vi è una classe Elemento Catalogo che implementa le funzionalità in comune tra tutte le classi che costituiranno effettivamente gli oggetti del catalogo. In particolare sono 41

42 presenti le funzioni add() e remove(), per aggiungere e rimuovere elementi dal catalogo, oppure la funzione iscomposite() che restituendo un valore booleano indica se un oggetto è composito o meno, ovvero se è un articolo o una categoria. Le classi che implementano questa interfaccia sono Categoria e Articolo. La prima all interno del Pattern rappresenta il Composite, che memorizza i componenti figli e implementa le operazioni correlate ai figli definite nell interfaccia, la seconda è l elemento foglia che non può essere scomposto. In particolare i vantaggi del pattern Composite sono utilizzati nel calcolo degli elementi presenti in una categoria, in quanto questo conteggio include, oltre agli elementi foglia della stessa, anche gli elementi presenti in tutte le sue sottocategorie, che vengono iterativamente visitate fino a giungere ai loro elementi foglia. Questa quantità è visualizzabile quando si naviga nel catalogo usando l albero delle categorie ed è aggiornata ogni volta che c è un cambiamento della quantità di articoli presenti nelle varie categorie Aggiornamento di Stato e Invio , Design Pattern Command Per implementare le funzionalità riservate all amministratore è stato utilizzato il pattern Command. aggiornastatocommand.execute() AggiornaStato -aggiornastatocommand : Command +aggiornastato() +setaggiornastato(in aggiornastato : Command) 1 1 «interface» Command +execute() * Send AggiornaStatoRegistrazione AggiornaStatoOrdine MacroCommand -commands -host : string -from : string -to : string -subject : string -text : string -sender : Sender +execute() -username : string -stato : int -motivazione : string -receiver : CambioStato +execute() -ordine : Ordine -stato : int -motivazione : string -receiver : CambioStato +execute() +execute() +add(in c : Command) 1 per ogni c in commands c.execute() sender.inviamail() /* Parametri non specificati per semplicità */ receiver.aggiornastatoordine() /* Parametri non specificati per semplicità */ receiver.aggiornastatoregistrazione() /* Parametri non specificati per semplicità */ CambioStato +aggiornastatoordine(in ordine : Ordine, in statoordine : int, in motivazionerifiuto : string) +aggiornastatoregistrazione(in username : string, in statoregistrazione : int, in motivazionerifiuto : string) Sender +inviamail(in host : string, in from : string, in to : string, in subject : string, in text : string) : bool Figura 19: Diagramma delle classi "Aggiornamento di Stato e Invio , Design Pattern Command" 42

43 All interno dell applicazione l amministratore ha il compito di cambiare lo stato delle richieste di registrazione, approvandole o rifiutandole, e di cambiare lo stato delle richieste di acquisto in rifiutate, in spedizione o evase. Inoltre in corrispondenza di ognuna di queste operazioni, la traccia richiedeva di informare tutti gli utenti interessati con una automatica. Queste funzioni coinvolgono molte classi diverse, ma le operazioni che svolgono sono pressoché identiche, ovvero devono aggiornare il campo stato nell opportuna tabella e richiamare la funzione di invio delle . Considerando che il pattern Command permette di incapsulare richieste in un oggetto, consentendo di parametrizzare i client con richieste diverse, abbiamo ritenuto opportuno utilizzarlo per implementare le operazioni di cambio stato e di invio . Inoltre per combinare le richieste di cambio stato e di invio come fossero una sola, è stato integrato il pattern Composite per creare un MacroCommand. Nel dettaglio la Classe AggiornaStato rappresenta l Invoker, ovvero la classe che richiama le funzionalità implementate nel command, mentre la classe Command costituisce l interfaccia. L interfaccia è poi implementata da quattro classi: AggiornaStatoRegistrazione e AggiornaStatoOrdine, che all interno del metodo Execute() invocano i metodi del Receiver CambioStato, la classe Send che sfrutta i metodi implementati nel Receiver Sender. Infine vi è la classe MacroCommand che serve appunto ad inglobare in una sola le richieste di cambio stato e di invio . Le due classi che fanno da Receiver, come previsto dal Pattern, implementano le funzionalità per svolgere le operazioni associate a una richiesta Calcolo del Prezzo Totale del Carrello, Design Pattern Strategy Per effettuare il calcolo del prezzo totale dei prodotti presenti nel carrello è stato realizzato un semplice algoritmo incapsulato nella struttura dettata dal Pattern Strategy. Figura 20: Diagramma delle classi "Calcolo del Prezzo Totale del Carrello, Design Pattern Strategy" 43

44 La classe Carrello, rappresenta il Context, ovvero la classe con cui interagiscono i client, che contiene tutti i dati necessari all algoritmo. Infatti Carrello possiede una lista di tipo CarrelloEntry che fornisce tutte le informazioni sul contenuto del carrello. Il Context poi può inoltrare la richiesta all interfaccia CalocoloPrezzoTotale, che a sua volta la inoltrerà alla classe Concrete Strategy implementata da DefaultCalcoloPrezzoTotale, dove è effettivamente implementato l algoritmo. L utilizzo del pattern Strategy è stato preso in considerazione in previsione di sviluppi futuri come il calcolo del prezzo totale del carrello in modi differenti, considerando particolari offerte relative ad esempio a dei codici sconto o a dei particolari bonus a cui un cliente potrebbe avere diritto. Questo richiederebbe l implementazione di diversi algoritmi di calcolo del prezzo che possono essere semplicemente aggiunti all interno di nuove classi di tipo Concrete Strategy Creazione del path per le immagini del Catalogo, Design Pattern Strategy Per generare il path all interno del quale memorizzare le immagini che vengono aggiunte nelle inserzioni, sono stati implementati due semplici algoritmi, organizzati nella struttura prevista dal Pattern Strategy. -instance imgpath : string UploadFileUtil +getinstance() : UploadFileUtil +setfilenamegenerator(in fng : FileNameGenerator) +upload(in file : File, in serverpath : string) : string -fng 1 1 «interface» FileNameGenerator +generatename(in file : File, in path : string, in extension : string) : string /* Per ottenere il path del file da caricare uso il FileNameGenerator */ String filepath = fng.generatename(file, imgpath, ".png"); /* a questo si aggiunge il path del server, per ottenere il path assoluto */ -defaultpath : string DefaultFileNameGenerator +generatefilename(in file : File, in path : string, in extension : string) : string -defaultpath : string HashFileNameGenerator +generatefilename(in file : File, in path : string, in extension : string) : string Figura 21: Diagramma delle classi "Creazione del path Immagini Catalogo, Design Pattern Strategy" La classe UploadFileUtil rappresenta il Context e richiede all interfaccia le funzionalità di generazione del path. La classe FileNameGenerator, che costituisce l interfaccia, è implementata da due Concrete Strategy: DefaultFileNameGenerator che usa la rappresentazione in millisecondi dell'istante corrente per generare il nome del file. Il secondo Concrete Strategy è HashFileNameGenerator che usa l'hash code del path assoluto del file per generare il nome del file stesso. Anche in questo caso l utilizzo del pattern Strategy è dovuto al fatto che è possibile creare molti diversi algoritmi per la generazione del path, che attraverso questa struttura potrebbero essere facilmente aggiunti. 44

45 5.4 Diagrammi di sequenza Per analizzare il comportamento della web application durante la sua esecuzione è utile servirsi di diagrammi di sequenza forniti da UML, i quali analizzano le interazioni che avvengono tra le classi ponendo particolare attenzione all aspetto temporale Cambio di Stato di una Registrazione, Design Pattern Command Figura 22: Diagramma di sequenza "Cambio di Stato di una Registrazione, Design Pattern Command" Come già spiegato attraverso il relativo diagramma delle classi per implementare le funzionalità di aggiornamento di stato riservate all amministratore è stato utilizzato il Pattern Command. Nel caso del cambio di stato delle richieste di registrazione, la Action principale istanzia il MacroCommand, richiedendo le funzionalità dei due Concrete Command AggiornaStatoRegistrazione e Send , che vengono accorpati nel MacroCommand attraverso la funzione add(). A questo punto viene istanziata la classe AggiornaStato che, in quanto invoker, avvia il meccanismo del pattern, richiamando il metodo Execute() del MacroCommand. Questo richiama poi i metodi Execute() del Concrete Command che utilizzeranno le funzioni implementate nei receiver CambioStato ed Sender per portare a termine il loro compito. In particolare il receiver CambioStato utilizza poi la funzione della classe UtenteUtil AggiornaStatoRegistrazione() per aggiornare l opportuno campo sul database. 45

46 5.4.2 Cambio di stato di una Richiesta di Acquisto, Design Pattern Command Figura 23: Diagramma di Sequenza "Cambio Stato Richiesta di Acquisto, Design Pattern Command" Il cambio di stato di una richiesta di acquisto ha come complicazione aggiuntiva, rispetto al caso precedente, il fatto che si debba inviare un ad ogni inserzionista di ogni prodotto contenuto nell ordine. Per questa ragione dopo le operazioni di istanziazione del MacroCommand c è un loop che aggiunge la funzionalità di invio dell per ogni inserzionista. Questo loop avrà effetto quando il MacroCommand richiamerà il metodo Execute() della classe Send , infatti questo metodo sarà richiamato un numero di volte pari al numero di comandi Send () richiamati nel loop precedente. 46

47 5.4.3 Creazione di una nuova inserzione Figura 24: Diagramma di sequenza "Creazione di una nuova inserzione" Per la creazione di una nuova inserzione la Action NuovaInserzione2Action prende un istanza della classe UploadFileUtil e successivamente richiama la su funzione upload() per avere il path all interno del quale collocare l immagine che verrà inserita. La classe Util fa a sua volta riferimento alla classe DefaultNameGenerator per ottenere il path del file. Successivamente la Action iniziale prende un istanza della classe CatalogoUtil, per utilizzare la sua funzione di memorizzazione di un nuovo articolo. La classe Util per portare a termine il suo incarico farà riferimento alla classe Articolo, che è considerato come un semplice contenitore di informazioni, e poi alla classe ArticoloDAO che contiene le query per l effettiva memorizzazione nel database attraverso la funzione save(). 47

48 5.4.4 Modifica di un inserzione esistente Figura 25: Diagramma di sequenza "Modifica di un inserzione esistente" Nella sezione di modifica di una nuova inserzione, l utente può modificarne tutti i campi e tra questi anche l immagine. Se questo avviene la action ModificaInserzione2Action prende un istanza della classe UploadFileUtil e successivamente richiama la su funzione upload() per avere il path all interno del quale collocare la nuova immagine, come avveniva nella creazione di un inserzione. In seguito ModificaInserzione2Action prende un istanza di CatalogoUtil e usa la sua funzione modifyarticolo(), la quale dopo aver utilizzato la funzione findbyid() della classe ArticoloDAO per individuare l oggetto Articolo da modificare, setta tutti i campi dell oggetto con i nuovi valori per i campi modificati, con i vecchi valori altrimenti. Infine richiama la funzione merge() di ArticoloDAO per rendere permanente l aggiornamento sul Database. 48

49 5.4.5 Calcolo del Prezzo Totale del Carrello, Design Pattern Strategy Carrello DefaultCalcoloPrezzoTotale CarrelloEntry setcarrelloprezzototale (DefaultCalcoloPrezzoTotale) totaleordine(carrelloentrylist) loop [per ogni CarrelloEntry in carelloentrylist] getprezzototarticolo() prezzototarticolo totcarrello La somma di tutti i prezzototarticolo Figura 26: Diagramma di sequenza "Calcolo del Prezzo Totale del Carrello, Design Pattern Strategy" Per poter calcolare il totale degli articoli presenti nel carrello, che possono differire per prezzo unitario e per quantità, la classe Carrello richiama la funzione totaleordine() della classe DefaultCalcoloPrezzoTotale dove è implementato il semplice algoritmo di calcolo del prezzo totale. Infatti questa funzione, iterando sugli elementi della lista di tipo CarrelloEntry, che ha ricevuto dalla classe Carrello, ne preleva il prezzototarticolo, che è pari al prezzo unitario per la quantità posta nel carrello, e lo somma al totale. Il totale è il valore di ritorno di questa funzione. 49

50 5.5 Diagramma di Deployment I diagrammi di deployment servono a documentare la distribuzione fisica di un sistema mostrando dove le varie parti di software vengono eseguite. Figura 27: Diagramma di Deployment In questa applicazione gli utenti accedono tramite un browser alla web application, questa a sua volta è collegata ad un database che si occupa di contenere tutte le informazioni necessarie all applicazione. 50

51 6 Implementazione dell Applicazione Viene proposta di seguito una panoramica generale dell applicazione corredata da screenshots e da una spiegazione rapida del relativo caso d uso illustrato. 6.1 Contenuti Statici Le pagine di contenuti statici più interessanti sono la home e la pagina di regolamento del mercatino la cui implementazione era richiesta dai requisiti. Figura 28: Screenshot "Home" Da notare è la presenza nella home del form di Login, è a questo form che si verrà rimandati ogni volta si cerchi di fare un operazione non autorizzata per utenti non registrati o quando si seleziona il link Login posto in alto a destra. Questo stesso link cambierà in Logout dopo essersi autenticati e diventerà l unico modo per effettuare il Logout. 51

52 Figura 29: Screenshot "Regolamento" 6.2 Navigazione del Catalogo La navigazione del catalogo è una funzionalità molto importante nel mercatino on-line perché permette di ricercare gli articoli nel catalogo usando diversi criteri e prendendo visione in seguito dei dettagli relativi agli articoli d interesse. La navigazione nello specifico può essere fatta attraverso l albero delle categorie, per inserzionista, ma anche attraverso una ricerca fatta per nome dell articolo e per fasce di prezzo. Di seguito è possibile osservare gli Screenshot relativi alle modalità di navigazione del catalogo appena indicati. 52

53 Figura 30: Screenshot "Navigazione del Catalogo per Categorie" Figura 31: Screenshot "Navigazione del catalogo per Inserzionista" 53

54 Figura 32: Screeshot "Risultato della Ricerca per nome articolo" Da osservare in questo ultimo Screenshot c è che i risultati delle ricerche possono essere ordinati cliccando sul nome nel campo che si vuole usare per effettuare l ordinamento. Ad esempio cliccando su Prezzo i prodotti vengono ordinati in base al valore del prezzo prima decrescente e poi crescente. 6.3 Effettuare un ordine Figura 33: Screenshot "DettaglioArticolo" 54

55 Dalla pagina del dettagli di un articolo lo si può aggiungere al carrello specificandone la quantità desiderata. Ogni volta che si aggiunge un articolo al carrello questo viene visualizzato con tutto il suo contenuto e può essere modificato sia eliminando articoli sia modificandone la quantità desiderata. Figura 34: Screenshot "Contenuto del carrello" Proseguendo nell acquisto appare il form per la conferma dei dati d acquisto. Figura 35: Screenshot "Form di conferma dati per l'acquisto" 55

56 Dalla voce Acquisti del menù principale è possibile accedere alla pagina di ricapitolazione di tutti gli acquisti effettuati da un utente, raggruppati per stato. Figura 36: Screenshot "Ricapitolazione Acquisti" Dal tastino accanto ad ogni acquisto è possibile accedere al dettaglio del relativo ordine. 6.4 Inserzioni Dal menu principale è possibile scegliere anche la voce Inserzioni, accedendo così ad una pagina che offre agli utenti le funzionalità per la creazione e la modifica delle inserzioni. Figura 37: Screenshot "Elenco e Inserimento inserzioni" 56

57 Figura 38: Screenshot "Modifica Inserzione" Questo è il form che appare quando si sceglie di modificare un inserzione già esistente. Lo stesso form appare quando si sceglie di inserire una nuova inserzione, ma senza i campi precompilati. 6.5 Gestione Dati Utente Dal menu principale si può accedere a una pagina di ricapitolazione dei dati personali di un utente e successivamente si può procedere alla loro modifica attraverso un form che appare precompilato. Figura 39: Screenshot "Form di Modifica dei Dati Utente" 57

58 6.6 Gestione Categorie All amministratore è riservato il compito della gestione delle categorie, questo infatti può aggiungerne di nuove o modificare quelle già esistenti. 6.7 Gestione Utenti Figura 40: Screenshot "Gestione Categorie" Un altro incarico dell amministratore è quello di gestione degli utenti, ovvero di approvare o rifiutare le richieste di registrazione che pervengono. Questo compito lo può svolgere attraverso l apposita sezione. Figura 41: Screenshot "Gestione Utenti" 58

59 6.8 Gestione Acquisti L ultimo compito importante che spetta all amministratore è quello di approvare, rifiutare ed evadere le richieste di acquisto. Queste possono essere visualizzate dall amministratore nell apposita sezione a cui può accedere attraverso la voce di menù Ordini che appare solo quando è loggato l amministratore, come accade per le due funzionalità precedenti. Figura 42: Screenshot "Gestione Ordini" Figura 43: Screenshot "Dettaglio Ordine" Visualizzando i dettagli di un ordine in spedizione può decidere di segnalarlo come evaso. 59