SDD System design document

Транскрипт

1 UNIVERSITA DEGLI STUDI DI PALERMO FACOLTA DI INGEGNERIA CORSO DI LAUREA IN INGEGNERIA INFORMATICA TESINA DI INGEGNERIA DEL SOFTWARE Progetto DocS (Documents Sharing) SDD System design document Membri del gruppo: Calè Giuseppe Gemmellaro Claudio Lo Grasso Marco Minacori Attilio

2 INDICE 1 Introduzione Scopo del Sistema Obiettivi di progettazione 2 2 Architettura software attuale 3 3 Architettura software proposta Overview Decomposizione in sottosistemi Mapping hardware/software Gestione dei dati persistenti Controllo e sicurezza degli accessi Global Control Flow Boundary Conditions 6 1

3 1 Introduzione 1.1 Scopo del Sistema Il Progetto DocS è stato commissionato con le specifiche di permettere la classificazione automatica e la condivisione dei documenti all interno di un azienda. Il sistema progettato per l Azienda Ortolani@Unipa permette lo sviluppo di progetti di varia natura che ha come obbiettivo la realizzazione di documenti aziendali che verranno inseriti in un archivio a disposizione di tutti i dipendenti dell azienda. l sistema andrà a velocizzare le procedure di condivisione dei documenti in lavorazione dai vari gruppo di lavoro oltre a permettere la consultazione dei documenti relativi a progetti realizzati in passato. Questo per permettere l abbandono di un sistema di scambio e condivisione di documentazione avvenuta prevalentemente su supporto cartaceo. Ne segue che, il software dovrà essere rivolto agli impiegati dell azienda e ai gruppi di lavoro composti da questi ultimi; agli impiegati, quindi, sarà consentito di condividere e visualizzare i documenti prodotti all interno del proprio gruppo di lavoro e di accedere a tutti i documenti presenti in archivio. Secondo specifiche, il sistema dovrà permettere la ricerca dei documenti all interno dell archivio informatico, a tal fine il sistema provvederà a classificare i documenti per categorie in maniera automatica al momento del loro inserimento. 1.2 Obiettivi di progettazione Il sistema DocS è stato sviluppato per semplificare le procedure di condivisione e classificazione di documenti inseriti dai dipendenti dell azienda. Grazie ad interfacce intuitive e possibile interagire ed amministrare il sistema. Il sistema si appoggia ad un DBMS esterno, sfruttando al massimo le potenzialità di ottimizzazione per il recupero dei dati. La documentazione gestita dal sistema DocS è a carattere riservato e ad uso esclusivo dei dipendenti dell azienda, pertanto è stato scelto di adottare un sistema di autenticazione che controlla l accesso al sistema tramite l inserimento di nome utente e password assegnate dall amministratore ad ogni dipendete dell azienda. Il progetto è stato realizzato nel linguaggio di programmazione Java, con paradigma di programmazione ad oggetti. La scelta di questo linguaggio di programmazione è scaturita dalla necessità del cliente di potere utilizzare il sistema DocS in tutti gli elaboratori presenti o che si acquisteranno in seguito nell azienda. 2

4 2 Architettura software attuale Nella realizzazione del sistema i progettisti non si sono potuti avvalere della possibilità di confronto con altri software simili in quanto non presenti sul mercato. Ad oggi il mercato non presenta un sistema automatizzato di questo tipo, in quanto nella maggior parte delle realtà aziendali la classificazione e la condivisione di documenti avviene ancora nel più familiare e meno efficiente sistema cartaceo. 3 Architettura software proposta 3.1 Overview Il Sistema commissionato è un software distribuito costituito da un nucleo centrale, contenente l archivio di tutti i documenti rilasciati dai vari gruppi di lavoro a progetto concluso. Gli utenti interagiscono con il sistema centrale da diverse postazioni client. I client non hanno alcuna possibilità di interagire tra di loro pertanto, tutte le richiesta delle informazioni al database o dei documenti sia in archivio che in locale, dovranno sempre essere fatte al server centrale. Ne deriva che l architettura più idonea al progetto è di tipo Client-Server. Il sistema pur basandosi su un architettura Client-Server, permetterà la condivisione, all interno di uno stesso gruppo di lavoro, di documenti residenti su postazioni diverse. Quando un utente richiederà un documento presente su un altra postazione, la richiesta verrà inviata al server, il quale tramite un interazione con il DBMS risalirà alla postazione che ospita il documento richiesto, lo stesso verrà prelevato (in copia) dalla postazione e verrà inoltrato all utente che ne aveva fatto richiesta. Le tipologie di utenti si dividono in: amministratore, impiegato, Group Member e Group Leader. Il primo sarà l amministratore, che conduce le operazioni di gestione degli account e dei gruppi di lavoro; il secondo è l utente normale che può accedere solamente all archivio in quanto non appartenente a nessun gruppo, Group Member è l utente appartenente a un gruppo del quale potrà gestirne i documenti, infine c è il Group Leader che oltre alle funzionalità del GM, ha la possibilità di gestire il gruppo tramite inserimento ed eliminazione di membri del gruppo. 3.2 Decomposizione in sottosistemi I sottosistemi individuati all interno del sistema D o c s rispecchiano in linea di massima le grandi aree di funzionalità offerte dal sistema. Tali sottosistemi possono essere divisi in due livelli, il primo riguarda i sottosistemi presenti nel lato Client ed il secondo riguarda i sottosistemi presenti nel lato Server, entrambi comunicano tra di loro tramite il sottosistema ComunicazioneServer. Per quanto riguarda il sottosistema Client si sono individuati i seguenti sottosistemi: 1. InterfacciaUtente (che comprende anche le interfacce relative ai GM ed ai GL) che interagisce con i sottosistemi GestioneGruppi e GestioneDocumenti 2. InterfacciaAmministratore che interagisce con tutti i sottosistemi presenti nel sottosistema Client che sono: GestioneUtenti, GestioneDocumenti e GestioneGruppi. I sottosistemi del lato Client dialogheranno con i sottosistemi presenti nel lato Server che svolgeranno le operazioni più importanti ed onerose del sistema. 3

