Descrizione del lavoro
Si richiede di implementare un programma che, tramite un'interfaccia grafica, consenta all'utente di comprare biglietti ferroviari.Il programma deve caricare da file di testo, passato come parametro sulla riga di comando, un insieme di orari di treni. Il file degli orari è strutturato come segue:
numero orari orario partenza1 città di partenza1 orario arrivo1 città di arrivo1 costo biglietto1 orario partenza2 città di partenza2 orario arrivo2 città di arrivo2 costo biglietto2 ...Un file d'orari di esempio può essere:
3 10 Udine 12 Venezia 8 04 Bologna 05 Firenze 4 22 Cosenza 08 Torino 56
Il programma, dopo aver caricato gli orari in una oppurtuna struttura dati, deve mostrare un'interfaccia grafica con una lista (
java.awt.List
), una choice (java.awt.Choice
) e un'area di testo (java.awt.TextArea
). La lista deve mostrare gli orari caricati, uno per riga. La choice deve permettere di ordinare, in ordine crescente, gli orari nella lista secondo quattro criteri:- per orario di partenza
- per orario di arrivo
- per città di partenza
- per città di arrivo
Ogni volta che si clicca su un elemento della lista, si acquista il biglietto corrispondente e nella textarea viene mostrato il messaggio
Hai acquistato il biglietto per il treno da ... a .... Partirai alle ... e arriverai alle .... Ti è costato ... euro.(Attenzione! Questo non è il modo giusto di progettare interfacce!! Serve solo per semplificarvi la vita... Il corso di Interazione Uomo Macchina dovrebbe chiarirvi le idee...)
Fino ad ora hai speso ... euro.
Suggerimenti
- Rappresentate in un'opportuna struttura dati in memoria tutti gli orari (quindi leggerete il file un'unica volta all'inizio dell'esecuzione del programma...).
- Potreste aver bisogno di una classe
Orario
, definita da voi, per rappresentare un singolo orario... - Vi serviranno i metodi
Integer.parseInt(String)
per convertire una stringa in un intero (ad esempio, la stringa"5"
nell'int 5
) eDouble.parseDouble(String)
per convertire una stringa in un double - Può esservi utile usare le
Collection
con i relativi metodi per l'ordinamento e iReader
con i relativi metodi per leggere da file di testo...
Modalità
Il livello di complessità del programma prodotto può essere deciso liberamente; 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. 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 in gruppi di 3 persone (a meno di accordi particolari con il docente, possibili solo in casi di reale e comprovata necessità), e tutti i componenti di un gruppo devono conoscere tutti i dettagli del progetto, come se l'avessero realizzato da soli.
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 della vostra soluzione (meno di 2 pagine!).
- Le eventuali semplificazioni apportate rispetto alla versione completa richiesta (poche righe). Le semplificazioni vanno adeguatamente motivate. Ovviamente, le semplificazioni porteranno a valutazioni inferiori, e in alcuni casi (quando le semplificazioni sono eccessive) a progetti insufficienti.
- 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.). Prima di aggiungere qualsiasi cosa, pensate a fare bene quello che è richiesto.
- 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 (in javadoc, ma non solo), 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.)
- deve essere inviato dal proprio indirizzo email ufficiale su spes (messaggi da fiorellino88@gmail.com o simili non verranno presi in considerazione),
- deve avere come destinatari i tre indirizzi stefano.mizzaro, dario.denart e marco.pavan tutti al mail server @uniud.it,
- deve avere in CC tutti i componenti del gruppo,
- deve avere come oggetto "Progetto per Programmazione [TWM]",
- deve contenere nel corpo i nomi dei componenti del progetto e,
- deve avere in allegato ("attach"), in un unico file compresso (ad es. zippato), la relazione, il codice sorgente (i file ".java") e il bytecode (i ".class").
NOTA Questo progetto è valido per chi intende sostenere l'esame nell'appello del 7, 9 gennaio 2014, e va quindi consegnato entro la scadenza. 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 ottenere una valutazione positiva:- 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.
- 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 direx=2;
!! - Non usate
static
solo perché il compilatore dà errore. Usatelo solo se serve veramente. - Non usate
public
solo perché il compilatore dà errore. Usatelo solo se serve veramente.