Ventiquattresima lezione -- a.a. 2013/14

Durante la lezione 24 (l'ultima lezione di teoria) abbiamo finito i lucidi lasciati in sospeso, riassunto il corso, discusso il progetto per il primo appello e fatto esercizi tratti dai compiti d'esame degli anni precedenti. Le lezioni di laboratorio continuano...

S.

Ventitreesima lezione -- a.a. 2013/14

Ecco qui i lucidi della lezione 23.

S.

Progetto per l'appello del 17,19/12/2013

Introduzione

Leggete *bene* *tutte* le istruzioni! In particolare i paragrafi modalità e raccomandazioni.
Un adventure è un gioco a tappe in cui bisogna scegliere le opzioni giuste ad ogni tappa per riuscire a trovare il percorso vincente. Tipicamente le tappe vengono mostrate una alla volta, in formato testo o grafico.

Descrizione del lavoro

Si richiede di implementare un programma che, tramite un'interfaccia grafica, consenta all'utente di "giocare" un semplice adventure, descritto in un file di testo formattato opportunamente. Il programma deve:

1. Consentire la scelta del nome del file di testo da cui leggere le varie tappe da linea di comando (parametro del main).
2. Gestire opportunamente il caso in cui il file specificato dall'utente non esista (visualizzando un messaggio opportuno).
3. Avere un'interfaccia utente grafica per gestire la comunicazione con l'utente.
4. Visualizzare il contenuto della tappa corrente in un'area di testo.
5. Consentire all'utente di scegliere la tappa successiva tramite un insieme opportuno di pulsanti. Deve esserci un pulsante per ogni opzione possibile (ossia per ogni tappa immediatamente raggiungibile dalla tappa corrente) e ogni pulsante deve avere come etichetta il numero della tappa successiva corrispondente. La GUI è quindi dinamica e cambia a seconda della tappa in cui ci si trova.
6. Mettere a disposizione dell'utente un'area di testo in cui "segnarsi" alcune scelte effettuate per mezzo di caratteri.

Un esempio di interfaccia del programma è riportato nella figura seguente. L'area di testo non editabile in alto a sinistra mostra il testo della tappa corrente. L'area di testo sulla destra serve all'utente per "segnarsi" le scelte effettuate. Il pannello in basso contiene tanti pulsanti (2) quante sono le tappe successive possibili (la 11 e la 10).

Ovviamente, questa è solo una delle molte possibili implementazioni, che viene fornita solo per esempio, e che quindi siete liberissimi di modificare.

Il formato del file contenente le tappe è il seguente:

• Una prima riga contenente un numero intero uguale al numero di tappe totali.
• Per ogni tappa:
  • Una prima riga contenente il numero identificativo della tappa (1 per la prima, 2 per la seconda, ecc.)
  • Una seconda riga contenente un numero intero (chiamiamolo N) che indica quante delle righe successive contengono il testo da visualizzare per quella tappa.
  • N righe contenenti il testo da visualizzare per quella tappa.
  • Una riga contenente un numero intero (chiamiamolo M) che indica quante opzioni sono possibili per quella tappa.
  • M righe contenenti ognuna un intero che indica la tappa successiva a seconda dell'opzione scelta.

Nel file le tappe sono ordinate (il file comincia con la prima tappa, poi c'è la seconda, ecc.). Il programma deve funzionare con qualsiasi file che rispetti le convenzioni suddette. A titolo di esempio, vi forniamo un "adventure" per la realizzazione del progetto di programmazione. Notate la tappa numero 9, corrispondente alla figura precedente:

9
3
Ormai non c'e' piu' tempo per trovare qualcun altro che non sia gia' in un gruppo.
Se decidi di fare da solo, segna 1 e vai al 11.
Se decidi di cercare qualche altro gruppo a cui manca un componente e aggregarti a loro, vai al 10.
2
11
10

Siete ovviamente liberi di divertirvi e sperimentare altri file...

Suggerimenti

• Rappresentate in un'opportuna struttura dati in memoria tutte le tappe (quindi leggerete il file un'unica volta all'inizio dell'esecuzione del programma...).
• Potreste aver bisogno di una classe Tappa, definita da voi, per rappresentare una singola tappa...
• Vi servirà il metodo Integer.parseInt(String) per convertire una stringa in un intero (ad esempio, la stringa "5" nell'int 5)
• I pulsanti in basso andranno cancellati e ricreati ad ogni tappa. Per farlo, vi possono essere utili i metodi:
  • public void remove(Component comp) di java.awt.Container (e quindi ereditato in Frame...);
  • public void validate() di java.awt.Container (ereditato in Frame...); e
  • public void repaint(long tm) di java.awt.Component (ereditato in  Frame...).
  Guardate la documentazione delle API corrispondente.

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:

1. Una breve analisi del problema ed una descrizione intuitiva della vostra soluzione (meno di 2 pagine!).
2. 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.
3. 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.
4. 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).
5. 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").
6. 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: la scadenza per la consegna è il martedì 17 dicembre 2013 ore 15:30. La consegna va effettuata sia in forma cartacea (1 copia, depositatela nella "Drop-box" sulla porta dello studio di Mizzaro o consegnatela all'inizio dello scritto), sia via posta elettronica. Si richiede un unico messaggio con le caratteristiche seguenti:

• 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").

Riceverete una notifica dell'avvenuta ricezione dell'email.
NOTA Questo progetto è valido per chi intende sostenere l'esame nell'appello del 17, 19 dicembre 2013, 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.

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.
• Non usate public solo perché il compilatore dà errore. Usatelo solo se serve veramente.

Per eventuali dubbi rivolgersi ai docenti, o durante l'orario di ricevimento o per posta elettronica. Ma solo dopo aver letto *bene* *tutte* le istruzioni! In particolare i paragrafi modalità e raccomandazioni.

Ventiduesima lezione -- a.a. 2013/14

Ecco qui i lucidi della lezione 22.

S.

Ventunesima lezione -- a.a. 2013/14

Ecco qui i lucidi della lezione 21.

S.

Scadenza autovalutazione

Come vi avevo preannunciato, la scadenza per l'attività di autovalutazione in laboratorio è il 17 dicembre 2013. Il sistema resterà aperto, ma quello che farete dopo il 17 dicembre non influenzerà il voto. Altre scdenze e modalità d'esame sono state comunicate a lezione e sono sui lucidi; se non capite chiedete...

S.

Ventesima lezione -- a.a. 2013/14

Ecco qui i lucidi della lezione 20. In più, alcune informazioni sull'AWT e un file compresso con alcuni esempi visti nelle ultime lezioni.

S.

Diciottesima e diciannovesima lezione -- a.a. 2013/14

Ecco qui i lucidi delle lezioni 18 e 19 (abbiamo "recuperato" la lezione)

S.

Diciassettesima lezione -- a.a. 2013/14

Ecco qui i lucidi della diciassettesima lezione -- siamo sempre in "ritardo" di una lezione...

E qui c'è un file .zip contenente il javadoc e il sorgente delle API.

S.

Programma del corso

Mi è stato chiesto dove si trova il programma del corso...

S.

Sedicesima lezione -- a.a. 2013/14

Ecco qui i lucidi della sedicesima lezione -- siamo sempre in "ritardo" di una lezione...

S.

Quindicesima lezione -- a.a. 2013/14

Ecco qui i lucidi della quindicesima lezione -- siamo sempre in "ritardo" di una lezione...

Nei primi lucidi c'è anche un calendario provvisorio delle attività e scadenze da qui a gennaio.

S.

Quattordicesima lezione -- a.a. 2013/14

Ecco qui i lucidi della quattordicesima lezione. Li abbiamo finiti la lezione successiva -- siamo in "ritardo" di una lezione, ma recupereremo :)

S.

Tredicesima lezione -- a.a. 2013/14

Ecco qui i lucidi della tredicesima lezione.

S.

Dodicesima lezione -- a.a. 2013/14

Ecco qui i lucidi della dodicesima lezione. Contengono anche le date degli esami.

S.