Corso di Laurea in Tecnologie Web e Multimediali
Esame di Programmazione e laboratorio, A.A. 2005/06
Progetto per il secondo appello (03, 06/04/2006):
Salvataggio pagelle giocatori letti da file

Premessa

Leggete bene tutte le istruzioni! In particolare i paragrafi modalità e raccomandazioni.

Introduzione

Si richiede di implementare un programma che permetta di salvare su file in formato xhtml le pagelle dei giocatori relativamente ad una partita.

Descrizione del lavoro

Il programma deve visualizzare un'interfaccia utente grafica contenente almeno 2 pulsanti, 1 casella di testo e 1 area di testo. La finestra del programma deve essere ridimensionabile e i componenti devono scalare automaticamente quando l'utente modifica le dimensioni della finestra.

Quando l'utente invoca il programma dalla linea di comando gli passa anche come argomento i file da cui leggere i giocatori. Ad esempio:

java Pagelle NumeroGiocatori.txt Giocatori.txt

Il programma deve leggere da un file di testo il numero di giocatori che compongono la squadra, leggere da un altro file di testo il nome dei giocatori della squadra e visualizzare il nome del primo giocatre nell'etichetta in alto.

Ad esempio, se il file con il numero dei giocatori contiene:

e il file con i nomi dei giocatori contiene:

Bigno
Bolda
Gabri
Gneur
Mauretto
Mugno
Neo
Paul
Silviuttis

l'interfaccia utente si presenta come illustrato in figura 1

Figura 1

I pulsanti <- e -> permettono di visualizzare le pagelle dei giocatori precedente e successivo. Se non c'è nessun giocatore precedente o successivo, il pulsante relativo deve essere disabilitato (si usi setEnable(boolean)). Si noti che quando si visualizza un giocatore per cui è già stata inserita una pagella, l'interfaccia la "ricorda" e la visualizza.

Figura 2

Quando l'utente chiude la finestra, il programma, prima di terminare, salva le pagelle nel file pagelle.html. Un esempio di file lo trovate qui.

Il programma deve essere composto almeno delle seguenti classi:

GUI (con eventuali classi interne per gli ascoltatori)
Pagella (con un metodo toString)
Giocatore
Progetto

L'interfaccia mostrata in figura è solo una delle molte possibili implementazioni, che viene fornita solo per esempio, e che quindi siete liberissimi di modificare. Potete anche apportare delle migliorie.

Modalità

Il livello di complessità del programma prodotto può essere deciso liberamente dagli studenti; ovviamente, progetti più articolati e complessi otterranno una valutazione migliore di progetti più semplici, ma si consiglia di fare "poco e bene" piuttosto che "tanto e male": progetti semplici possono comunque ottenere il massimo punteggio, purché ben fatti (leggete bene le raccomandazioni!). La durata prevista del lavoro, considerando un gruppo di 3 persone che lavorano a tempo pieno, è di una settimana al massimo.

Il progetto va realizzato assolutamente in gruppi di 3 persone e tutti i componenti di un gruppo devono conoscere tutti i dettagli del progetto, come se l'avessero realizzato da soli.
Progetti realizzati da gruppi di meno o più persone non verranno valutati. In caso di difficoltà? nel trovare compagni è possibile mandare una email ai docenti che provvederanno ad assegnare i compagni mancanti. L'unica eccezione a questa regola vale per gli studenti iscritti come lavoratori che devono comunque richiedere prima l'autorizzazione ai docenti via email. Senza autorizzazione il progetto non verrà? valutato.

Va preparata una breve relazione, preferibilmente (ma non necessariamente) in XHTML + CSS, sul lavoro effettuato. La relazione deve contenere:

