Documento di SYSTEM DESIGN Progetto di un portale per una società di servizi dedicati al settore delle imprese edili

Transcript

1 Documento di SYSTEM DESIGN Progetto di un portale per una società di servizi dedicati al settore delle imprese edili GRUPPO 2 Indice analitico Introduzione...2. Obiettivi del sistema Obiettivi di design Criteri di performance Criteri di affidabilità Criteri di costi Criteri di mantenimento Criteri di End User Definizioni, acronimi e abbreviazioni Riferimenti Architettura software proposta Overview Decomposizione in sottosistemi Mappaggio su hardware e software Descrizione sulla componente Velocity Descrizione della componente JavaMail TM Descrizione della componente JDBC TM Trattamento dei dati persistenti Controlli di accesso e aspetti relativi alla sicurezza Flusso di controllo globale Condizioni limite Casi d uso per Startup Comportamento del sistema in condizioni eccezionali Servizi dei sottosistemi Tempo richiesto per il completamento di questa documentazione...3

2 Introduzione. Obiettivi del sistema L obiettivo del progetto è la realizzazione di un portale internet per la messa on line di un servizio di gare e di appalti relative al settore edile. Il servizio è diretto sia alle aziende che intendono pubblicare una gara di appalto per la realizzazione di un lavoro edile, sia alle imprese edili interessate alla consultazione delle gare..2 Obiettivi di design Il sistema proposto cerca di rispettare quasi tutti i criteri di design ed in particolare:.2. Criteri di performance Tempo di risposta: le risposte del sistema avverranno in tempo reale, o quasi, a seconda del livello di carico del WebServer. Throughput: il sistema non ha grossi vincoli per portare a compimento i task; l unica limitazione potrebbe essere dovuta al tipo di WebServer utilizzato o alle performance della piattaforma hardware dedicata al database. Memoria: il sistema, escludendo la memoria richiesta dal WebServer, necessita di poco spazio per esplicare le proprie funzionalità..2.2 Criteri di affidabilità Robustezza: dal lato client verranno effettuati diversi controlli per stabilire la validità dei dati immessi dall utente; in particolare, verranno utilizzati degli script utilizzando tecnologia JavaScript per i controlli. Nel caso l utente abbia disabilitato JavaScript nel suo browser, tali controlli verranno, comunque, effettuati lato server in modo da avere la certezza di trattare dati validi. Nonostante questo comporti un overhead e appesantisca leggermente il carico del sistema, ciò permette all utente di accorgersi subito di eventuali errori commessi. Oltre alla correttezza dei dati, i controlli verteranno anche sui diritti di accesso per effettuare richieste in aree del portale che richiedono l uso di credenziali. Attendibilità: il sistema rispetterà le specifiche fornite dal cliente, riscontrabili nel documento di analisi dei requisiti (RAD). Disponibilità: il sistema sarà attivo H giorni all anno. Tolleranza ai fault: sotto condizioni di errore (es. immissione di password errata, abbonamento scaduto, ecc.) il sistema notificherà all utente il tipo di errore, seguito da un consiglio su come proseguire. Sicurezza: il WebServer prevedrà un sistema di crittografia di tipo HTTPS e la rete su cui risiede sarà protetta da un firewall. Fidatezza: il sistema non arrecherà nessun danno alle normali attività umane, anche in presenza di errori e di fallimenti. Il Sistema è tutelato dalle leggi sul copyright, dalle leggi sui diritti d'autore e dalle disposizioni dei trattati internazionali. Verranno, altresì, rispettate le vigenti normative sulla tutela dei dati personali (legge n. 96/03)..2.3 Criteri di costi I costi sono orientativi e verranno valutati per ore/uomo. Costo di sviluppo del sistema iniziale: 50 h. Costo per il deployment e il training degli utenti: 20 h. Costi di manutenzione: data la semplicità e la portabilità della piattaforma Java, verranno effettuate continue migliorie e aggiornamenti, al fine di individuare possibili bug in fase di deployment. Il tutto viene stimato in 90 h. 2

