Meet O Matic. Design Document. Autori: Matteo Maggioni Luca Mantovani. Matricola:

Transcript

1 Meet O Matic Design Document Autori: Matteo Maggioni Luca Mantovani Matricola:

2 Indice 1 Introduzione 4 2 Architettura 4 3 Definizione della base di dati Tabelle, campi e chiavi primarie Chiavi esterne Descrizione in Dettaglio delle Tabelle Design del software Interazione con l utente Diagramma di analisi dettagliata Diagrammi di sequenza Struttura dell applicazione Definizione Entity EJB Note conclusive 20 2

3 Elenco delle figure 1 Mappatura logica dell architettura Mappatura fisica dell architettura Progettazione concettuale della base di dati Progettazione logica della base di dati Diagramma UX Diagramma di analisi dettagliata - BCE Diagramma di sequenza, sottoscrizione gruppo Diagramma di sequenza, voto sondaggio Struttura applicazione Entity Enterprise JavaBeans

4 1 Introduzione Meet O Matic offre ai propri utenti un sistema democratico per raccogliere le opinioni di gruppi di persone. Il proposito dell applicazione è quello di risparmiare tempo in ciascuna delle fasi richieste per eseguire un comune processo decisionale, dalla creazione del sondaggio fino all ottenimento della risposta passando attraverso la diffusione puntuale dell informazione verso l utenza interessata. Il sistema, avvalendosi delle tecnologie Java e delle tecniche progettuali offerte da JEE, è capace di offrire da un lato sicurezza e protezione delle informazioni e dall altro immediatezza nell uso, ampia accessibilità e interoperabilità. 2 Architettura L architettura di Meet O Matic rispecchia la classica configurazione a tre livelli logici nei sistemi informativi, così strutturata: 1. livello di presentazione: l insieme delle modalità di interazione con l utente gestite da un Web Client (un browser) e dalle tecnologie informative offerte dal Web 2. livello di logica applicativa: Meet O Matic, come detto, è sviluppato in accordo ai paradigmi offerti dalle tecnologie Java per la generazione dinamica di pagine (Java Server Pages e Servlet) e l architettura JEE per lo svolgimento del flusso di controllo e di interazione con i dati 3. livello di accesso ai dati: il DBMS dedicato alla gestione dei dati contenuti in Meet O Matic e garante della loro persistenza. I tre livelli sopra descritti potranno essere distribuiti su altrettanti livelli fisici, come rappresentato in figura 1, andando così a costituire un sistema a tre Tier, in particolare nella configurazione Thin Client, dove il lato client, in questo caso costituito da un web browser, si occupa della sola funzione di presentazione e il lato server è suddiviso in due elaboratori distinti, i quali si occupano rispettivamente dell esecuzione della logica di business e dell accesso ai dati. Una prima analisi del sistema Meet O Matic aveva suggerito una più semplice architettura a due livelli fisici, così strutturata: 1. un web browser lato client, a cui è delegata la logica di presentazione 2. una singola macchina lato server nella quale sono fuse le logiche di applicazione e di accesso ai dati 4

5 Figura 1: Mappatura logica dell architettura Figura 2: Mappatura fisica dell architettura 5

6 Tuttavia, nonostante le non eccessive preteste computazionali dovute all esecuzione dei livelli logici (2) e (3) che avrebbero permesso la messa in pratica di una tale soluzione, viene suggerito un sistema a tre livelli per la maggiore flessibilità nella manutenzione, per la sua scalabilità nel caso di un (eventuale) aggiornamento e infine poiché in generale vengono offerte migliori prestazioni e migliore sicurezza agli utenti finali. 3 Definizione della base di dati Lo schema concettuale e lo schema logico del database hanno poche differenze, relative alla creazione di tabelle per gestire le relazioni molti a molti. Esistono in tutto 8 tabelle: 4 tabelle principali (User, Group, Agreement e Category) e 4 tabelle che smistano le relazioni molti a molti fra quelle principali (Invitation, Group User, Banned User, User Vote). Figura 3: Progettazione concettuale della base di dati 6

7 Figura 4: Progettazione logica della base di dati 7

8 3.1 Tabelle, campi e chiavi primarie Group (ID, Name, Creation Date, Description, Group Creator, Category) User (Username, Password, Name, Surname, Gender, Birthdate, State, City, Address, , Subscription Date, Last Expired Session) Category (Name, Description) Agreement (ID, Title, Group, Poll, Choice A, Choice B, Score A, Score B, Issuer, Start Date, End Date) Invitation (Group, User, Vip User) Group User (Group, User, Vip User) Banned User (Group, User) User Vote (User, Agreement, Vote Date) 3.2 Chiavi esterne Group.Category > Category.Name Group.Group Creator > User.Username Agreement.Group > Group.ID Invitation.Group > Group.ID Invitation.User > User.Username Group User.Group > Group.ID Group User.User > User.Username Banned User.Group > Group.ID Banned User.User > User.Username User Vote.User > User.Username User Vote.Agreement > Agreement.ID Agreement.Issuer > User.Username 8

