SWIM v2 Design Document

Транскрипт

1 PROGETTO DI INGEGNERIA DEL SOFTWARE 2 SWIM v2 DD Design Document Matteo Danelli Daniel Cantoni 22 Dicembre

2 Indice Progettazione concettuale Modello ER Entità e relazioni nel dettaglio User Feedback Richiesta amicizia Richiesta Skill Messaggio Skill Admin Progettazione logica Modello logico UX Model UX relativi agli user Login, registrazione, logout Modifica dati utente, modifica personal skill, proponi skill Ricerca user, invio richiesta amicizia, messaggio, richiesta aiuto, feedback Visualizzazione amici Visualizza messaggio, visualizza richiesta aiuto, visualizza richiesta amicizia UX relativi ai guest Cerca utenti UX relativi all admin Modifica password, visualizza/accetta/rifiuta richieste ampliamento skill set Architettura del sistema Descrizione Pattern MVC MVC in JEE Package Diagram BCE Diagram Registrazione Login, cerca utenti, modifica dati personali e personal skill Visualizza amici, proponi skill, visualizza/rispondi a messaggi o richieste Invia messaggi e richieste ad un user Admin: modifica password, rispondi alle richieste di ampliamento skill set

3 Progettazione concettuale Per la gestione dei dati persistenti sarà usata una base di dati relazionale, di cui rappresentiamo il diagramma Entità-Relazione, utile per avere una visione concettuale del database che sarà implementato. Modello ER 3

4 Entità e relazioni nel dettaglio Di seguito vengono descritte le varie entità e le relazioni presenti nel modello, con lo scopo di mettere in evidenza quegli aspetti che nel modello possono essere ambigui, come i tipi di dato utilizzati per i vari attributi e la loro cardinalità. User E l entità fondamentale del sistema; come già specificato nel documento di analisi ogni suo attributo è modificabile in qualsiasi momento dall utente. Gli attributi che la compongono sono: 1. costituisce la chiave primaria della tabella; deve essere di tipo char. 2. Password: è la password di accesso al sistema; deve essere di tipo char e per ragioni di sicurezza deve essere codificata con un algoritmo di hashing, ad esempio MD5. 3. Nome: è il nome dell user; il campo è obbligatorio e deve essere di tipo char. 4. Cognome: è il cognome dell user; il campo è obbligatorio e deve essere di tipo char. 5. Provincia, sesso, data nascita: sono tutti attributi non obbligatori. L entità User è soggetta alle seguenti relazioni 1. Possiede: mette in relazione User con Skill; la cardinalità è molti a molti: un user può infatti possedere più skill, ed una skill a sua volta può essere associata a più user. In fase di progettazione logica per realizzare questo tipo di relazione sarà necessaria una tabella di appoggio. 2. Invia(Feedback): mette in relazione User con Feedback; la cardinalità è uno a molti: un User infatti può essere il mittente di più feedback, ma un feedback può avere sono un mittente. 3. Riceve(Feedback): mette in relazione User con feedback; la cardinalità è uno a molti. 4. Invia(Richiesta Amicizia): mette in relazione User con Richiesta Amicizia; la cardinalità è uno a molti: User sarà colui che ha richiesto l amicizia. 5. Riceve(Richiesta Amicizia): mette in relazione User con Richiesta Amicizia; la cardinalità è uno a molti: User sarà colui che ha ricevuto la richiesta d amicizia. 6. Amicizia: questa relazione serve per esprimere l amicizia tra due user distinti; la cardinalità è molti a molti, quindi in fase di progettazione logica servirà una tabella di appoggio. 7. Invia(Richiesta Skill): mette in relazione User con Richiesta Skill; cardinalità uno a molti. 8. Invia(Messaggio): mette in relazione User con Messaggio; cardinalità uno a molti: User è il mittente del messaggio. 9. Riceve(Messaggio): mette in relazione User con Messaggio; cardinalità uno a molti: User è il destinatario del messaggio. 4

