Relazione del Gruppo PowerGruppo2. Bonfigli Diego, Mandrioli Luca, Patrignani Marco, Tamburini Michele

Transcript

1 Relazione del Gruppo PowerGruppo2 Bonfigli Diego, Mandrioli Luca, Patrignani Marco, Tamburini Michele 16 giugno 2009

2 Indice 1 Considerazioni iniziali 1 2 Requisiti Modello dei Requisiti Elenco dei Requisiti Specifica dei Requisiti Stime e Metriche Stime con FP Stima dello Sforzo Analisi dei Rischi Risultati delle metriche e collaudi Diagrammi UML Use Cases Ricerca Autenticazione Gestione Carrello Activity Diagram State Diagram Deployment Diagram Class Diagram PackageDiagram Sequence Diagram Piano di Software Quality Assurance Scopo Aree di coinvolgimento Management Standards, pratiche, convenzioni e metriche Metriche i

3 ii INDICE 5.5 Revisioni Tools e Test Strumenti Utilizzati Strumenti utilizzati Relazione sulla base di dati Studio di Fattibilità Requisiti Progettazione Concettuale Progettazione Logica Progettazione Fisica Test Popolamento del Database Scelte Progettuali Organizzazione in cluster Data Tier Business Tier Web Tier Manuale Utente Come eseguire l applicazione L applicazione Guida all installazione e configurazione Installazione e configurazione di JBoss Installazione e Configurazione di MySql L applicazione Installazione e configurazione di Apache Diario di Gruppo Diari Personali Diario di Diego Bonfigli Diario di Luca Mandrioli Diario di Marco Patrignani Diario di Michele Tamburini A Notazione utilizzata 163 B Diagrammi aggiuntivi 165

4 Elenco delle tabelle 2.1 Tabella di Specifica dei Requisiti Tabella riassuntiva dei Function Points Tabella della stima con Adjusted FP Tabella della stima attraverso COCOMO II Tabella riassuntiva dei rischi riscontrati iii

5 iv ELENCO DELLE TABELLE

6 Elenco delle figure 3.1 Diagramma Gantt preventivo per la consegna al 22 maggio Diagramma Gantt effettivo per la consegna al 22 maggio Diagramma Gantt preventivo per la consegna al 19 giugno Diagramma Gantt effetivo per la consegna al 19 giugno Tabella riassuntiva per le metriche Istogramma della mancanza di coesione Use case diagram ad alto livello Use case diagram a più basso livello Use case diagram per la Ricerca di un libro Use case diagram della registrazione di un nuovo utente Activity diagram del flusso di business Activity diagram della procedura di autenticazione State diagram Deployment diagram Class diagram: Web Tier Class diagram: Business Tier Class diagram: strategy pattern Diagramma proposto dal libro: Burke,Java and XSLT Model View Control modellato dalle classi Sequence diagram di login dell utente v

7 vi ELENCO DELLE FIGURE 4.15 Sequence diagram per la ricerca di un libro Sequence diagram dell aggiunta di un libro nel carrello Sequence diagram dell operazione di checkout Sequence diagram della rimozione di un libro Sequence diagram per la visualizzazione dei dati utente Diagramma ER relativo alla progettazione concettuale Diagramma delle tabelle prodotto dalla progettazione logica Deployment diagram Finestra di gestione mostrata dal tool MySql Administator.. 96 B.1 Legenda notazione blueprint B.2 Blueprint homepage B.3 Blueprint homepage dopo il login B.4 Blueprint pagina utente B.5 Blueprint pagina di descrizione libro B.6 Blueprint carrello B.7 Wireframe homepage B.8 Wireframe homepage con maggiori dettagli

8 Capitolo 1 Considerazioni iniziali Questo capitolo contiene alcune considerazioni fatte dal gruppo all inizio del progetto. Innanzitutto si sono analizzate le varie metodologie di processo presentate a lezione e si è optato per AUP 1 in quanto unisce i punti forti di Agile Processing e RUP 2. Questa metodologia è sufficientemente lasca da dotarci della necessaria flessibilità per portare a compimento il progetto, inoltre ha un buon compromesso per quello che riguarda la documentazione da produrre. Non si pretende di avere tutti i documenti già stesi per incominciare l implementazione, come impone un approccio RUP, una tale metodologia si può imporre solo a persone fortemente navigate nell ambito dell ingegneria del software. D altro canto non si pretende che i documenti formali(diagrammi ecc...) siano costantemente aggiornati prima di procedere con la scrittura del codice. Scelta la metodologia di processo, si è continuato con la suddivisione dei ruoli. A seconda delle proprie propensioni ci si è presi uno dei ruoli suggeriti nelle specifiche di progetto, con l accordo di non fossilizzarsi sulle proprie mansioni ma coprirsi a vicenda per ottenere una visione globale del progetto. Si sono istituiti formalismi comuni per la scrittura dei diari, si sono decisi i comuni strumenti di sviluppo sia per quel che riguarda il software che per quanto riguarda la documentazione e i diagrammi. Il resto del lavoro svolto si evince dalle prossime sezioni. Il resto del documento è strutturato come segue: il capitolo 2 tratta il lavoro svolto per l analisi dei requisiti, il capitolo 3 analizza le stime di sforzo necessario per il completamento del lavoro, nel capitolo 4 vengono riportati i diagrammi richiesti dal progetto. Il capitolo 5 riguarda il piano di qualità 1 Agile Unified Process 2 Rational Unified Process 1

9 2 CAPITOLO 1. CONSIDERAZIONI INIZIALI che il progetto fornisce, nel 6 vi è una approfondita analisi degli strumenti utilizzati, nel 7 vi è riportata la relazione per la costruzione della base di dati a cui si appoggia il sistema software implementato. Il capitolo 8 contiene il manuale utente sviluppato per gli utilizzatori del sistema, il capitolo 9 contiene i diari di gruppo e quelli personali che riportano l attività giornaliera svolta dal gruppo per il completamento del progetto. Sono presenti 2 appendici: la prima riguarda la notazione usata nei diari, la seconda riguarda ulteriori diagrammi sviluppati per il progetto: blueprints e wireframes.