9 3.3 Descrizione in Dettaglio delle Tabelle User Questa tabella contiene gli User registrati nel sistema. Ogni User ha uno Username, che è la sua chiave primaria, e una Password. La password qui memorizzata deve essere criptata. La tabella inoltre contiene le generalità dell utente (Name, Surname, Gender, Birthdate, State, City Address, E- mail). Vincoli: Username e Password non possono essere uguale a NULL. Subscription Date non può essere a NULL e non deve essere maggiore del timestamp attuale. Last Expired Session non può essere minore di Subscription Date e maggiore del timestamp attuale. Birth Date deve essere minore di Subscription Date. Se esiste una relazione Group Creator fra un User e un Group, deve esistere nella tabella Group User una tupla con foreign key a quel particolare User e a quel Group. Se esiste una relazione Group Creator fra un User e un Group, non deve esistere nella tabella Banned User una tupla con foreign key a quel particolare User e a quel Group. Cancellazione: in caso di cancellazione di una tupla di User, vengono cancellati anche tutti i Group in relazione di Group Creator con quella tupla e tutte le tuple di Invitation, Group User, Banned User e User Vote, in cui compare come foreign key lo chiave primaria della tupla. Group Questa tabella contiene i Group creati dagli User. Ogni Group ha come chiave primaria un ID univoco. Inoltre ha un Name, una Description e una Creation Date. Vincoli: Creation Date non può essere uguale a NULL, non deve essere maggiore del timestamp attuale e non deve essere minore della Subscription Date dello User con cui è in relazione tramite Group Creator. 9

10 Cancellazione: in caso di cancellazione di una tupla Group vengono cancellati tutti gli Agreement in relazione con quella tupla e tutte le tuple di Invitation, Group User e Banned User, in cui compare come foreign key lo chiave primaria della tupla. Agreement E la tabella che contiene la categoria alla quale appartiene un particolare Group. Il Name della categoria è la sua chiave primaria. Cancellazione: in caso di cancellazione di una tupla di Category, vengono messi uguali a NULL tutti i campi delle tuple di Group che erano in relazione con quella Category Invitation Questa tabella contiene gli Invitation correntemente attivi. E una tabella che gestisce relazioni molti a molti fra User e Group. Ha come chiavi primarie le foreign key verso User e Group. Ha inoltre un attributo booleano VIP User. Vincoli: Una coppia di foreign key che compare in questa tabella, non può apparire anche in Group User. VIP User non può essere uguale a NULL ed è di default FALSE. Cancellazione: in caso di cancellazione di una tupla non succede nulla di particolare. Group User Questa tabella contiene informazioni sugli User appartenenti ai Group. E una tabella che gestisce relazioni molti a molti fra User e Group. Ha come chiavi primarie le foreign key verso User e Group. Ha inoltre un attributo booleano VIP User. Vincoli: Una coppia di foreign key che appare qui, non può apparire pure in Invitation e Banned User. VIP User non può essere uguale a NULL ed è di default FALSE. Cancellazione: in caso di cancellazione di una tupla non succede nulla di particolare. 10

11 Banned User Questa tabella contiene informazioni sugli User bannati dai Group. E una tabella che gestisce relazioni molti a molti fra User e Group. Ha come chiavi primarie le foreign key verso User e Group. Vincoli: Una coppia di foreign key che appare qui, non può apparire pure in Group User. Cancellazione: in caso di cancellazione di una tupla non succede nulla di particolare. User Vote La tabella contiene informazioni su quali utenti hanno votato ad un particolare Agreement. E una tabella che gestisce una relazione molti a molti fra User e Agreement. Ha come chiavi primarie le foreign key verso User e Agreement. Ha inoltre un attributo di tipo timestamp Vote Date. Non è stato aggiunto un campo che indica la preferenza nel voto dello User per tutelare il rispetto della privacy. Vincoli: Vote Date non può essere uguale a NULL, e deve essere compreso fra Start Date ed End Date dell Agreement con cui è in relazione 1:1 Cancellazione: in caso di cancellazione di una tupla non succede nulla di particolare. 4 Design del software 4.1 Interazione con l utente Per meglio modellare i percorsi di navigazione che determinano il modo in cui gli utenti interagiscono con Meet O Matic, si usa il diagramma UX (User experience), tramite il quale è possibile definire quelle che saranno le caratteristiche del sistema dal punto di vista dell utente. Viene quindi rappresentata la superficie di Meet O Matic, ovvero l insieme di pagine consultabili e i dati in esse contenuti. 11

12 Figura 5: Diagramma UX 12