Una breve analisi del problema ed una descrizione intuitiva delle specifiche (meno di 2 pagine!).
Le eventuali semplificazioni apportate rispetto alla versione completa richiesta (poche righe). Ovviamente, le semplificazioni porteranno a valutazioni inferiori. Inoltre, le semplificazioni vanno adeguatamente motivate.
Eventuali aggiunte (cose in più non richieste; ad esempio uso di componenti dell'AWT non spiegati a lezione, uso delle Swing, aggiunta di funzionalità? non richieste, aggiunta di menu, ecc. ecc.).
Le motivazioni di tutte le scelte effettuate (ad esempio, perché avete apportato una semplificazione, perché avete deciso di usare certi componenti grafici e non altri, perché avete fatto certe scelte di progetto piuttosto che altre, e così via).
Il listato completo del programma, con commenti, scritto in font non proporzionale (come questo: la "i" e la "m" occupano la stessa larghezza) e opportunamente incolonnato ("indentato").
Una "prova di esecuzione" (di circa 3 pagine) che illustri il funzionamento del programma: una spiegazione con testo e figure del modo in cui il programma funziona (aspetto dell'interfaccia utente, esempio di esecuzione adeguatamente spiegato, ecc.)

Il progetto va consegnato inderogabilmente entro l'inizio della prova scritta dell'appello, ossia il 03 aprile 2006 ore 9:00, sia in forma cartacea (1 copia), sia via posta elettronica (2 copie, una per docente, indirizzi: coppola@dimi.uniud.it e mizzaro@dimi.uniud.it). Si richiede un unico messaggio:

con oggetto "Progetto per Programmazione",
contenente nel corpo i nomi dei componenti del progetto e,
in allegato ("attach"), in un unico file compresso (ad es. zippato), la relazione, il codice sorgente (i file ".java") e il bytecode (i ".class").

Il progetto in forma cartacea può essere consegnato a mano subito prima del compito scritto oppure può essere consegnato nei giorni precedenti lo scritto direttamente a uno dei docenti o nella casella della posta del dipartimento di matematica e informatica.

NOTA Questo progetto è valido per chi intende sostenere il secondo appello (03, 06 aprile 2006), e va quindi consegnato entro la scadenza del 03 aprile ore 9:00 (inizio della prova scritta). Non si accetteranno ritardi per nessun motivo. Per gli appelli successivi saranno predisposti altri progetti.

Raccomandazioni

Alla valutazione del progetto concorrono vari aspetti (rilevanza delle semplificazioni apportate, qualità? della relazione, ecc.), ma è di prioritaria importanza la qualità? del programma prodotto, soprattutto per quanto concerne le caratteristiche di leggibilità?, modificabilità?... Esempi di criteri per la valutazione:

Il programma funziona?
Resiste agli errori di interazione con l'utente?
Si riescono ad apportare piccole modifiche nel comportamento senza riscrivere molto codice?
L'interfaccia utente grafica è ridimensionabile (ossia: non avete usato setResizable(false))? E quindi la si può usare su schermi di varie dimensioni?
Avete usato i layout manager?
Il codice è scritto correttamente, e avete seguito i principi della programmazione strutturata, dell'occultamento delle informazioni e dell'object oriented?
Il codice è commentato? Ci sono abbastanza commenti? Non ci sono troppi commenti? I commenti non sono scontati? I tre tipi di commenti disponibili in Java sono stati usati in modo corretto?
Avete rispettato le convenzioni sui nomi degli identificatori in Java?
La relazione è chiara?
Le variabili d'istanza e di classe non possono essere ridefinite come variabili locali?
ecc. ecc.

Altre raccomandazioni:

Non dichiarate una variabile se poi la usate una sola volta. Potete sicuramente scrivere un programma analogo senza quella variabile.
Non copiare scriteriatamente il codice trovato su Internet: chiunque può scrivere su Internet e non è detto che sappia cosa sta facendo.
Evitate al massimo setPreferredSize. Piuttosto pensate ad un layout che funzioni con qualsiasi dimensione sensata.
Evitate commenti del tipo x = 2; //assegno 2 a x: qualunque programmatore sa cosa vuol dire x=2;!!
Non usate static solo perché il compilatore dà? errore. Usatelo solo se serve veramente.
Limitate al massimo l'uso delle variabili d'istanza e di classe.
Non usate public solo perché il compilatore dà? errore. Usatelo solo se serve veramente.