Specifiche del progetto di LabSO 2009
Versione 1.0, aggiornato il 29/3/2009
Funzionalità del programma
Si deve implementare un sistema di prenotazione delle aule del dipartimento di informatica. Tale sistema è composto da un server e un semplice client.
Il server
Il server deve leggere un file di configurazione che descrive le aulee di cui è composto il dipartimento. Tale file di configurazione è un file testuale di record, separati da due \n (new line) con i seguenti campi separati da un \n:
Aula: <nome>
Capienza: <numero>
Orario-inizio: <numero>:<numero>
Orario-fine: <numero>:<numero>
Ad esempio il seguente file di configurazione definisce due aulee, la rossa e la blu, da 30 e 35 posti. L'aula rossa apre alle 9:00 e chiude alle 17:00, mentre l'aula blu apre alle 12:30 e chiude alle 20:00.
Aula: rossa
Capienza: 30
Orario-inizio: 09:00
Orario-fine: 17:00
Aula: blu
Capienza: 35
Orario-inizio: 12:30
Orario-fine: 20:00
Il server legge il file di configurazione una sola volta, quando viene lanciato. Il server è un programma concorrente, e deve accettare richieste simultanee dai client aderenti al protocollo che viene spiegato in seguito. Al termine di ogni richiesta deve essere generato un file HTML che mostra lo stato di prenotazione delle aulee (una sorta di calendario con i giorni e le ore in cui le aulee sono occupate).
Il server prende tre argomenti a linea di comando, la porta su cui mettersi in ascolto, il nomde del file di configurazione e il nome del file html da generare. Esempio:
server 3000 aule.txt calendario.html
Il client
Il client è un semplice programma a linea di comando i cui argomenti sono indirizzo e porta identificanti il processo server, il nome di chi effettua la prenotazione, il nome di un'aula, una data, un ora di inizio e un ora di fine. Esempio:
prenota server:porta Tassi blu 12/01/2009 10:00 12:00
Il client deve informare l'utente della avvenuta prenotazione o della
impossibilità di prenotare. Nel primo caso deve stampare semplicemente OK,
mentre nel secondo caso deve stampare uno dei seguenti messaggi di errore:
Problemi di rete, in caso non si riesca a contattare il server oppure la connessione cada prima del completamento della prenotazioneAula non esistente, in caso sia stata specificata un'aula non esistenteOrario non disponibile, in caso l'intervallo di tempo richiesto non sia disponibile, sia in caso l'aula sia chiusa in tale orario, sia in caso che sia già stata prenotata per tale orarioGiornata completamente prenotata, raffinamento del messaggio precedente nel caso in cui l'aula sia già prenotata dall'ora di apertura a quella di chiusura, anche da persone differenti
Il protocollo
Il protocollo prevede lo scambio ordinato dei seguenti messaggi.
Hello\nviene mandato dal server al client non appena si instaura la connessione. Il client deve attendere tale messaggio prima di inviare qualsiasi messaggio al server.Hello <user>\nviene mandato dal client come primo messaggio. Con tale messaggio il client si identifica. Il nome dell'utente specificato dal messaggio dovrà essere parte delle prenotazione (chi ha prenotato l'aula).Welcome\nviene mandato dal server in risposta al messaggioHello <user>.RequestForAula <aula>\nviene mandato dal client per informare il server a quale aula sia interessato.RequestAccepted\nviene inviato dal server per informare il client che l'ultima richiesta è stata accettata.RequestForDate <date>\nviene mandato dal client per informare il server della data in cui desidera prenotare l'aula specificata in preedenza.RequestAccepted\nviene inviato dal server per informare il client che l'ultima richiesta è stata accettata.RequestForTime <time1> <time2>\nviene mandato dal client per informare il server che desidera prenotare l'aula da<time1>a<time2>.RequestAccepted\nviene inviato dal server per informare il client che l'ultima richiesta è stata accettata.
Formato ora
Le ore sono specificate usanto 5 caratteri, 2 cifre per le ore seguite da :
e altre 2 cifre per i minuti. Esempio 09:45.
Formato data
Le date sono specificate usando 10 caratteri, 2 cifre per il giorno seguite da
/ e da 2 cifre per il mese seguite da / e da 4 cifre per l'anno. Esempio
01/06/2004.
Esempio di scambio messaggi
Il prefisso S: contraddistingue i messaggi inviati dal server, mentre il prefisso C: contraddistingue i messaggi inviati dal client:
S: Hello
C: Hello Tassi
S: Welcome
C: RequestForAula blu
S: RequestAccepted
C: RequestForDate 12/01/2009
S: RequestAccepted
C: RequestForTime 10:00 12:00
S: RequestAccepted
Messaggi di errore
I messaggi 5, 7 e 9 posso essere sostituiti dal server dal seguente messaggio
RequestNotAccepted\nviene mandato dal server al client per comunicare uno sei seguenti problemi:- aula sconosciuta
- giornata al completo
- orario non disponibile
In caso il messaggio del client sia malformato
MalformedRequest\nviene mandato dal server per informare il client che l'ultimo messaggio del client non era ben formato.
In ogni caso, subito dopo aver mandato il messaggio di errore il server deve chiudere la connessione.
Esempio di scambio messaggi con errore
Un altro esempio, in cui il client richiede la prenotazione di un'aula non esistente
S: Hello
C: Hello Tassi
S: Welcome
C: RequestForAula violetta
S: RequestNotAccepted
Esempio in cui il client manda al server un messaggio malformato
S: Hello
C: Hello tassi
S: Welcome
C: RequestForAula rossa
S: RequestAccepted
C: RequestForDate domani
S: MalformedRequest
File di output
Al termine di ogni richiesta deve essere aggiornato il file HTML di output. Tale file deve essere interpretato da un essere umano una volta che viene reso dal browser, quindi non vi è un formato rigido come per i messaggi scambiati tra client e server. I requisiti minimi per tale file sono i seguenti: deve essere un semplice elenco delle giornate (ordinato cronologicamente); per ogni giorno vi deve essere un elenco delle aule (nome e capienza); per ogni aula vi deve essere un elenco delle prenotazioni (con orario e utente che detiene la prenotazione). Ad esempio:
- 15/02/2009
- aula rossa (30 posti)
- 09:00 - 11:00 tassi
- aula blu (35 posti)
- 13:00 - 15:00 tassi
- aula rossa (30 posti)
- 18/02/2009
- aula rossa (30 posti)
- 09:00 - 10:30 tassi
- 11:00 - 12:00 sangiorgi
- aula blu (35 posti)
- aula rossa (30 posti)
Gruppi di lavoro
I gruppi dovranno essere composti da al più quattro persone, al minimo due. Tali gruppi devono essere formati entro il 30 Aprile iscrivendosi al sito
http://esami.int.nws.cs.unibo.it/cgi-bin/Main.php
Modalità di consegna
Si devono consegnare due file:
- un archivio in formato tar.gz. oppure .zip
- un file di testo semplice o html
L'archivio deve contenere tutti i sorgenti del progetto e un file README che specifichi passo per passo come, a partire dall'archivio, si possano eseguire tutte le operazioni necessarie per compilare e eseguire sia il server che il client. Inoltre è necessario che tale archivio contenga un file AUTHORS con i nomi e le matricole degli studenti che hanno lavorato al progetto.
Il file di documentazione deve essere una relazione del lavoro svolto di al massimo una decina di pagine. Devono essere descritte le scelte implementative che sono state fatte, le strutture dati utilizzate, e eventualmente problemi incontrati che non si è riusciti a risolvere.
Le consegne che non soddisferanno tali requisiti (es. README o AUTHORS mancanti, relazione mancante non saranno valutati in nessun modo.
Il sorgente
Il codice sorgente che viene consegnato deve essere commentato in modo ragionevole: è inutile commentare ogni riga, ma è utile commentare i pezzi di codice che implementano una operazione di senso compiuto (es. una funzione che controlla la disponibilità dell'aula) e le guardie a cicli o parti condizionali del codice (es. ripete l'operazione su tutte le aule ancora disponibili; controlla che l'aula esista).
È inutile commentare ogni riga, ad esempio
il commento incrementa la variabile i relativo al codice i=i+1;
non aiuta per niente nella lettura del codice.
L'email di consegna
La consegna deve essere effettuata in modalità elettronica, mandando una email
con subject consegna progetto SO <nomegruppo> e in allegati l'archivio e il
file con la relazione. Nel corpo del messaggio devono essere specificati i
componenti del gruppo. Tale messaggio di posta elettronica deve essere mandato
a tassi@cs.unibo.it e in copia a sangio@cs.unibo.it.
Valutazione del progetto
Il progetto verrà valutato con una discussione di gruppo, con tutti i componenti del gruppo presenti. Non è possibile per i componenti di un gruppo effettuare la discussione in incontri separati. Al termine della discussione ad ogni singolo componente del gruppo verrà assegnato un voto in base all'effettivo contributo dimostrato nel lavoro di progetto. La valutazione del progetto è indipendente dal numero di persone che compongono il gruppo. Il voto del progetto sarà in trentesimi, indicativamente 2/3 per il codice e 1/3 per la relazione. La discussione del progetto può abbassare o alzare il voto.
Un progetto senza relazione (o con una relazione indecente) non verrà considerato sufficiente, anche se dovesse funzioanre perfettamente.
Scelte implementative non banali (ad esempio nell'output html o nelle strutture dati), attività sul newsgroup (potete anche rispondervi a vicenda!), proposte di raffinamento delle specifiche saranno valutate positivamente.
Domande sul progetto
Domande e dubbi sulle specifiche del progetto o altro devono essere presentate nel newsgroup del corso (magari mettete il mio indirizzo email in CC)
unibo.cs.scienzeinternet.so