13 4.2 Diagramma di analisi dettagliata L obiettivo di questa fase di analisi è di isolare gli elementi di presentazione, di controllo e di interazione con i dati corrispondenti ai livelli logici descritti nella sezione 2. Per meglio modellare l insieme di classi e le relazioni che legano tali componenti viene usato il modello Boundary-Control-Entity. <<boundary>>: indica le interfacce esterne di Meet O Matic verso l utente, le classi marcate da questo stereotipo offrono metodi di navigazione e presentazione. In particolare il sistema offre tre interfacce principali: l insieme di funzionalità necessarie alla generica relazione utentesistema (autenticazione e registrazione, ricerca e gestione profilo personale) l insieme di funzionalità necessarie alla relazione utente-gruppo (creazione e sottoscrizione gruppo, gestione avanzata gruppo, ricerca gruppi e inviti) l insieme di funzionalità necessarie alla relazione utente-sondaggio (crea nuovo sondaggio, vota sondaggio, visualizza risultati, consulta notifiche) <<control>>: rappresenta una classe che realizza (interamente o in parte) la logica applicativa di Meet O Matic offerta agli utenti attraverso le interfacce boundary, utilizzando le risorse informative. Data la divisione funzionale delle classi boundary, anche le classi control seguono lo stesso principio divisionale che tende a separare le unità di controllo in base alle tre macro-funzionalità dell applicazione: (1) interazione con il sistema, (2) interazione con i gruppi, (3) interazione con i sondaggi <<entity>>: identifica una classe di accesso ai dati di interesse, le classi control di Meet O Matic sfruttano queste risorse per soddisfare le richieste effettuate dagli utenti attraverso le interfacce boundary. Nelle classi identificate da questo stereotipo sono definiti (1) attributi e (2) metodi, ovvero un sistema per interfacciare e manipolare i dati presenti nella base di dati. Come osservazione si noti che il concetto di entity è molto vicino a quello di Entity Enterprise JavaBean descritto in sezione

14 Figura 6: Diagramma di analisi dettagliata - BCE 14

15 4.3 Diagrammi di sequenza Per meglio mostrare il flusso di interazione tra le classi individuate si mostrano due diagrammi di sequenza significativi: Figura 7: Diagramma di sequenza, sottoscrizione gruppo 15

16 Figura 8: Diagramma di sequenza, voto sondaggio 16

17 4.4 Struttura dell applicazione La struttura dell applicazione è una classica struttura jsp? servlet? session EJB? entity EJB. Le pagine dell applicazione sono di tipo JSP (Java Server Page). Anche le pagine che non contengono contenuti dinamici sono JSP per coerenza con il resto dell applicazione. Le servlet, che hanno lo scopo di generare la relative pagine in un formato leggibile da un comune browser web, si interfacciano con i session EJB. I session EJB si occupano di far interagire servlet e database, richiamando gli opportuni metodi degli entity EJB. Non hanno stato e non sono persistenti. I session EJB sono di tre tipi, e si differenziano per il particolare dominio su cui agiscono. Ogni session EJB corrisponde grosso modo ad un Control del diagramma BCE. SystemManager si occupa di tutte le operazioni relative al sistema in generale e alla gestione degli User. GroupManager si occupa di ogni singolo aspetto relativo alla gestione dei Group e delle operazioni sui Group. AgreementManager gestisce gli Agreement e si occupa di tutti gli aspetti relativi alla votazione. 4.5 Definizione Entity EJB Gli entity EJB permettono di superare il divario che esiste fra la programmazione a oggetti dell ambiente Java e l architettura relazionale delle comuni basi di dati, e quindi rendono possibile lavorare sui dati contenuti nel database come se fossero normali oggetti di Java. Gli entity EJB sono persistenti e la loro sincronizzazione con le tabelle della base di dati viene gestita dal Java Container. Il mapping con il database avviene per mezzo di annotazioni. Il mapping degli entity EJB rispetta grosso modo la struttura del database presentata precedentemente. Group, User, Agreement e Category sono i bean che rappresentano le 4 tabelle principali. Banned User, essendo una tabella per lo smistamento di relazioni molti a molti, non ha un entity che la rispecchi. Esistono però 3 bean che rappresentano rispettivamente le tabelle Group User, Invitation e User Vote perché queste, anche se servono per gestire delle relazioni molti a molti, hanno degli attributi che non possono essere rappresentati da nessun altra parte. Tutte le relazioni fra gli entity EJB sono bidirezionali. 17

18 Figura 9: Struttura applicazione 18

19 Figura 10: Entity Enterprise JavaBeans 19

20 5 Note conclusive Il presente documento è stato realizzato per il corso di Ingegneria del Software 2 tenuto dalla Prof.ssa Di Nitto durante l AA 2007/2008 da: Matteo Maggioni (matteomaggioni@tiscali.it) Luca Mantovani (lukus2@msn.com) Per la sua realizzazione sono stati utilizzati i seguenti software: Java Diagrammi E-R (JDER) 1.3 per la modellazione della base di dati Visual Paradigm for UML 6.1 Community Edition per la modellazione UML L A TEX per la stesura del documento GIMP per l elaborazione delle immagini 20