3 Costo di amministrazione: trattandosi di un applicazione web dinamica ne consegue che i contenuti saranno in costante aggiornamento. I costi variano in base alla mole di informazioni da amministrare, ma comunque non inferiore a 70 h..2.4 Criteri di mantenimento La qualità della suddivisione dei sottosistemi, ottenuta usando uno stile simile a MVC e il meccanismo di ereditarietà di Java, concorre a garantire la semplicità e la rapidità nel modificare il sistema dopo il suo rilascio soprattutto per quanto riguarda l interfaccia utente. Altri criteri da tenere in considerazione sono elencati di seguito: Estendibilità: grazie alla portabilità ed estendibilità di Java, risulterà molto facile implementare nuove interfacce o estendere classi esistenti per aggiungere nuove funzionalità al sistema. E possibile, quindi, sfruttare il riuso per estendere le potenzialità del Sistema. Modificabilità: la modifica delle funzionalità del Sistema sarà molto semplice ed intuitiva, considerando la semplice modularizzazione offerta da Java e dalle Servlet. Adattabilità: il sistema sarà realizzato per uno specifico dominio di applicazione ed eventuali cambiamenti del dominio comporterebbero semplici modifiche del sistema. Portabilità: le tecnologie impiegate garantiscono una totale indipendenza, rendendo così possibile utilizzare la stessa applicazione web su qualsiasi piattaforma che supporta java (Windows, Unix, Solaris, Macintosh). Leggibilità: grazie ad una buona strutturazione del codice sorgente, all aiuto di opportuni commenti e a javadoc inseriti in sezioni rilevanti del programma, risulterà di facile comprensione la lettura dei sorgenti e/o la sua successiva modifica. Tracciabilità dei requisiti: data la modularità e l organizzazione generale del progetto sarà facile effettuare il mapping dei requisiti del cliente in specifiche sezioni di codice..2.5 Criteri di End User Utilità: dall analisi del problema e dalle specifiche richieste dal cliente, il sistema risponderà completamente ai bisogni del cliente. Usabilità: per rendere facile l utilizzo del sistema, oltre ad un training completo del personale, sarà previsto un help on-line che aiuterà l utente nelle sue interazioni con il sistema..3 Definizioni, acronimi e abbreviazioni - SMTP: Simple Mail Transfer Protocol - DBMS: Database Management System - JDBC: Java Database Connectivity - SQL: Structured Query Language - MVC: Model View Control - HTTPS: HyperText Transfer Protocol Secure (versione sicura del protocollo http) - HTML: HyperText Markup Language - LAN: local area network - JSP: Java Server Pages - RAD: documento di analisi dei requisiti - VTL: Velocity Template Language (linguaggio che usa la componente Velocity).4 Riferimenti Bernd Bruegge e Allen H. Dutoit - Object-Oriented Software Engineering (using UML, Patterns and Java TM ) Prentice Hall Jim Conallen - Building Web Applications with UML (Second Edition) - Addison Wesley Velocity Template Engine (progetto Jakarta su mysql database ( 3

4 JavaMail TM ( Slide del docente Carmine Gravino 2 Architettura software proposta 2. Overview L architettura del nostro sistema presenta uno stile simile ad MVC (Model View Control), che è ampiamente utilizzata per applicazioni di tipo web. Il sistema è composto da tre sottosistemi principali e fa uso di sette componenti esistenti. Il cliente interagirà con il sottomodulo ClientPages, il quale rappresenta l interfaccia utente del sistema. Tale sottomodulo interagirà con il sottomodulo ServerPages mediante la componente WebServer che assegnerà ogni richiesta dell utente ad un thread che andrà, infine, ad eseguire le funzionalità richieste. Il thread a questo punto entrerà nell esecuzione della specifica classe contenuta in ServerPages che, ove necessario, farà le opportune richieste al sottomodulo DomainModel il quale si occupa di gestire tutte le informazioni sul dominio di applicazioni del sistema, come interfacciamento con il database, gestione della posta elettronica e gestione degli accessi. Il sottosistema DomainModel potrà, quindi, utilizzare le componenti JDBC TM e JavaMail TM della Sun che permettono l interfacciamento con i servizi sottostanti di DBMS e SMTP. Dopo tutta la fase di creazione della risposta il sottosistema ServerPages invierà l output all utente utilizzando un motore di gestione di template contenuto nella componente Velocity (si veda progetto Apache-Jakarta). Per tutto quanto descritto sopra, tutto il flusso di informazioni avviene utilizzando un architettura three-tier con thin client che è in realtà un evoluzione di quella Client-Server. Presentazione Applicazione Rete Accesso ai dati Rete 2.2 Decomposizione in sottosistemi Tenendo presente l architettura di riferimento, i sottosistemi identificati sono i seguenti: DomainModel: si occupa di manipolare le informazioni di tutto il dominio dell applicazione. ServerPages: il sottosistema che si occupa di raccogliere e gestire le richieste dell utente. ClientPages: rappresenta l interfaccia utente del sistema. 4

5 ClientPages ServerPages DomainModel Per ogni sottosistema verranno identificati gli oggetti contenuti e le relazioni tra essi. Diagramma di classi dei sottosistemi ClientPages e ServerPages per quanto riguarda l interazione con gli attori Visitatore e Abbonato. LoginForm +<<input>> login : string +<<input>> password : string CatalogoImprese Certificazioni HomePage ListaGare Login Sicurezza Autenticazione ControlloGare «redirect» ControlloRicercaGare ControlloContatto ControlloDownload RicercaForm +<<input>> query : string Contatto ContattoForm +<<input>> nome : string +<<input>> cognome : string +<<input>> string +<<textarea>> richiesta : string Gara RisultatoRicercaGare Ricerca NotificaContatto Figura Class diagram della vista logica per i sottosistemi ClientPages e ServerPages relativamente all'interazione degli attori Visitatore e Abbonato 5

6 HomePage LoginAreaRiservata LoginForm +<<input>> login : string +<<input>> password : string Autenticazione AreaRiservata InserimentoGara ControlloInserisciGara ControlloModificaGara ControlloCancellaGara ListaGare GaraForm -<<input>> inserzionista : string -<<input>> categoria : string -<<input>> provincia : string -<<input>> importo : double -<<input>> data_inserimento : Date -<<input>> data_scadenza : Date -<<textarea>> descrizione : string ModificaGara NotificaInserimentoAvvenuto NotificaModificaAvvenuta NotificaCancellazione Figura 2 Class diagram della vista logica per i sottosistemi ClientPages e ServerPages relativamente all'interazione dell'attore Amministratore nei casi d'uso di aggiornamento gara. 6

7 HomePage LoginAreaRiservata LoginForm +<<input>> login : string +<<input>> password : string Autenticazione AreaRiservata InserimentoUtente ControlloInserisciUtente ControlloModificaUtente ControlloCancellaUtente ListaUtenti UtenteForm +<<input>> nome : string +<<input>> cognome : string +<<input>> data_di_nascita : Date +<<input>> login : string +<<input>> password : string +<<select>> livello +<<input>> scadenza : Date +<<select>> tipo_abbonamento +<<input>> credito : double NotificaInserimentoAvvenuto ModificaUtente NotificaModificaAvvenuta NotificaCancellazione Figura 3 Class diagram della vista logica per i sottosistemi ClientPages e ServerPages relativamente all'interazione dell'attore Amministratore nei casi d'uso di aggiornamento utente. 7

8 Gara ListaGare +iterator() : object +get() : Gara +add() +remove() * -id : int -inserzionista : string -categoria : string -provincia : string -importo : double -data_inserimento : Date -data_scadenza : Date -descrizione : string SqlConnector +doselect() : object +doinsert() : int +doupdate() : int +close() Mail +setsubject() +setrecipient() +setsender() +send() Utente ListaUtenti +iterator() : object +get() : Utente +add() +remove() * -id : int -nome : string -cognome : string -data_di_nascita : Date -login : string -password : string -livello : LivelloUtente -scadenza : Date -tipo_abbonamento -credito : double * Session +getattribute() +setattribute() TipoAbbonamento +IS : TipoAbbonamento +PS : TipoAbbonamento LivelloUtente +VISITATORE : LivelloUtente +ABBONATO : LivelloUtente +AMMINISTRATORE : LivelloUtente Figura 4 Class diagram per il sottosistema DomainModel 8

9 2.3 Mappaggio su hardware e software Come già accennato nei punti precedenti, l architettura, per quanto riguarda il flusso di informazioni, segue la divisione in three-tier, che scompone l intero sistema in tre livelli hardware interconnessi da rete. Il WebServer utilizzato è Apache Tomcat e sarà residente su una macchina UNIX. I sottosistemi ServerPages e DomainModel saranno direttamente dipendenti dalla componente WebServer mentre le componenti mysqlengine e SMTP sono residenti su differenti piattaforme UNIX e disponibili attraverso la rete, preferibilmente LAN (per efficienza). Il sottosistema ClientPages sarà posizionato lato client ed i suoi contenuti saranno visualizzati tramite la componente WebBrowser. Client WebBrowser * ClientPages Server WebServer ServerPages Velocity DomainModel JavaMail JDBC MailServer DMBS SMTP mysqlengine Figura 5 Deployment diagram 9

10 2.3. Descrizione della componente Velocity Velocity Template Engine è un motore di template basato su Java. Fa parte del progetto Jakarta della Apache Software Foundation ed ha lo scopo principale di facilitare la costruzione di siti secondo il modello MVC con estrema semplicità. Velocity permette di dividere in modo netto il design di una web page dalla logica di controllo (il codice in Java), rendendo il web site molto più mantenibile e facilmente modificabile. I programmatori hanno a disposizione delle API che estendono le Servlet standard, ma che offrono maggiore velocità e potenzialità. Essi preparano ed elaborano le informazioni da passare alla view (il sottosistema ClientPages) e quindi le visualizzano. I designers possono usufruire del Velocity Template Language (VTL), un linguaggio di scripting estremamente semplice e veloce. Grazie alla semplicità di questo linguaggio i file scritti in VTL (.vm) sono del tutto simili a delle semplici pagine in HTML, il che facilita molto il compito dei designer e consente l'utilizzo di tools di sviluppo grafico molto affermati come Macromedia Dreamweaver Descrizione della componente JavaMail TM JavaMail fornisce le API per aggiungere a Java le funzionalità di interazione con i sistemi di posta elettronica supportando quindi l invio di attraverso il protocollo SMTP Descrizione della componente JDBC TM JDBC è un API composta da un insieme di classi e interfacce scritte in Java che forniscono agli sviluppatori la possibilità di scrivere applicazioni robuste per interfacciarsi con i database usando esclusivamente tecnologia Java. Per usare le API di JDBC con un particolare DBMS occorre un driver basato su tecnologia JDBC che ha il compito di mediare tra JDBC e il database. Nel nostro progetto verrà usato il driver mysql Connector/J ( 2.4 Trattamento dei dati persistenti Vista la problematica degli accessi multipli è stato deciso di affidare la gestione dei dati persistenti ad un database relazionale ed in particolare al DBMS open-source mysql. Nel nostro sistema verrà usato il framework JDBC di java e il driver mysql Connector/J per l interfacciamento con il DBMS. Gli oggetti identificati di tipo persistente sono le entità Gara e Utente. Le informazioni di questi dati sono contenute negli attributi delle rispettive classi e saranno memorizzate in modo persistente quando occorre nel database. Le tabelle necessarie per memorizzare i dati persistenti ed i relativi attributi sono qui di seguito indicati: UTENTI: id (int), nome (string[64]), cognome (string[64]), data_di_nascita (date), login (string[6]), password (string[6]), livello (enum[,2,3]), scadenza (date), tipo_abbonamento (enum[is,ps]), credito (numeric[5,2]). GARE: id (int), inserzionista (string[64]), categoria (string[32]), provincia (string[32]), importo (numeric[5,2]), data_inserimento (date), data_scadenza (date), descrizione (longtext). 2.5 Controlli di accesso e aspetti relativi alla sicurezza Alla prima richiesta dell utente al sistema, viene creato un oggetto Sessione che mantiene le informazioni sui diritti di accesso. In particolare l oggetto Utente verrà associato alla Sessione per l intera durata dell interazione. Ad ogni richiesta successiva il sistema verificherà nell oggetto Utente contenuto nella Sessione le operazioni consentite. 0

11 Per cambiare il livello dell utente, che di default è Visitatore, è stata prevista una form di autenticazione dove è possibile specificare login e password. Il sistema prenderà i campi login e password e verificherà che nel database sia presente la tupla contenente la login e la password specificata. Nel caso non sia presente, il livello di utente rimarrà Visitatore e verrà visualizzato un messaggio di errore indirizzando l utente al form iniziale di autenticazione, altrimenti nella Sessione verranno inserite le informazioni sull utente. Se l autenticazione è andata a buon fine verranno inviati dei Cookie al WebBrowser contenenti la login e la password in formato crittografato. Nel caso in cui il WebBrowser non supporti o non abbia i Cookies abilitati sarà necessario effettuare l autenticazione dell utente ad ogni accesso successivo al sistema. Per i diversi livelli di utenza vedere il RAD. 2.6 Flusso di controllo globale L architettura del sistema, essendo basata su un WebServer, userà un meccanismo di controllo di flusso di tipo event-driven e successivamente di tipo threads. Il WebServer, infatti, rimane in attesa di una richiesta da parte di un browser web; la richiesta, non appena ricevuta, verrà assegnata ad un thread che, poi, inizializzerà il controllo di flusso del sistema all interno di una delle classi del sottosistema ServerPages. Poiché vengono usati dei thread e più utenti possono accedere ai servizi del portale contemporaneamente, è necessario che negli oggetti che effettueranno delle modifiche ai dati persistenti si valutino bene le condizioni di concorrenza e prese opportune precauzioni. 2.7 Condizioni limite Per ogni oggetto persistente ora verranno definite le fasi in cui vengono creati, distrutti e archiviati nel database. Utente: l oggetto utente viene creato dall Amministratore all ingresso del caso d uso InserimentoNuovoUtente e archiviato all uscita. La distruzione avviene nel caso d uso CancellaUtente. Gara: l oggetto gara viene creato dall Amministratore all ingresso del caso d uso InserimentoNuovaGara e archiviato all uscita. La distruzione avviene nel caso d uso CancellaGara. Per ogni componente ora definiremo i casi d uso più interessanti per quanto riguarda lo startup, lo shutdown e la configurazione Casi d uso per Startup Caso d uso StartWebServer Nome Use Case Partecipanti Flusso degli eventi Condizioni d ingresso StartWebServer Inizializzato dal sistemista.il Sistemista accede da remoto alla macchina che contiene il WebServer. 2.Il sistema autentica il sistemista e lo fa accedere alla shell dei comandi. 3.Il sistemista esegue lo script di avvio del WebServer. 4.Il sistema mostra la conferma. Il sistemista ha accesso al sistema.

12 Condizioni d uscita Il WebServer è stato avviato Caso d uso StartMySqlEngine Nome Use Case Partecipanti Flusso degli eventi Condizioni d ingresso Condizioni d uscita StartMySqlEngine Inizializzato dal sistemista. Il Sistemista accede da remoto alla macchina che contiene il server mysql. 2. Il sistema autentica il sistemista e lo fa accedere alla shell dei comandi. 3. Il sistemista esegue lo script di avvio del server mysql. 4. Il sistema mostra la conferma. Il sistemista ha accesso al sistema. Il server mysql è stato avviato. Per quanto riguarda la gestione dei casi eccezionali e il fallimento dei componenti ora verranno descritti alcuni casi ed i relativi comportamenti del sistema Comportamento del sistema in condizioni eccezionali WebServer disconnesso da rete o in crash Il WebBrowser del client visualizzerà un messaggio di errore che comunica l impossibilità di contattare il WebServer e tutti i servizi del sistema non saranno disponibili fino a quando il problema non sarà risolto DMBS disconnesso da rete o in crash Se il DMBS diventa irraggiungibile dalle componenti presenti nel Server, il sottosistema DomainModel lancia un eccezione che risale attraverso il sottosistema ServerPages, verso il componente WebServer e infine alle ClientPages sotto forma di pagina di errore. I servizi forniti dal portale saranno parzialmente disponibili: tutte le pagine dinamiche che richiedono la ricerca e l aggiornamento del DBMS genereranno un messaggio di errore MailServer irraggiungibile Se il MailServer diventa irraggiungibile dalle componenti presenti nel Server, il sottosistema DomainModel lancia un eccezione che risale attraverso il sottosistema ServerPages, verso il componente WebServer e infine alle ClientPages sotto forma di pagina di errore. Il servizio relativo al caso d uso ContattaResponsabileClientela non sarà disponibile e genererà un messaggio di errore. 3 Servizi dei sottosistemi Il sottosistema ClientPages offre all utente servizi di pura interazione uomo-macchina, ovvero click, submit etc. Il sottosistema ServerPages offre servizi solo al sottosistema ClientPages. Per realizzare questa interazione in realtà il client utilizza l interfaccia fornita dalla componente WebServer che è rappresentata principalmente dalle operazioni di GET e POST (protocollo HTTP). Il sottosistema ServerPages utilizza, inoltre, i servizi messi a disposizione dal sottosistema DomainModel che espone servizi quali query al database, trattamento dei dati persistenti, interfacciamento con JavaMail, gestione e controllo degli accessi. 2

13 4 Tempo richiesto per il completamento di questa documentazione Questa documentazione è stata redatta in circa una settimana e con un totale effettivo di ore lavorative in gruppo uguali circa a 30. Francesco Amelio 556/00699 Clemente Vitulano 556/00095 Edoardo Mari 556/00679 Barbara Cusati 087/00393 Fabio Discenza 556/ Valerio Donnarumma 556/ Biagio Cosenza 556/00703 Debora Galdi 557/00795 Jole Sabella 556/