5 Feedback Questa entità rappresenta i feedback che gli userpossono scambiarsi, è composto dai seguenti atributi: 1. Id: chiave primaria di tipo int, il suo valore è autoincrementale. 2. Numero Stelle: rappresenta il giudizio dell user; il suo valore deve essere maggiore o uguale a 0 e minore o uguale a 5. Tale campo è di tipo int ed è obbligatorio 3. Commento: campo non obbligatorio di tipo char. 4. Data: rappresenta la data e l ora in cui il feedback è stato inviato; tale attributo è obbligatorio. Richiesta Amicizia Questa entità serve per tenere traccia delle richieste di amicizia non ancora confermate tra 2 user. La chiave primaria è formata dalla coppia di user(mittente/destinatario) appartenenti alla richiesta. Richiesta Skill Tale entità serve per rappresentare le richieste di ampliamento dello skill set fatte da uno o più user all admin; gli attributi che la compongono sono: 1. Id: chiave primaria di tipo int; il suo valore è autoincrementale. 2. Richiesta: attributo di tipo char, obbligatorio, che rappresenta la skill proposta. 3. Letto: è un valore booleano che indica se la richiesta è gia stata letta. Messaggio L entità messaggio rappresenta i messaggi che ogni user può inviare; i messaggi possono essere richieste di aiuto o semplici messaggi di testo. E composta dai seguenti attributi: 1. Id: chiave primaria di tipo int, il suo valore è autoincrementale. 2. Testo: campo non obbligatorio che costituisce l oggetto del messaggio; è di tipo char. 3. Data: rappresenta la data e l ora in cui il messaggio è stato inviato; l attributo è obbligatorio. 4. Letto: è un valore booleano che rappresenta se il messaggio è stato letto o meno. I messaggio testuali sono i messaggi con contenuto generale che due user possono scambiarsi, indipendentemente dalla richiesta di aiuto. I messaggi di richiesta di aiuto sono relativi solo alla richiesta e quindi sono soggetti alla relazione compone che indica la skill per la quale il mittente chiede aiuto. La cardinalità della relazione compone è uno a molti. 5

6 Skill Tale entità contiene tutte le skill presenti nel sistema ed è formata dai seguenti attributi: 1. Id: chiave primaria di tipo int; il suo valore è autoincrementale. 2. Nome: Il nome dell abilità in questione; il suo tipo è char. Da notare che non possono esistere due skill con lo stesso nome. Admin L entita admin contiene le informazioni relative all amministratore di sistema. Gli attributi che la compongono sono: 1. costituisce la chiave primaria della tabella; deve essere di tipo char. 2. Password: di tipo char; valgono le stesse considerazioni fatte a riguardo della password di User. A tale entità non è associata nessuna relazione per l assunzione che l amministratore di sistema è unico. 6

7 Progettazione logica Modello Logico Rappresentiamo di seguito il modello logico della base di dati, derivabile direttamente dal modello ER indicato sopra. 7

8 UX Model L obiettivo dei seguenti grafici è modellare l esperienza dell utente, rappresentando i possibili percorsi di navigazione e di interazione con il sistema. Vengono di seguito documentati tutti i percorsi possibili effettuabili da un utente, raggruppandoli in modo da rendere gli stessi diagrammi più leggibili. UX Relativi agli User Login, Registrazione, Logout 8

9 Modifica dati utenti, Modifica personal skill, Proponi skill 9

10 Ricerca user, Invio richiesta amicizia, Invio messaggio, Invio richiesta aiuto, Invio Feedback 10

11 Nota: Nella <<Screen>> Profilo Utente sono presenti i metodi InviaFeedback() e InviaRichiestaAmicizia() che vengono resi disponibili a seconda della relazione d amicizia tra due user: Se gli utenti sono amici: deve essere presente InviaFeedback() ma non InviaRichiestaAmicizia() Se gli utenti non sono amici: deve essere presente InviaRichiestaAmicizia() ma non InviaFeedback() Visualizzazione amici 11

12 Visualizza messaggio, Visualizza richiesta aiuto, Visualizza richiesta amicizia 12

13 UX Relativi ai Guest Cerca Utenti 13

14 UX Relativi ad Admin Modifica Password, Visualizza/Accetta/Rifiuta richieste ampliamento skill set 14