10 Capitolo 2 Requisiti 2.1 Modello dei Requisiti Nella seguente sezione vengono esposti i requisiti che si propongono al committente dopo l elaborazione del documento di specifiche consegnatoci. Essi rappresentano i servizi e le funzionalità che si garantiranno nell applicazione concordata. Con la presente sezione non si enunciano né i dettagli implementativi né si ha la pretesa di avanzare suggerimenti sul risultato finale del prodotto. Nella successiva, invece, è possibile osservare più nello specifico le aree di sviluppo e la categorizzazione di ciasun requisito. Attore L attore del sistema è colui che in prima persona trae profitto dalla corretta funzionalità del servizio. Nel nostro caso esso è impersonificato dalla figura dell utente. Con esso ci si riferisce ad un qualunque essere umano dotato di pc con connessione alla rete, che desidera acquistare libri. Non si fanno assunzioni sulla copertura economica di cui dispone l utente, poichè, come si potrà notare più avanti, è una componente esterna al sistema che andiamo a realizzare. 3

11 4 CAPITOLO 2. REQUISITI Elenco dei Requisiti È di seguito presentato l elenco dei requisiti dell applicazione suddivisi per categorie [25]. 1. Funzionali: 1 Memorizzare informazioni sui libri ; 2 Set di operazioni sui dati: 1 Ricerca per i principali metadati del libro; 3 Autenticazione dell utente: 1 Registrazione; 2 Login; 3 Logout; 4 Gestione del carrello: 1 Inserimento; 2 Eliminazione; 3 Acquisto; 2. Non Funzionali: 3. Vincoli: 1 Sistema accedibile tramite browser; 2 Accedibile 24/24 h 7/7 gg; 3 Il sistema deve fornire tempi di risposta ragionevoli (ordine dei sec); 4 Il database deve garantire le proprieta ACID 1 per le transizioni; 5 Dettagliato livello di documentazione 1 Utilizzo del linguaggio JAVA, in particolare tecnologia J2EE; 2 Utilizzo di JBoss; 3 Utilizzo della tecnologia EJB3.0; 4 Sfruttare le potenzialità offerte da un DBMS; 5 L applicazione deve essere schierata in un cluster di nodi in maniera omogenea. 1 Atomicità, Consistenza, Isolamento, Durabilità.

12 2.2. SPECIFICA DEI REQUISITI Specifica dei Requisiti In questa sezione vengono incapsulati i requisiti individuati in una struttura tabellare assodata [32]. Questa prassi introduce chiarezza in un ambito soggetto a possibili ambiguità. Nella seguente tabella si fanno riferimenti all architetura del sistema che saranno spiegati in seguito. 2 Tabella 2.1: Tabella di Specifica dei Requisiti. ID Funzionale Derivato Sul prodotto Priorià Scope / Non Funzionale / Imposto / sul processo 1.1 F I Prod Obbligatorio business tier, DBMS 1.2.* F I Prod Obbigatorio tutto il sistema F D Prod Obbligatorio tutto il sistema F I Prod Obbligatorio tutto il sistema F D Prod Obbligatorio tutto il sistema F D Prod Obbligatorio web tier F D Prod Obbligatorio web tier F I Prod Obbligatorio web tier, business tier 2.1 NF I Prod Obbligatorio web tier 2.2 NF D Prod Opzionale nulla 2.3 NF D Prod Desiderabile tutto il sistema 2.4 NF I Prod Obbligatorio business tier, DBMS 2.5 NF I Prod Obbligatorio nulla La priorità adottata nella tabella di specifica dei requisiti 2.1 segue il seguente ordine: Obbligatorio : livello di massima importanza; Desiderabile : requisito in grado di dare un valore aggiunto al sistema; Opzionale : requisito utile ma non di necessario. 2 Per ora basti sapere che la suddivione del sistema è: web tier, business tier, DBMS

13 6 CAPITOLO 2. REQUISITI Misurazione dei requisiti Dalla tabella 2.1 emerge chiaramente come la maggor parte dei requisiti siano imposti. Infatti lo scopo del presente progetto è quello di soddisfare il committente nella semplice misura delle feature che vengono richieste. Lo scopo che stà alla base delle motivazioni del presente progetto non trarrebbe alcun beneficio da una proliferazione di funzionalità. Il team ha quindi ritenuto opportuno non spingersi al di là di quelle che sono parse le reali necessità dell utente finale che utilizzerà il software. Durante la fase di elaborazione del documento di specifica del progetto e nella formulazione sia del modello che della presente specifica, è emersa l idea di non doversi scontrare con una mole particolarmente onerosa di lavoro. Non sono tuttavia assenti punti privi di difficoltà nello sviluppo e potenziali rischi (si veda per dettagli la sezione relativa alla gestione dei rischi).

14 Capitolo 3 Stime e Metriche 3.1 Stime con FP La stima attraverso i Function Point prevede la compilazione di una tabella [32] che raccoglie alcuni parametri sensibili per il progetto. Da una preventivazione di componenti interne e di appoggio per il sistema si può infatti avere una stima delle righe di codice da scrivere. L utilizzo di tecnologie quali EJB 3.0 però automatizza la generazione di gran parte di queste. In particolare una grossa mole di righe deriva dalla presenza di diverse query sql, che tramite l utilizzo di un IDE 1 come Eclipse possono essere ottenute automaticamente. La tecnica di stima preventiva attraverso Function Points pesati prevede la divisione del progetto in aree di dominio, ciascuna quantificata da parametri variabili che indicano le interazioni tra il sistema e l utente. 1 Integrated Development Environment: ambiente di sviluppo con grafica integrata per aiutare gli sviluppatori nella scrittura di codice. 7

15 8 CAPITOLO 3. STIME E METRICHE Tabella 3.1: Tabella riassuntiva dei Function Points Parametro Conteggio Fattore di peso Totale Semplice Medio Complesso EI EO EQ IFL EIF Totale 82 Totale pesato 86,1 Per ogni riga il totale si ottiene moltiplicando il valore di conteggio per il fattore di peso associato. Quest ultimo si individua nel seguente modo: se il parametro di conteggio è minore di semplice allora si utilizza quel valore, se compreso tra semplice e medio si utilizza il medio altrimenti quello complesso. Legenda della tabella 3.1: EI : External Input = input diretti dall utente verso il sistema. Nel nostro caso rientrano in questa area azioni come: autenticazione, ricerca, checkout e visualizzazione del carrello. EO : External Output = output che il sistema fornisce all utente. Vengono elaborati e quindi restituiti come risultati le seguenti schermate: ricerca, registrazione, login, checkout, errore della procedura appena effettuata. EQ : External Query = interrogazioni provenienti dall esterno del sistema che necessitano di una risposta immediata. Queste query si riassumono in: ricerca per metadati, login, checkout. IFL : Internal File Logic = numero di file logici interni. Identifica il numero di file nei quali conservare informazioni indispensabili alla computazione. Nel nostro caso ve n é presente uno solo che coincide con il database. EIF : External Interface File = l interfaccia esterna è raggruppata in un insieme di file logici: homepage, pagine di descrizione dei libri, risultati della ricerca, checkout, login, form per la registrazione. Alla somma totale dei parametri inseriti in tabella 3.1 occorre aggiungere un ulteriore valore di normalizzazione per ottenere quelli che si definiscono

