Politecnico di Milano

Transcript

1 1 Politecnico di Milano Facoltà di Ingegneria dell Informazione Progetto di Ingegneria del Software 2: SWIMv2 Prof.ssa Mirandola Raffaella A.A 2012/2013 SWIMv2: Small World hypotesis Machine v2 Realizzato dal gruppo: Francia e Mosca Mosca Fabio Matr Gounemond@gmail.com Francia Massimiliano Matr francia.massimiliano@gmail.com

2 2 Design Document Progetto SWIMv2

3 3 Indice Introduzione Panoramica del sistema Descrizione dell'architettura 3.1 Deployment Rete e connettività Prestazioni Configurazione hardare 3.2 Decomposizione in sottosistemi Gestione dei dati persistenti 4.1 Progeettazione concettuale 4.2 Progettazione logica Design 5.1 Modelli di navigazione 5.2 Diagrammi di analisi 5.3 Diagrammi di sequenza 5.4 Diagrammi di dettaglio

4 4 1. Introduzione Il seguente documento descrive le scelte di progettazione del sistema SWIMv2, i cui requisiti sono stati analizzati nel RASD. 2. Panoramica del sistema L'obiettivo del sistema SWIMv2 è quello di ottimizzare, velocizzando e semplificando, l'interazione tra eventuali datori di lavoro e lavoratori, nell'ambito della ricerca di personale con specifiche abilità. Questo sarà garantito servendosi di una soluzione informatica semplice e immediata, in modo che si possa facilmente accedere a tutte le sue funzionalità dal primo utilizzo. Grazie ad un meccanismo di autenticazione, i dati relativi ad ogni utente risulteranno protetti. 3. Descrizione dell'architettura L'architettura utilizzata segue l'impostazione suggerita dalla specifica J2EE in modo da dividere le parti del sistema relative alla memorizzazione dei dati, al livello di controllo, e al livello di presentazione.

5 5 3.1 Deployment Secondo le attuali esigenze dell'università, possiamo gestire il flusso dei dati e gli accessi inglobando Web Server, Application Server e DBMS su un'unica macchina (Server). Questa macchina dovrà garantire ottime prestazioni, soprattutto per quanto riguarda la persistenza dei dati.

6 6 Web Server, Application Server e DBMS possono essere installati su macchine diverse, in caso di aumenti futuri di accessi e di flusso dei dati. Il sistema sarà quindi estensibile ed adattabile con l'evoluzione dello scenario. Questa soluzione richiede una maggiore gestione per quanto riguarda la comunicazione fra le varie parti, ma risulta più robusta, più sicura e meno complessa da mantenere Rete e connettività Nel nostro contesto web-oriented, avremo bisogno di un server dedicato (con qualche servizio di hosting); è previsto quindi l'utilizzo della rete Internet per il trasferimento dei dati tra Server e Client. Il server dovrà disporre di banda larghissima, in quanto sarà il punto di carico di tutto il sistema.

7 Prestazioni Considerato il contesto di funzionamento, solo il server dovrà avere una buona potenza elaborativa, e una memorizzazione dei dati efficace. Le comunicazioni potranno essere trattate in maniera asincrona, sollevando ogni problema di sincronizzazione Configurazione Hardware La configurazione hardware minima per un'ottima fruizione delle risorse software è la seguente: Client: Pentium Celeron o AMD celeron 512 Mb di RAM Scheda video integrata con 128 MB di memoria HD 80 GB Scheda di rete o WiFi 10/100Mb Monitor Sistema Operativo: Microsoft Windows Xp home Service Pack 3 Java Virtual Machine Connessione internet ADSL Server: Processore Intel I7 o AMD 8 GB di RAM Scheda video integrata con 128 MB di memoria HD 10 TB+ (possibilmente con configurazione raid per la gestione backup) Scheda di rete ethernet 10GB + Monitor Sistema Operativo: Microsoft Windows Server / Linux RedHat Java Virtual Machine Jboss MySql JQuery

8 8 3.2 Decomposizione in Sottosistemi Sono stati individuati tre differenti sottosistemi, corrispondenti ai tre ruoli principali per l'accesso al sistema, un sottosistema Archivio, Login e Registrazione. Non consideriamo la parte software direttamente accessibile dall'utente, in quanto consisterà in un web browser. Di seguito i sottosistemi individuati: Utente: si occupa della gestione delle funzionalità dell'utente registrato, e alcune funzionalità relative alle amicizie e alle richieste Amministratore: si occupa della gestione delle funzionalità dell'amministratore, e alla gestione delle richieste di modifica delle competenze. Archivio dati: si occupa di gestire gli accessi al DBMS Login: si occupa dell'autenticazione degli utenti. Registrazione: si occupa della gestione della registrazione di un utente 4. Gestione dei Dati Persistenti Per la gestione dei dati persistenti è stata realizzata una base di dati relazionale protetta da password. 4.1 Progettazione concettuale La progettazione concettuale del database per il sistema SWIMv2 ha lo scopo di individuare e rappresentare in maniera naturale i dati di interesse dell applicazione. La descrizione dei dati e della base di dati relativa al sistema viene presentata concentrandosi sugli aspetti concettuale e logico: per quanto riguarda l'aspetto concettuale, si mostrano le entità principali che interagiscono nel sistema e si mostra lo schema ER della base di dati; per quanto riguarda la progettazione logica, vengono mostrati i passi di traduzione da schema concettuale a logico e si mostra anche la rappresentazione logica. Di seguito sono riportati i diagrammi EntitaRelazioni generati, e le relative descrizioni.