5 I sottosistemi individuati nel Server sono: 1. Autenticazione, che contiene le classi che si occuperanno di controllare i dati inseriti nel Client e di autenticare l utente informando il Client che tipo di interfaccia principale deve mostrare in base ai dati inseriti dall utente (le interfacce principali saranno diverse a seconda che l utente autenticato sia Admin, Utente, GM o GL). 2. ArchiviazioneERecuperoDocumenti, che si occuperà delle operazioni richieste dai Client riguardanti la gestione dei documenti. 3. ClassificaERicerca, che si occuperà di classificare i documenti al momento del loro inserimento da parte dei Client e che fornirà le funzionalità di ricerca richieste dai Client. 4. DBMSCtrl, che si occuperà di interfacciare le richieste effettuate dai vari sottosistemi, sia quelli presenti nel lato Client che quelli presenti nel lato Server, al sottosistema DATABASE. Il diagramma seguente illustra la suddivisione sopra descritta, mostrando le dipendenze tra i vari sottosistemi. 4

6 3.3 Mapping hardware/software La struttura hardware proposta e costituita da un server centrale e dalle postazioni utenti che possono essere costituite da computer portatili o fissi nei quali possono girare sistemi operativi diversi fra loro. Al server si collegano le postazioni client ed il database, il tipo di postazione del client è determinata in fase di autenticazione controllando nel database il tipo di utente che corrisponde allo UserName inserito in quel client. Le postazioni client dovranno effettuare richieste al server per eseguire le operazioni legate alle loro rispettive funzionalità. Sulle postazioni client dei Group Member, come già detto, risiederanno i documenti dei progetti in corso di lavorazione, nel server invece risiederanno tutti i documenti dell archivio inerenti i progetti completati. Il database conterrà sia i dati relativi agli account ed ai gruppi, sia i dati relativi ai documenti ed alla loro collocazione e classificazione all interno del sistema. Le postazioni client e il server saranno connesse tramite una rete che utilizzerà il protocollo TCP/IP. Di seguito è illustrato il diagramma di deployment con i componenti suddivisi per ogni nodo 5

7 3.4 Gestione dei dati persistenti Il sistema DocS si avvale dell uso di un database di tipo relazionale, al quale si interfaccia tramite un DBMS. Questa scelta è stata ponderata data la sicurezza offerta da un DBMS di ultima generazione, assieme ad una maggiore affidabilità e garanzia di coerenza e facilità di gestione, nonché dalla velocità di accesso e trasmissione dei dati. 3.5 Controllo e sicurezza degli accessi La sicurezza ed il controllo dei dati del database è garantita tramite l utilizzo di username e password per ogni singolo utente, che verranno richieste per ogni singolo accesso. Ogni tipo di utente, group member, group leader ed amministratore, avrà a disposizione diverse interfacce grafiche, in modo che ogni utente possa accedere solo alle rispettive funziolità che rientrano nella sua categoria di utenza. 3.6 Global Control Flow Per quanto riguarda il flusso di controllo esterno (fra sottosistemi), il server sarà sempre in funzione, in attesa di eventuali richieste di servizi da parte delle varie postazioni client; nel caso di più richieste contemporanee, il server utilizzerà la tecnica FIFO (First In First Out). 3.7 Boundary Conditions 1. Il server deve essere sempre accesso altrimenti i client non possono richiedere funzionalità quali l autenticazione e di conseguenza la condivisione dei documenti tra le postazioni dello stesso gruppo di lavoro, l accesso ai documenti presenti in archivio ed al servizio di classificazione automatica utilizzato anche per i documenti salvati in locale. 2. In presenza di una chiusura o malfunzionamento del client, il sistema funziona correttamente ma non può accedere alla documentazione presente in quest ultimo. 3. In caso di errata digitazione di username e/o password il sistema avverte l utente con un messaggio di errore e visualizza nuovamente la schermata di login, consentendo un nuovo inserimento dei dati. 6