16 3.1. STIME CON FP 9 gli Adjusted Function Point. Viene calcolato attraverso una serie di 14 domande che inquadrano le difficoltà introdotte per la realizzazione del sistema. Bisogna quindi assegnare a ciascuna un valore da 0 (non importante o non applicabile) a 5 (indispensabile) ed ottenerne la somma che andrà quindi a normalizzare il totale. 1. Il sistema ha bisogno di operazioni di backup e ripristino affidabili? [3] 2. È necessario impiegare comunicazioni specializzate per trasferire le informazioni da o verso l applicazione? [1] 3. Esistono funzioni di elaborazione distribuita? [2] 4. Le prestazioni rappresentano un fattore critico? [3] 5. Il sistema può funzionare in un ambiente operativo esistente, pesantemente utilizzato? [2] 6. Il sistema richiede un inserimento online dei dati? [3] 7. L inserimento online dei dati richiede che venga realizzata una transazione di input costituita da più schermi od operazioni? [2] 8. I file IFL vengono aggiornati online? [4] 9. Esistono input, output, file o richieste di natura complessa? [1] 10. L elaborazione interna è complessa? [1] 11. Il codice è progettato per essere riutilizzabile? [5] 12. Nel progetto sono compresi la conversione e l installazione? [4] 13. Il sistema è progettato per più installazioni in più organizzazioni? [4] 14. L applicazione è progettata per facilitare le modifiche e la facilità d uso da parte degli utenti? [5] Somma delle risposte alle domande: 40. Il passo successivo consiste quindi nell applicare i sisultati ottenuti alla formula sottostante. FP = conteggiototale (0, 65 + (0, 01 F i ) RISULTATO: 86,1 FP Se ne ottiene una stima in Function Points, valore utile per stimare il tempo necessario alla realizzazione del progetto ( si veda la sezione sucessiva 3.2).

17 10 CAPITOLO 3. STIME E METRICHE 3.2 Stima dello Sforzo Dai risultati ottenuti dalla sezione precedente 3.1 si deve ora analizzare la previsione del tempo necessario per la realizzazione del progetto. I rischi, evidenziati in seguito, non influiscono nel calcolo di questa stima che si assume valga nel caso ottimale. Si sono utilizzati due metodi per ottenere un valore in mesi-uomo che identificasse il tempo necessario al complemtamento del progetto. Il primo viene suggerito in [32]. Viene riportata la tabella indicante i valori ottenuti dal calcolo 3.2. Tabella 3.2: Tabella della stima con Adjusted FP LOC 2 x FP 63 Tot LOC stimate 5424,3 mesi/uomo stimati 1,79375 L utilizzo del linguaggio Java implica la necessità di far corrispondere 63 linee di codice (LOC o SLOC) ad un FP. Si utilizza come stima delle linee totali quella calcolata sulla media pesata dei FP. Da ciò si evince che avendo un team di quattro persone serviranno circa 50 giorni per il completamento del progetto contando che una persona produce 12 FP al mese. Il secondo metodo utilizzato è il COCOMOII [24], [6]. Si è sfruttato un tool online [18] in quanto il calcolo previsto con questa metodologia prevede la considerazione di diversi parametri. L automatizzazione del calcolo velocizza il raggiungimento del risultato.

18 3.2. STIMA DELLO SFORZO 11 Tabella 3.3: Tabella della stima attraverso COCOMO II. Input 5,200 Source Lines Of Code 0.7 Team Skills 1.04 Project Complexity Output 9.5 Person-Months 191 Person-Days 1,524 Person-Hours Questa metodologia di calcolo prevede l utilizzo del numero di righe ottenute dalla media non pesata dei FP. Inoltre si presuppone di avere un team molto capace seppur con poca esperienza riguardante le tecnologie specifiche. L ultima assunzione fatta riguarda la complessità del progetto che è stato valutato facile dal punto di vista implementativo in quanto la vera difficoltà risiede nella metodologia di sviluppo e nell utilizzo delle tecnologie assegnate. Anche da questa stima si evince che servono circa 50 giorni. Per quanto le stime indichino l impossibilità di consegna del progetto al primo appello si è deciso di procedere comunque per questa data. Come si evince dalla prossima sezione si è considerato pertanto il rischio di slittare alla data di consegna successiva. Questo rischio si è effettivamente verificato pertanto vengono forniti due diversi diagrammi Gantt rappresentanti la prima e seconda schedulazione del lavoro da svolgere. Per ogni diagramma di stima ne viene fornito uno che indica come sono realmente state svolte le attività.

19 12 CAPITOLO 3. STIME E METRICHE 3.3 Analisi dei Rischi Le riunioni del team di sviluppo hanno portato all identificazione di alcuni rischi. Come proposto in [32], i più probabili vengono riportati nella tabella 3.4.

20 3.4. RISULTATI DELLE METRICHE E COLLAUDI 13 Si è quindi deciso di affrontare solo i primi quattro per evitare suvraccarico di lavoro. Si sono abbattuti con successo i rischi per i primi 3 casi, mentre si è verificato il quarto rischio previsto e quindi la consegna del progetto è slittata. Tutto ciò era stato preventivato quindi si sono rieffettuate alcune fasi di progettazione per pianificare di conseguenza l utilizzo delle nostre risorse. Osservazioni Vale la pena spendere qualche parola con osservazioni su alcuni punti su cui il lettore si può essere interrogato: La stima attraverso altri metodi, in particolare Use Case non è stata contemplata in quanto priva di una letteratura consolidata e perchè fornisce stime dall abbondante upper bound. Una stima troppo approssimativa e che giunta producesse un eccessivo sforzo di quello ipotizzato idalmente da ciascun membro, avrebbe avuto il solo effetto di generare falsi allarmismi e pessimismo sul processo e i tempi previsti. La stima dei Function Points normalizzati è utilizzata anche dal famoso modello matematico COCOMO2.0. Come nota non del tutto positiva dobbiamo sottolineare il fatto che i membri del team non hanno una così larga esperienza da aver collezionato sufficienti dati sui progetti passati da risultare utili per la stima di quello attuale. 3.4 Risultati delle metriche e collaudi Nella seguente sezione sono esposti i risultati inerenti ai parametri di qualità del codice sorgente. Durante tutte le fasi dell implementazione si sono tenute in considerazione, oltre che alla correttezza ed il rispetto dei requisiti, anche un esaustivo elenco di metriche (elencate e spiegate nella relativa sezione con lo scopo di mantenere una buona qualità in termini implementativi. Questi sono mostrati in forma abbastanza schematica, per agevolarne la consultazione e possibilmente renderli più chiari al lettore. In tabella 3.5 vengono elencati i valori di ciascuna metrica suddivisi per package del progetto. Sono presentati alcuni diagrammi per mostrare in maniera più chiara i risultati ottenuti:

21 14 CAPITOLO 3. STIME E METRICHE Figura 3.1: Diagramma Gantt preventivo per la consegna al 22 maggio.

22 3.4. RISULTATI DELLE METRICHE E COLLAUDI 15 Figura 3.2: Diagramma Gantt effettivo per la consegna al 22 maggio.

23 16 CAPITOLO 3. STIME E METRICHE Figura 3.3: Diagramma Gantt preventivo per la consegna al 19 giugno.

24 3.4. RISULTATI DELLE METRICHE E COLLAUDI 17 Figura 3.4: Diagramma Gantt effetivo per la consegna al 19 giugno.

25 18 CAPITOLO 3. STIME E METRICHE Tabella 3.4: Tabella riassuntiva dei rischi riscontrati Incapacità AS 30% Critico Il personale si focalizza di utilizzo di nello studio della tecnologia. JBoss in modo Si intensifica lo sforzo corretto ed per la comprensione della efficace stessa, il team si focalizza nella ricerca di testi esempi e quant altro per risolvere i problemi inerenti al progetto. Fase di progettazione Inesperienza 20% Critico Si analizzano gli artefatti fallimentare mal realizzati per ogni fase progettuale, si correggono e reimplementano. Ogni artefatto viene convalidato dall intero team, attraverso un confronto prima di procedere Incapacità di utilizzo in maniera corretta di J2EE con l implementazione. Tecnologia 15% Critico Il team si focalizza nello studio della materia tralasciando temporaneamente le altre mansioni per cercare esempi e cose utili per sopperire alla mancanza di una preparazione adeguata sull argomento. Mancanza di Ambiente 10% Critico tempo per l implementazione delle risorse umane del sistema basilare e rilascio dell ultima Milestone Implementazione Inesperienza 6% Marginale errata di qualche operazione

26 3.4. RISULTATI DELLE METRICHE E COLLAUDI 19 Figura 3.5: Tabella riassuntiva per le metriche. Figura 3.6: Istogramma della mancanza di coesione.

27 20 CAPITOLO 3. STIME E METRICHE Figura 3.7: Figura 3.8:

28 3.4. RISULTATI DELLE METRICHE E COLLAUDI 21 Figura 3.9: Figura 3.10:

29 22 CAPITOLO 3. STIME E METRICHE Figura 3.11: Figura 3.12:

30 3.4. RISULTATI DELLE METRICHE E COLLAUDI 23 Figura 3.13: Figura 3.14:

31 24 CAPITOLO 3. STIME E METRICHE Figura 3.15: Figura 3.16:

32 Capitolo 4 Diagrammi UML Per sviluppare gli artefatti è stato usato un plugin di Eclipse(UML2.0 modeler) che fornisce anche il diagrama in formato XML. Tutto ciò per questioni di condivisione delle risorse, in quanto è stato usato un repository svn per condividere l accesso ai files. Per implementare i sequence diagram ci siamo serviti di Umbrello[19] in quanto il plugin adottato non supportava tale diagramma. Il processo di creazione dei diagrammi UML ha portato a completare prima quelli più ad alto livello, poi quelli che richiedevano più conoscenze implementative sulla tecnologia in uso. Sarà facile notare per il lettore che alcuni di questi, la quale capacità espressiva consente di scendere al dettaglio, rispecchiano invece la situazione ad un livello alto di astrazione. Questo è dovuto a due motivi in particolare. Primo è il fatto di costruire i diagrammi ancora in fase iniziale del lavoro. Secondo perchè adottando un processo agile e volendoci mantere fedeli a questo, si è preferito far sì che la fase di modellazione non si traducesse in una continua modifica degli artefatti anche durante l implementazione del codice. 4.1 Use Cases Si è trovato utile seguire la proposta del [34] che invita il lettore a sfruttare la potenzialità degli use case di porsi a diversi livelli d astrazione, per poter dialogare con il committente vedendo il sistema come black box ed allo stesso tempo con l intero staff dedicato all implementazione. 25

33 26 CAPITOLO 4. DIAGRAMMI UML Figura 4.1: Use case diagram ad alto livello. Sono quindi stati prodotti due tipi di use case diagrams: uno più ad alto livello pensato per il committente 4.1 ed uno più dettagliato per l uso interno del team 4.2. La creazione di quest ultimo è mossa inoltre dalla necessità di ridurre ipotetici dubbi e situazioni ambigue.

34 4.1. USE CASES 27 Figura 4.2: Use case diagram a più basso livello. utto ciò che riguarda il lato business, quindi entiy e session bean Sono inoltre stati modellati i casi specifici della ricerca di un libro e della registrazione di una nuova persona, dei quali se ne ripropongono i diagrammi rispettivamente in 4.3 e 4.4.

35 28 CAPITOLO 4. DIAGRAMMI UML Figura 4.3: Use case diagram per la Ricerca di un libro.

36 4.1. USE CASES 29 Figura 4.4: Use case diagram della registrazione di un nuovo utente.

37 30 CAPITOLO 4. DIAGRAMMI UML Non si vuole annoiare il lettore con inutili descrizioni a parole sui dettagli e puntualizzazioni su questi diagrammi. Di seguito esponiamo quindi le tabelle utilizzate dal team per la formalizzazione degli scenari (tecnica proposta da [34]). Esse sono sufficientemente dettagliate ed elencano oltre alla situazione di normalità anche quelle di errore o le possibili varianti. Allo stesso tempo sono veloci da consultare perchè è possibile estrapolarne solo le informazioni che si cercano.

38 4.1. USE CASES 31 Casi d uso: tabelle e scenari Ricerca Id UC-ri1 Caso d uso: RicercaLibro Versione Descrizione L utente può ricercare un libro in base a delle keywords inserite in appositi form di ricerca. Priorità Elevata Durata Nell ordine dei secondi Attore primario Utente Attori Secondari non presenti Precondizioni L Utente visualizza la pagina apposita fornita dal servizio Garanzie Minime: il sistema integra la pagina di errore all interno di un template standard; Successo: il sistema integra la pagina coi risultati all interno del template standard previamente inizializzato. Avvio L utente compila la form di ricerca e preme il pulsante search.

39 32 CAPITOLO 4. DIAGRAMMI UML Scenario Principale 1. Utente: compila i campi necessari per la sua ricerca e preme il pulsante search; 2. Sistema: riceve i dati appena immessi; 3. Sistema: interroga il database; 4. Sistema: crea la pagina con i risultati e la mostra; Scenario Di Errore Primo Scenario di errore 4.1 Sistema: la pagina creata non contiene i risultati desiderati in quanto non presenti, viene fornita una pagina standard Autenticazione Id UC-au1 Caso d uso: Autenticazione Versione Descrizione L Utente può autenticarsi presso il sistema oppure registrarvisi Priorità Elevata Durata Nell ordine dei secondi Attore primario Utente Attori Secondari Non previsti Precondizioni L Utente visualizza la relativa form nel caso di login o registrazione oppure il collegamento per il logout Garanzie Minime: Viene visualizzata una pagina di errore; Successo: il sistema esegue correttamente l azione specificata. Avvio L utente visualizza la pagina associata all azione desiderata.

40 4.1. USE CASES 33 Annotazioni Si vedano i casi d uso associati al Login, Logout e Registrazione. Registrazione Id UC-re1 Caso d uso: Registra Utente Versione Descrizione L Utente si registra al sistema. Priorità Elevata Durata Nell ordine dei minuti Attore primario Utente Attori Secondari non presenti Precondizioni L Utente visualizza la form di registrazione. Garanzie Minime: Il sistema rimane in una situazione coerente e viene mostrato un messaggio dell esito dell operazione; Successo: i dati dell Utente vengono correttamente inseriti nel sistema. Avvio L Utente accede alla pagina di registrazione.

41 34 CAPITOLO 4. DIAGRAMMI UML Scenario Principale 1. Utente: compila i campi con i propri dati e preme sul pulsante registra; 2. Sistema: riceve in input i dati e verifica che non siano già presenti sul database; 3. Sistema: aggiunge le relative informazioni al database; 4. Sistema: mostra una schermata di successo per confermare l avvenuta operazione. Scenario Di Errore Primo Scenario di Errore 2.1 Sistema: rileva la presenza degli stessi dati nelle tabelle; 2.2 Sistema: mostra un messaggio di errore; 2.3 Sistema: riprende l interazione dall avvio dello scenario. Login Id UC-lo1 Caso d uso: Login Versione Descrizione L Utente si autentica presso il sistema. Priorità Elevata Durata Nell ordine dei secondi Attore primario Utente Attori Secondari non presenti Precondizioni L Utente visualizza la form di login Garanzie Minime: viene visualizzato un messaggio di errore; Successo: l Utente è correttamente autenticato. Avvio L Utente accede alla sezione di autenticazione.

42 4.1. USE CASES 35 Scenario Principale 1. Utente: compila i campi username e password e preme il pulsante login; 2. Sistema: riceve i dati inseriti e li confronta con quelli presenti nel database; 3. Sistema: inizializza una sessione associata all utente; 4. Sistema: mostra l avvenuta autenticazione all utente. Scenario Di Errore 2.1 Sistema: visualizza un messaggio di errore dato dalla non presenza nel database dei dati immessi dall Utente; 2.2 Sistema: viene mostrata la pagina di registrazione per i nuovi utenti (vedasi caso d uso associato). Logout Id UC-lo2 Caso d uso: Logout Versione Descrizione L Utente esce dalla sessione aperta in fase di login. Priorità Elevata Durata Nell ordine dei secondi Attore primario Utente Attori Secondari non presenti Precondizioni L Utente ha già eseguito correttamente l autenticazione. Garanzie Minime: viene visualizzato un messaggio di errore; Successo: viene distrutta la sessione creata precedentemente dall Utente. Avvio L Utente, una volta autenticato, preme il pulsante di logout

43 36 CAPITOLO 4. DIAGRAMMI UML Scenario Principale 1. Utente: preme il pulsante di logout 2. Sistema: elimina tutte le informazioni temporanee prodotte dall interazione con l Utente fino a quel momento Gestione Carrello Id UC-cg1 Caso d uso: Gestione del carrello Versione Descrizione L Utente può aggiungere o rimuovere libri, inoltre può comprare l intero contenuto del carrello. Priorità Elevata Durata nell ordine dei secondi Attore primario Utente Attori Secondari non previsti Precondizioni L Utente ha effettuato login. Si veda il caso d uso associato per dettagli. Garanzie Minime: viene visualizzata una pagina di errore; Successo: a seconda dell azione selezionata viene cambiato lo stato della sessione associata all Utente e viene fornito feedback a quest ultimo dell azione avvenuta. Avvio L utente visualizza la pagina di gestione del carrello o una lista di libri.

44 4.1. USE CASES 37 Scenario Principale 1. Utente: visualizza la pagina per la gestione del carrello o una lista di libri; 2. Utente & Sistema: si faccia riferimento al caso specifico che si tratta. Scenario Alternativo 0.1 Utente: effettua una ricerca come specificato nel caso d uso ricerca libro e poi procede con un caso d uso che estende questo. Annotazioni 1. I casi d uso specifici Aggiungi libro, Acquista libro, Rimuovi libro, Visualizza carrello, sono dotati di una specifica precisa a parte. Vi sono scenari alternativi comuni che vengono riportati qui per ovvie ragioni. Aggiungi Libro Id US-al1 Caso d uso: Aggiunta libro al carrello Versione Descrizione L Utente aggiunge un libro da una lista al suo carrello. Priorità Elevata Durata nell ordine dei secondi. Attore primario Utente Attori Secondari non presenti Precondizioni L utente ha svolto una ricerca e si è autenticato presso il sistema. Garanzie Minime: viene fornita una pagina di errore; Successo: la sessione viene modificata in modo da tener conto della selezione effettuata. Avvio L Utente seleziona un libro e sceglie di aggiungerlo al suo carrello.

45 38 CAPITOLO 4. DIAGRAMMI UML Scenario Principale 1. Utente: inserisce la quantità desiderata del libro che vuole acquistare e preme il pulsante aggiungi; 2. Sistema: riceve i dati inseriti dall utente e modifica la sessione a lui associata di conseguenza; 3. Sistema: mostra feedback all Utente della modifica avvenuta alla sua sessione. Scenario Alternativo 1.1 L Utente non inserisce alcuna quantità, il sistema prenderà 1 come caso di default. 1. Si faccia riferimento allo scenario descritto nello use case gestione carrello. Scenario Di Errore 2.1 Sistema: visualizza un messaggio di errore dato dalla non presenza nel database della quantità immessa dall Utente; Rimuovi Libro

46 4.1. USE CASES 39 Id UC-rl1 Caso d uso: Rimozione libro Versione Descrizione L Utente decide di rimuovere il libro dal suo carrello. Priorità Elevato Durata Nell ordine dei secondi Attore primario Utente Attori Secondari non presenti Precondizioni L Utente si è autenticato al sistema e sta visualizzando la pagina relativa al suo carrello. Garanzie Avvio Scenario Principale Minime: non viene modificato la sessione associata all Utente; Successo: viene modificata la sessione associata all Utente. L Utente decide di rimuovere dei libri dal suo carrello. 1. Utente: preme il pulsante rimuovi o - associato ad un determinato libro presente nel suo carrello; 2. Sistema: riceve l input dell Utente e rimuove il libro selezionato dalla sessione; 3. Sistema: se la quantita di un certo libro raggiunge 0 elimina la sua traccia dalla sessione; 4. Sistema: fornisce feedback all Utente delle modifiche avvenute. Scenario Alternativo 1. Si faccia riferimento allo scenario descritto nello use case gestione carrello. Acquisto Libro

47 40 CAPITOLO 4. DIAGRAMMI UML Id UC-ac1 Caso d uso: Acquisto degli elementi presenti nel carrello. Versione Descrizione L Utente decide di acquistare uno o piu libri previamente aggiunti al carrello. Priorità Elevata Durata Nell ordine delle decine di secondi. Attore primario Utente Attori Secondari Sistema di pagamenti esterno. Precondizioni L utente ha aggiunto al carrello uno o piú dopo le relative ricerche e stá visualizzando la pagina di gestione del carrello. L Utente si è autenticato presso il sistema. Garanzie Minime: viene visualizzata una pagina di errore; Successo: il sistema viene modificato in modo da rimanere consistente con le informazioni ricevute. Avvio L Utente decide di fare checkout.

48 4.1. USE CASES 41 Scenario Principale 1. Utente: clicca il pulsante di checkout; 2. Sistema: riceve la richiesta dell Utente; 3. Sistema: in base ai dati di sessione agisce di conseguenza decrementando correttamente la quantita dei libri selezionati; 4. Sistema: cancella i dati associati alla sessione dell Utente e ne crea una nuova per lo stesso; 5. Sistema: visualizza la pagina di eseguita transizione all Utente. Scenario Alternativo 1. Si faccia riferimento allo scenario descritto nello use case gestione carrello. Scenario Di Errore Primo scenario di errore 2.1 Sistema: l Utente non ha abbastanza soldi per pagare i libri richiesti; 2.2 Sistema: viene fornita una pagina d errore con le indicazioni opportune. Secondo scenario di errore 2.1 Sistema: non sono presenti le quantita di libri richiesti; 2.2 Sistema: viene fornita una pagina d errore con le indicazioni opportune. Visualizza Carrello

49 42 CAPITOLO 4. DIAGRAMMI UML Id UC-vc1 Caso d uso: Visualizza carrello Versione Descrizione L Utente visualizza tutti gli oggetti presenti nel carrello. Priorità Elevata Durata Nell ordine dei secondi. Attore primario Utente Attori Secondari non presenti Precondizioni L Utente si è autenticato presso il sistema. Garanzie Minime: viene visualizzata una pagina con un carrello vuoto; Successo: viene visualizzata una pagina con le corrette informazioni memorizzate nella sessione associata all Utente. Avvio L Utente decide di visionare i suoi possibili acquisti. Scenario Principale 1. Utente: preme il pulsante Cart; 2. Sistema: riunisce le informazioni di sessione associate all Utente; 3. Sistema: visualizza la pagina con le informazione previamente raccolte. Scenario Alternativo 1. Si faccia riferimento allo scenario descritto nello use case gestione carrello.

50 4.2. ACTIVITY DIAGRAM Activity Diagram Attraverso l Activity Diagram si vuole dare una visione del flusso di interazione a partire dalla richiesta dell utente fino alla risposta elaborata dal sistema. Questo diagramma si colloca ad un livello di astrazione sufficientemente alto da poter modellare solo le macro-azioni. Da questo si possono intuire oltre al flusso principale che l utente intende seguire, anche alcune possibili aree di diramazione, per causa di un errore o per volontà dell utilizzatore. Tuttavia esso non è adatto a modellare nel dettaglio tali situazioni, ma si presta invece per rendere l idea di come è stata pensata la sequenza delle azioni in relazioni agli scopi dell utente.

51 44 CAPITOLO 4. DIAGRAMMI UML Figura 4.5: Activity diagram del flusso di business.

52 4.2. ACTIVITY DIAGRAM 45 Figura 4.6: Activity diagram della procedura di autenticazione.

53 46 CAPITOLO 4. DIAGRAMMI UML Il grande vantaggio di questi diagrammi risiede in particolare nella loro chiarezza. È facile intuire nel primo (4.5) come lo scopo dell utente sia quello dell acquisto. Si ipotizza quindi che, salvo alcuni casi nei quali l utente ha bene in mente che libro acquistare, per la stragrande maggioranza venga prima eseguita una ricerca. I risultati vengono quindi selezionati, aggiunti al carrello ed infine acquistati. Questa operazione viene identificata all interno del team con il termine: checkout (si veda il glossario per ulteriori chiarimenti). Nel secondo (4.6) è esplicitata la procedura di registrazione grazie alla quale l utente viene inserito nel database. Questo vincolo è necessario sia per l acquisto sia per il riconoscimento dello stesso durante una seconda visita del sito. Si noti come non sono definite le cause del fallimento delle azioni, per le quali si consiglia di osservare lo State Diagram o direttamente le tabelle degli Use case. 4.3 State Diagram Contrariamente al precedente in questo si distinguono le transazioni tra stati nella forma: trigger[guardia]/attività. Grazie a questa dettagliata notazione degli eventi è possibile modellare con maggior dettaglio i casi alternativi durante l interazione. L utilizzo che se n è fatto lo colloca, similmente al precedente, ad un livello alto, dove cioè gli stati corrispondono alle macro azioni che l utente può svolgere, o più propriamente gli scopi dell utente.

54 4.3. STATE DIAGRAM 47 Figura 4.7: State diagram.

55 48 CAPITOLO 4. DIAGRAMMI UML Non potendo scendere nei dettagli implementativi, e volendo mantenere un diagramma che risultasse flessibile, si sono tralasciate alcune transizioni giudicate ovvie, o meglio non esigenti di particolari definizioni. Ad esempio non viene mostrata la possibilità di eseguire una ricerca quando l utente si trova nella sezione del carrello. Tale possibilità viene ovviamente offerta all utilizzaziore, ma non si è voluto arricchire l immagine di contenuti superflui, che tendono a minarne la chiarezza. Da esso emerge piuttosto che la parte principale del sistema riguarda la gestione dei dati personali dell utente, e dei libri che desidera acquistare. Da questo quindi deriva la cruciale differenza di azioni consentite ad un utente autenticato (ha eseguito il login) da un altro che non lo è ancora. Purtroppo nonostante il tool adottato fosse eccellente per altre tipologie di diagrammi lo stesso non si può dire per questa. D altra parte un ampia ricerca ha fatto emergere il tool scelto per la propria semplicità e completezza. Si è infatti riscontrato che non esistono stumenti particolarmente espressivi e completi nel campo della modellazione avanzata che non richiedano una cospicua somma di denaro. 4.4 Deployment Diagram L obiettivo del Deployment Diagram è quello di visualizzare come sono distribuiti a livello fisico i moduli implementati. Questo diagramma è per buona parte suggerito dalla stessa architettura J2EE e dall utilizzo dell application server in un cluster distribuito.

56 4.4. DEPLOYMENT DIAGRAM 49 Figura 4.8: Deployment diagram

57 50 CAPITOLO 4. DIAGRAMMI UML Il server che funge che load balancer è nel nostro caso Apache mod jk. Il compito di questo è quello di indirizzare le richieste dell utente verso i nodi, che corrispondono a macchine fisiche. La nostra applicazione viene eseguita nell ambiente offerto dal web service, e su ciascuna macchina viene eseguita un istanza sia di JBoss, che di tutto il corredo di moduli ad essa necessari. Per meglio rendere questo concetto sono infatti evidenziati i componenti necessari, ovvero: servlet, session bean ed entity bean. Il database viene mantenuto in una macchina particolare, la quale collocazione è nota al load balancer, che dovà essere in grado di comunicarlo agli altri nodi perché possano effettuare le proprie interrogazioni. 4.5 Class Diagram In questa corposa sezione si consiglia il lettore di armarsi di tanta pazienza e un tazza di caffè. Qui presenteremo infatti i passaggi che hanno portato al class diagram finale. Questo processo non è stato poi così lineare e indolore come ci aspettavamo. In particolare si è dovuto soppesare attentamente l architettura del web tier attraverso discussioni sugli effetti che le scelte a questo livello avrebbero implicato. Il class diagram finale è composto dalle due figure 4.9 e 4.10, rappresentati rispettivamente il web tier ed il business tier. Come già accennato in altre sezione della presente relazione, l architettura suggerita per un applicazione enterprise prevede la suddivisone in quattro livelli di astrazione. Il primo, denominato Enterprise Information System (EIS), si colloca alla base degli altri e corrisponde al metodo di mantenimento delle informazioni in memoria di massa. Questo compito nel progetto è affidato al DBMS MySql (si veda il capitolo 7 per i dettagli) e non compare nei diagrammi di classe. Subito al livello superiore si collocano le entity e le session bean, che insieme formano il business tier. Le prime rappresentano una vera e propria tupla della base di dati tradotta in linguaggio Java, alla quale è quindi possibile associare metodi anche piuttosto elaborati. Le session bean vengono invece coinvolte nella gestione delle entity. A queste spetta il compito di fornire un interfaccia adeguata al soddisfacimento di richieste che coinvolgono il DB (come ad esempio ricerche elaborate di libri) ai livelli superiori. Spostandoci ancora più ad alto livello si arriva al web tier. Le specifiche enterprise lasciano particolare libertà a questo punto e consentono sia l implemetazione attraverso pagine JSP, sia con Servlet. La soluzione adottata

58 4.5. CLASS DIAGRAM 51 dal team si colloca in mezzo: le pagine JSP collaborano con le servlet per propagare ed elaborare la richiesta dell utente, e formattare la risposta in modo adeguato per la visualizzazione tramite web. L ultimo strato di questa struttura è occupato dall applicazione client. Un alternativa all utilizzo di un browser consiste nell implementare un applicazione in linguaggio Java che, oltre a fornire l interfaccia grafica, viene corredata di ulteriori moduli, per la gestione delle richieste ed elaborazione delle risposte dal lato client. Nel nostro caso, visto il requisito 2.1 del modello dei requisiti (cap 2.1), che prevede l accesso all applicazione tramite browser, si è scelta la prima strategia, pertanto quest ultimo livello non è contemplato nei diagrammi. Questo perchè, forti di esperienze passate, la scrittura di tecnologie macchinose e ad oggi ormai datate, come le Applet Java, aggiunge una notevole complessità al sistema e non garantisce nè prestazioni, nè tantomeno sicurezza in più rispetto all accesso da browser. Per non coinvolgere il lettore nella storia dei passi seguiti per arrivare al prodotto finale, esponiamo da subito lo schema definitivo, e lasciamo nella seccessiva sessione la descrizione e le motivazioni delle strategie analizzate, che hanno condotto il team al risultato giudicato migliore.

59 52 CAPITOLO 4. DIAGRAMMI UML Figura 4.9: Class diagram: Web Tier.

60 4.5. CLASS DIAGRAM 53 Il web tier descritto in figura 4.9 rispecchia lo schema architetturale Model Control View. Anche se di difficile interpretazione si può notare come le classi che generalizzazano PBSView corrispondano alla vista del sistema. Probabilmente si può apprezzare meglio osservando la figura 4.13 che rappresenta le classi raggruppate in package nella sezione successiva. L idea che è stata portata avanti fin dall inizio prevede l utilizzo di codice XML per la formattazione dei dati in uscita dalle session bean. In questo modo risulta più facile il controllo delle informazioni che si producono. Questo inoltre introduce un buon livello di flessibilità nella strutturazione della pagina di output, dove sarà possibile sfruttare lo stesso XML. Ciò implica però che ogni entity bean possieda una classe in grado di tradurne i metodi in codice XML: XMLBook, XMLUser e XMLCart. Sebbene si introduca un sensibile accoppiamento tra le entity ed i relativi traduttori, bisogna anche evidenziare come questa strategia amplii in modo ancora più espansivo le potenzialià. In questo modo infatti viene a crearsi una gerarchia di classi in grado di soddisfare qualunque esigenza di una visualizzazione complessa. Inoltre diventa estremamente facile aggiungere nuove visualizzazioni o personalizzarne di esistenti: semplicemente si aggiungono o si modificano le classi vista *View che sono responsabili di cosa visualizzare nella pagina. Per fare un esempio è possibile voler visualizzare, dopo una ricerca, una descrizione dettagliata dei libri dei quali si forniscono tutte le informazioni disponibili: titolo, isbn, autore, genere, trama, numero di pagine, prezzo... Gli stessi acquistano però una forma più leggibile e veloce se elencati nel carrello, dove se ne mostra solo: titolo, isbn e prezzo. La classe addetta alla visualizzazione del carrello raggrupperà e tradurrà i dati i maniera sicuramente diversa da quella addetta alla visualizzazione dopo una ricerca. L oggetto Model viene implementato dall intero business tier, che già dialoga con il livello superiore per mezzo delle session bean. Esso viene sia utilizzato dalle classi che implementano la vista ( traduttori in XML delle entity bean) sia richiamato dal controller. L ultimo tassello del meccanismo viene ricoperto dall insieme di servlet facenti parte del web tier. Il Control si occupa infatti di richiamare inizialmente le session bean perchè, tramite l iter già osservato, costruiscano i risultati. Quindi si deve preoccupare di invocare l opportuna vista per tradurre le informazioni in codice XML che verrà poi tradotto in pagina web. Senza voler entrare nei dettagli implementativi, basti sapere che, attraverso un do-

61 54 CAPITOLO 4. DIAGRAMMI UML Figura 4.10: Class diagram: Business Tier. cumento xslt 1, dal codice XML si produce una pagina html. Come si evince dai nomi, ciascuna servlet è impegnata nella risposta ad una particolare richiesta, che viene invocata da una pagina JSP mostrata all utente. Scendiamo ora nel dettaglio del business tier. La figura 4.10 mostra per l appunto le relazioni che intercorrono tra le entity Costumer, Book, Order e le relative session. È già stato accennato che le session bean si devono occupare di gestire le richieste per mezzo delle entity, infatti tra le due è presente una dipendenza di utilizzo. Significa cioè che in alcuni casi verrà restituita una entity dalla session, oppure verrà controllata e restituita una risposta in forma booleana. 1 Fogli di stile per trasformare un documento XML in HTML.

62 4.5. CLASS DIAGRAM 55 Altri diagrammi e strategie analizzate La complessità strutturale che il pattern architetturale MVC 2 introduce è ripagata dall elevato grado di espandibilità acquistato dal codice. Un altro vantaggio ottenuto è la modularità: è stato infatti possibile implemenatare e testare le parti in modo indipendente e poi adeguate per le comunicazioni reciproche, una volta accordati sulle interfacce. Seguendo quindi la stessa logica sarà possibile eseguire manutenzioni future modificando semplicemente la parte necessaria e testandola, a patto di mantenere inalterata la struttura adottata per le comunicazioni tra le componenti del MVC. Questo risultato è il frutto di discussioni e rielaborazioni di una strategia iniziale molto semplice, alla quale abbiamo applicato i metodi di individuazione e utilizzo di pattern. La prima versione del diagramma delle classi prevedeva l uso di due gestori: uno per i dati utente, l altro per la gestione del carrello. Una volta inoltrate dalla servlet le richieste questi provvedevano ad interrogare le session bean, quindi propagare la risposta di nuovo al lato web che era incaricato di costruire la pagina web di risposta. Questo è stato ideato come primo appriccio naive per avere chiara la struttura del problema, e poter addirittura avanzare l implementazione delle parti necessarie a prendere confidenza con la nuova tecnologia. Ci riferiamo in particolare alla comunicazione con l application server, per la quale gerarchia di classi le specifiche suggeriscono un pattern al quale ci siamo attenuti. Si tratta di accoppiare ciascuna entity alla relativa session bean che la gestisce (come visto a lezione e citato in [33] ). Il risulato viene mostrato nella figura In questo modo risulta facile intuire che tutto il problema della gestione viene condensato in due sole classi (omesse nell immagine) alle quali si affidano grosse responsabilità. Da qui scaturiscono nuove idee per ingegnerizzare il web tier per avvicinarci ad una soluzione più elegante ma soprattutto robusta e in grado di sostenere futture manutenzioni. L idea di utilizzare XML è parsa fin da subito vincente, sia per le sue capacità implicite di strutturare le informazioni, che per la flessibilità che introduce nella realizzazione di pagine web. Tuttavia abbiamo cercato allo stesso tempo di non spendere troppe energie sui numerosi dettagli formali che prevede. Per quanto riguarda lo schema delle classi un approccio più elaborato 2 MVC è abbreviazione per Model View Controller.