9 9 Entità: - Amministratore: rappresenta l'amministratore che interagisce col sistema; i suo attributi sono: Username, Password. Username rappresenta l'identificativo dell'entità. -Abilità: rappresenta una competenza selezionabile dagli utenti. I suoi attributi sono: Nome, che è anche l'identificativo dell'entità -Utente registrato: rappresenta l'utente registrato all'interno del sistema; i suoi attributi sono: Username, password, data nascita, nome, cognome, mail. Username rappresenta l'identificativo dell'entità. -Feedback: rappresenta i feedback che gli utenti registrati si daranno l'un l'altro in seguito a collaborazioni. I suoi attributi sono: Mittente, Destinatario, Data, Voto, Commento. Gli identificatori dell'entità sono Mittente, Destinatario, Data (con mittente e destinatario chiavi esterne riferite ad utente registrato). -Richiede aiuto: rappresenta la relazione tra due entità Utente registrato, legate da una richiesta di aiuto / collaborazione. I suoi attributi sono: descrizione, data, ora.

10 10 -Messaggio : rappresenta l'entità messaggio che due utenti registrati possono scambiarsi. I suoi attributi sono: Id, Mittente, Destinatario, Data, Ora, Testo. Id sarà l'attributo chiave per l'entità, mentre mittente e destinatario saranno riferimenti alla chiave di Utente Registrato. Associazioni: -Definisce: rappresenta il legame tra amministratore ed abilità. L'amministratore può definire varie abilità. -Richiede abilità: rappresenta il legame tra un utente registrato e le abilità; questo legame in particolare indica eventuali aggiunte di abilità al proprio profilo, che verranno poi approvate dall'amministratore. -Possiede: rappresenta il legame tra un utente registrato e le sue abilità; questo legame indica le abilità effettivamente possedute e già confermate. -Invia: rappresenta il legame tra utente registrato e messaggio -Commenta: rappresenta il legame tra utente registrato e il commento da lasciare ad un messaggio -Richiede aiuto: rappresenta il legame tra proessore e corso, mostrando quali corsi sostiene un professore. -Amicizia: rappresenta la relazione di amicizia tra due utenti registrati -Richiedi amicizia: rappresenta una relazione tra due utenti registrati, che vogliono raggiungere una relazione di amicizia. -Ottiene: rappresenta relazione tra due utenti ed un feedback 4.2 Progettazione logica La progettazione logica del database per il sistema SWIMv2 si prefigge l obiettivo di costituire la base di dati per l effettiva realizzazione dell applicazione, tenendo quindi conto, per quanto possibile, delle sue prestazioni, anche a costo di una ristrutturazione dello schema concettuale. Per ognuna delle parti in cui si è divisa la progettazione concettuale si è tenuto conto dei criteri di ristrutturazione dello schema Entità-Relazione (il partizionamento e accorpamento di entità e associazioni, e infine la scelta degli identificatori primari), e successivamente dei criteri per la traduzione verso il modello logico. (modificare il testo perchè è uguale a quello dell'esempio) Ricostruzione e traduzione da ER a logico: tutte le relazioni relative a richieste sono state trasformate in tabelle; inoltre la relazione commento è stata trasformata in tabella per tener conto della relazione tra i messaggi e per poter numerare progressivamente i messaggi, in modo da renderne l'analisi più semplice.

11 11 Schema logico descrittivo: UTENTE (ID, Nome, Cognome, Età, Password, Connesso) CAPACITA' (IDUtente, NomeAbilità) ABILITA' (Nome) AMICIZIA (IDCorrente, IDAmico) RICAMICIZIA (IDRichiedente, IDDestinatario) RICABILITA' (NomeAbilità, IDRichiedente) RICAIUTO (Richiedente, Destinatario, Data, Ora, Descrizione) AMMINISTRATORE (ID, password) FEEDBACK (Mittente, Destinatario, Data, Voto, Commento) MESSAGGIO(Id, Mittente, Destinatario, Data, Ora, Testo) COMMENTO(IdBase, IdCommento, Progressivo) NB: in commento base sta per messaggio di base su cui si fanno i commenti e progressivo è il numero che ordina i commenti.

12 12 5. Design 5.1 Modelli di navigazione Per illustrare i percorsi di navigazione dell'applicazione sono stati realizzati i seguenti modelli di navigazione (User experience) organizzati per gruppi di funzionalità relative ai tipi d'utente. Si utilizza una distizione cromatica per cui gli elementi <<screen> si differenziano dagli elementi <<input form>> e, in presenza di elenchi, dal dettaglio di questi ultimi. Amministratore:

13 13 Utente registrato:

14 14 Utente non registrato:

15 Diagrammi di analisi Di seguito mostriamo i diagrammi di anlisi che mettano in evidenza le tipologie dei singoli componenti (Boundary, Control, Entity), e le loro relazioni. Amministratore

16 16 Utente registrato

17 17 Utente non registrato Login e registrazione

18 Diagrammi di sequenza I diagrammi seguenti descrivono i casi d'uso alla luce del modello concettuale, spiegando come avvengono le interazioni tra le varie classi identificate nei diversi scenari.

19 19

20 20

21 21

22 22

23 23

24 Diagrammi di dettaglio Per un maggior dettaglio sono stati espansi i diagrammi, mettendo in evidenza i componenti dell'architettura J2EE utilizzata (Servlet, HTML, JSP, EJB entity e session). I boundary si trasformano in JSP e Servlet. I control assumono la forma di EJB session, mentre le entity diventano EJB entity.

25 25

26 26

27 27

28 28