abstract
Il progetto si basa sulla gestione in tempo reale di una rete di trasporto pubblico, quale può essere ad esempio una compagnia di treni, autobus o aerei. Nello specifico si vuole sviluppare un progetto secondo le casistiche e le necessità di una compagnia di autobus.
L'obiettivo del sistema è quello di aggiornare e monitorare, in tempo reale, la posizione, i ritardi, gli autisti e ed eventuali altri dati che l'azienda intende controllare di ogni singolo automezzo disponibile, offrendo i propri servizi agli amministratori dell'azienda, che sono così in grado di monitorare sia i propri dipendenti e mezzi, sia l'utilizzo delle proprie linee, avendo quindi un mezzo per monitorare ed eventualmente migliorare il servizio reso ai propri clienti.
In futuro si potrà espandere il progetto per gestire la clientela stessa(infatti il server è strutturato in modo da poter essere ampliato); essi avranno la possibilità in tempo reale di sapere la capienza e la posizione dei mezzi.
Il sistema dovrà prevedere 4 componenti principali:
- Il sistema centrale, che si appoggia su un database che immagazzina le informazioni, e un'apposito sistema che gestisce il flusso delle stesse fra i vari componenti esterni.
- Un componente per gli amministratori dell'azienda, che avrà il compito di prelevare informazioni utili, inserire e/o alterare le stesse, e fare tutte quelle procedure di controllo e mantenimento richieste ad un generico database.
- un sistema di localizzazione GPS, per poter individuare in tempo reale la posizione del mezzo(emulato da noi con un componente java) inviata periodicamente dal mezzo e in caso di necessità recuperata in maniera attiva dalla centrale.
- il componente dovrà periodicamente comunicare al server la sua posizione, aggiornando i dati nello stesso
In futuro si potrà migliorare il sistema aggiungendo :
- Un componente mobile per ogni singolo automezzo, che potrà prevedere un'interfaccia, dalla quale i dipendenti dell'azienda dovranno registrare il proprio turno sul mezzo stesso
- Un componente utilizzabile da un generico cliente, non registrato al sistema (al contrario degli altri due), che dia lo status in tempo reale della rete di trasporto in modo da conoscere l'esatta posizione di tutti i mezzi in circolazione.
| Termine | Descrizione |
|---|
| Server Centrale |
Elemento centrale del sistema (spesso utilizzato in maniera abbreviata con il nome di Server). Ha il compito di accedere alla struttura dati e di controllare le connessioni in ingresso e uscita. Ha il compito di gestire l'intero flusso di informazioni fra i componenti e il database. Ha inoltre il compito di tenere in memoria lo status di tutti i mezzi registrati come attivi |
| Operatore |
Un qualunque dipendente dell'azienda incaricato di accedere al pannello di controllo principale del Server. Ha il compito di impostare e monitorare il corretto funzionamento del Server, nonché di utilizzarlo per prelevare e modificare qualsiasi informazione dal database, passando dal componente pannello di controllo |
| Pannello di controllo |
Componente utilizzato dall'operatore, ha il massimo livello di privilegi sul server, utilizzato per impostazioni/mantenimento del server e database |
| Automezzo |
Mezzo registrato al sistema, ha il compito di aggiornare in tempo reale il suo status con il server, indicando informazioni sul suo stato (posizione) |
I casi d'uso sono già stati parzialmente citati all'interno del glossario, si possono ridurre in 4 macro-situazioni, effettuate da altrettanti tipi di utenza:
- Server
- Aggiornamento della lista dei mezzi attivi
- Richiesta in caso di necessità della posizione dei mezzi
- Operatore
- Modifica delle impostazioni del server
- Inserimento nuovo mezzo nel database
- Autobus
- Cambio di status da attivo a fermo
- Periodico aggiornamento della sua posizione al server
Un possibile futuro caso d'uso potrebbe anche essere:
- Utente
- Fotografia istantanea della situazione in tempo reale della rete di trasporti
- Controllo di informazioni di tipo statico (tabelle orari, percorsi ecc)
Il nostro sistema avrà dei requisiti non funzionali, tuttavia di fondamentale importanza per garantire la sua corretta funzionalità.
- Manutenibilità, dovrà quindi essere realizzato in modo da poter essere gestito e aggiornato in maniera corretta.
- Usabilità: il sistema dovrà essere semplice ed intuitivo.
- Affidabilità: il sistema dovrà essere in grado di funzionare correttamente per lunghe sessioni di lavoro e dovrà garantire il non smarrimento dei dati in caso di guasto o problema.
- Prestazioni: il sistema dovrà garantire idonei standard di prestazioni, per non rendere frustrante ed inconveniente l'utilizzo dello stesso durante la sua normale attività.
- Portabilità: dovrà essere possibile, in futuro, spostare uno la totalità dei componenti eterogenei del sistema su diversi ambienti in maniera non dolorosa e senza perdita di informazioni
Il sistema prevede lo sviluppo di vari componenti che avranno il compito di interagire fra loro stessi secondo un protocollo server-client, dove il server sarà l'unico componente che avrà accesso alle informazioni contenute nel dbms. Possiamo quindi, partendo dai casi d'uso e dagli scenari precedentemente definiti, iniziare la fase di progettazione logica del sistema e dei componenti stessi, tenendo sempre in considerazione i requisiti non funzionali delineati, per poter definire un iniziale piano di collaudo.Possiamo quindi, stabiliti i casi d'uso, iniziare a progettare il modello del dominio e l'architettura logica del nostro sistema, tramite grafici uml e svariate note, per poter poi passare alla fase di progettazione e collaudo. Pertanto in questa fase di progettazione ci baseremo più sulla modellazione del dominio dell'applicazione piuttosto che hai problemi veri e propri di programmazione.
Modellata l'architettura generale del sistema, essendo lo stesso distribuito, e modellato il modello del dominio, dovremo anche fare svariate decisioni riguardo al modo in cui i componenti comunicano fra loro per garantire consistenza ed efficacia dei dati scambiati fra di essi.
Si è sentita la necessità, in fase di progettazione, di dividere il server in 3 sotto-componenti da sviluppare singolarmente. Essi sono infatti i componenti del sistema che andranno ad ascoltare e servire le richieste di ogni singolo tipo di utenza che vorrà avere informazioni dal server e che potrà in un futuro essere implementata. Inoltre in questo modo si è reso semplice l'eventuale inserimento di un nuovo tipo di utenza (basterà infatti estendere l'interfaccia madre dando al nuovo componente una sua porta dove ascoltare). I componenti potranno inoltre così essere distribuiti a loro volta, potendo creare un server distribuito.Lo scompo del dbmsListener è quello di interagire con il db vero e proprio, garantendo consistenza dei dati, essendo l'unico a poter accedere e modificare i dati del db.IActiveBus è una struttura dati esistente per ogni mezzo della compagnia, il quale tiene memoria di tutti i dati di ogni singolo mezzo nel server. Questi dati non sono salvati all'interno del db, ma sono temporanei; in un futuro si potrà modificare il DB per memorizzare tali dati al fine di una futura elaborazione da parte della Società di Trasporti.Và inoltre annotato che gli autobus sono indicati univocamente all'interno dell'intero sistema tramite la loro targa.
Il componente che andrà sistemato all'interno dell'autobus ha il compito di aggiornare periodicamente la propria struttura dati interna nel server (IActiveBus) con la sua posizione e/o altri dati di interesse. Per questo si è deciso di creare un componente il cui compito è eseguire questa routine periodica di aggiornamento (qualora il mezzo sia attivo) e di richiedere quindi periodicamente la connessione al server. Il componente viene sbloccato dopo una procedura di login, il cui compito è semplicemente quello di controllare che alla guida ci sia un utente (in questo caso l'autista) effettivamente registrato al sistema.Alcuni dati (es IP Address del server o il timer che indica ogni quanto effettuare l'aggiornamento dei dati) può essere messo in un file config, nascondendolo quindi all'utenza, lasciando una classica schermata di login ad avvio dell'applicazione.
Il client è di semplice realizzazione, in quanto consiste nella semplice richiesta di dati al server, senza l'invio e/o la modifica degli stessi.I grafici sottostanti rappresentano le interazioni fra i vari componenti
Qui sopra è rappresentato l'avvio e l'ingresso nella ruotine di attesa di connessione de Buslistener del server. Sotto invece come un futuro ClientListener potrà essere realizzato. Entrambi consistono nel lancio dei componenti, in una procedura di avvio e nell'attesa di una connessione alla porta designata.
Il grafico rappresenta la connessione Client -> ClientListener, compresa un eventuale procedura d'avvio del client.
Procedura d'avvio del componente autobus
Come già detto il sistema è stato costruito in modo da poter aggiungere altri listener al server e grazie all'utilizzo di java rmi per la creazione dei componenti remoti la gestione dei dati distribuiti risulta di semplice lettura e riutilizzo.