15 Architettura del sistema Descrizione Il sistema SWIMv2 sarà sviluppato seguendo un paradigma web-oriented. L architettura utilizzata segue lo standard suggerito dalla piattaforma JEE, in modo da semplificare la gestione dell applicativo rendendolo al tempo stesso scalabile, sicuro e affidabile. La piattaforma JEE utilizza un modello multi tier che prevede la suddivisione del sistema in diversi moduli dedicati rispettivamente all interfaccia utente, alla logica di presentazione, alla logica di business, e alla gestione dei dati. Il tier dedicato all interfacciamento con l utente, detto anche client tier, rappresenta il browser web, utilizzato dagli utenti per interagire con il sistema. Il tier relativo alla logica di presentazione incapsula tutta la logica necessaria ai client, ovvero la logica jsp e le servlets. Le jsp sono utilizzate per generare dinamicamente dei contenuti da mostrare all utente mentre le servlets sono i componenti che gestiscono l interazione clientserver. Il tier dedicato alla logica di business contiene gli enterprise beans, ovvero i componenti necessari per gestire la logica del sistema. Esso include entity beans e session beans. Gli entity beans rappresentano i dati persistenti salvati sul database mentre i session beans sono legati alla singola sessione dell utente. L ultimo tier è dedicato alla gestione dei dati; contiene il database e tutte le istanze utilizzate dal sistema. L interazione tra il client tier e il presentation tier avviene tramite il protocollo http, utilizzato attualmente dai browser. La comunicazione tra il database e la logica invece utilizza la tecnologia jdbc. Nell architettura che verrà implementata il presentation tier e il business tier saranno uniti in un singolo container e posti sullo stesso nodo insieme al database. 15

16 Pattern MVC La scelta di adottare l architettura esposta sopra è stata dettata dal fatto di voler aderire al famoso pattern Model-View-Controller. Tale pattern architetturale consente infatti di separare in modo netto la rappresentazione dei dati dalla logica del sistema e dall interfaccia utente. JEE è un framework Java che ne facilita l utilizzo. Nel nostro caso la logica del sistema include sia il presentation tier che il business tier. Possiamo quindi distinguere le seguenti tre componenti: Controller: il componente che riconosce e interpreta le azioni dell utente sulla View invocando oppurtune operazioni sul Model. Model: è il cuore del sistema; contiene tutti i dati, rappresenta lo stato del sistema e le operazioni disponibili. View: è una rappresentazione grafica del modello. Include tutto il necessario per gestire l interazione con l utente. Il disaccoppiamento tra logica, dati e presentazione rispecchia i paradigmi di buona programmazione e consente anche una migliore manutenibilità del codice. 16

17 MVC in JEE Nell architettura scelta, JEE, tale pattern si traduce come segue: Considerando lo schema illustrato sopra vediamo come opera una web application: 1. Il browser invia una richiesta al server web del sistema. 2. Nel server web una servlet gestisce la richiesta prendendo i dati inviati dal browser. 3. La servlet interagisce poi con i javabeans richiamando opportuni metodi (che vanno solitamente ad agire sul database). 4. La servlet, una volta ottenuti i dati, fa una forward della richiesta alla jsp. 5. La jsp, ricevuti i dati, si preoccupa di generare la pagina da restituire al web browser. 17

18 Package Diagram Per una migliore gestione dell implementazione del sistema si adotta la seguente suddivisione: Il sistema è composto di due progetti diversi, chiamati rispettivamente Swimv2-Server e Swimv2-Client. Il primo è un progetto ejb e contiene tutta la logica e i riferimenti al database, il secondo invece è responsabile dell interazione con l utente tramite il web browser. Il progetto server è diviso in tre package: Entity, Test e Session. L entity contiene tutte le classi che si riferiscono ai dati e permettono l accesso al database. Il session invece contiene le classi che implementano la logica del sistema e tutte le azioni che l utente può effettuare. Il test è un contenitore di tutte le classi necessarie al testing del sistema. Il progetto client contiene, all interno delle java resources, un package Servlet che contiene tutte le classi java necessarie alla generazione delle pagine dinamiche (servlet). Nel client, all interno della cartella Web Content sono presenti due sottocartelle, User e Admin, che contengono i file html visulizzati staticamente dal client e i file jsp che generano le pagine dinamiche nel browser. 18

19 BCE Diagram L obiettivo dei seguenti grafici è mostrare come vengono mappati i componenti del pattern MVC nel nostro sistema. Anche se i diagrammi hanno valenza generale è possibile trovare una correlazione con gli elementi strutturali offerti da JEE: I <<Boundary>> corrispondono alle pagine.jsp e alle servlet. I <<Control>> rappresentano i session beans. Le <<Entity>> sono i vari entity beans. Registrazione 19

20 Login, cerca utenti, Modifica dati personali e personalskill 20

21 Visualizza Amici, Proponi skill, Visualizza/rispondi a messaggi e richieste 21

22 Invia Messaggi e richieste ad un User 22

23 Admin: Modifica password, visualizza/rispondi alle richieste di ampliamento skillset 23