Avviso

L'orale del 24 settembre è posticipato alle ore 15:00.

S.

Progetto per l'appello del 21 settembre

Premessa

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

Introduzione

Si richiede di implementare un programma che permetta di visualizzare in forma di istogramma i dati relativi ai punti realizzati dai giocatori di una squadra di basket, in modo semplificato.

Descrizione del lavoro

Il programma deve visualizzare un'interfaccia utente grafica contenente almeno 3 pulsanti e 2 aree di testo. La figura 1 illustra un possibile aspetto dell'interfaccia. La finestra del programma deve essere ridimensionabile e i componenti devono scalare automaticamente quando l'utente modifica le dimensioni della finestra.

Figura 1

Quando l'utente clicca sul pulsante "Leggi Giocatori", 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 i nomi dei giocatori letti nell'area di testo a sinistra. Ad esempio, se il file con il numero dei giocatori contiene

10

e il file con i nomi dei giocatori contiene

Cino
Dino
Gino
Lino
Mino
Nino
Pino
Rino
Tino
Vino

l'interfaccia utente si presenta come illustrato in figura 2.

Figura 2

Quando poi l'utente clicca sul pulsante "Leggi Punti", il programma deve leggere da un terzo file di testo i punti segnati da ogni singolo giocatore e visualizzare un istogramma "verticale" (non orizzontale) con la somma dei punti segnati da ogni singolo giocatore. Anche il terzo file deve essere un file di testo (ossia visualizzabile da linea di comando e creabile/modificabile con un
editor di testo), e deve avere un formato predefinito: su ogni linea, deve comparire il nome del giocatore, uno spazio e il tipo di canestro segnato (da 1, 2 o 3 punti).

Ad esempio, un possibile file di punti è il seguente:

Gino 1
Dino 1
Lino 2
Gino 1
Mino 3
Mino 1
Nino 2
Pino 1
Rino 1
Gino 3
Vino 1
Gino 2
Gino 2
Gino 1
Tino 2
Gino 1
Nino 2
Mino 2
Dino 2
Rino 3
Gino 1
Gino 1
Gino 1
Gino 1
Gino 1
Gino 1

che porta a un istogramma come quello illustrato in figura 3.

Figura 3

I nomi dei tre file vanno passati al programma sulla linea di comando secondo questa sintassi:

java NomeProgramma FileConNumeroGiocatori FileGiocatori FilePunti

Si noti che i singoli canestri rappresentati nel file dei punteggi vanno sommati giocatore per giocatore per ottenere i valori da visualizzare nell'istogramma; nell'esempio, questi valori sono:

Cino 0
Dino 3
Gino 17
Lino 2
Mino 6
Nino 4
Pino 1
Rino 4
Tino 2
Vino 1

Si noti anche l'area di testo a destra usa un font monospaziato per la visualizzazione corretta dell'istogramma. Fate riferimento alla classe java.awt.Font. Anche il metodo java.lang.Integer.parseInt(String) vi potrebbe essere molto utile…

Il pulsante "Esci" serve, ovviamente, a chiudere la finestra e terminare l'esecuzione del programma.

Il programma deve essere composto almeno delle seguenti classi:

• GUI (con eventuali classi interne per gli ascoltatori. Potete comunque implementare gli ascoltatori anche come classi "normali".)
• Istogramma (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:

1. Una breve analisi del problema ed una descrizione intuitiva delle specifiche (meno di 2 pagine!).
2. Le eventuali semplificazioni apportate rispetto alla versione completa richiesta (poche righe). Ovviamente, le semplificazioni porteranno a valutazioni inferiori. Inoltre, le semplificazioni vanno adeguatamente motivate.
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.).
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, scritto in font monospaziato, ossia 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, ossia il 21 settembre 2009 ore 9:00, sia in forma cartacea (1 copia), sia via posta elettronica (2 copie, una per docente, indirizzi: coppola@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 l'appello del 21, 24 settembre 2009), e va quindi consegnato entro la scadenza del 21 settembre 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, preferite le variabili locali ai metodi.
• 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.

Esame scritto secondo appello

Qui.

S.

Progetto per l'appello del 10,16/07/2009

Il progetto per l'appello del 10,16/07/2009 è lo stesso dell'appello precedente.

S.

Ventiquattresima - e ultima lezione

e qui c'è il codice degli esempi)
S.

Progetto per l'appello del 24 giugno

Premessa

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

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:

1. per orario di partenza
2. per orario di arrivo
3. per città di partenza
4. per città di arrivo
   

Ogni volta che si cambia scelta nella choice gli orari devono essere riordinati secondo il criterio selezionato.

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.
Fino ad ora hai speso ... 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...)

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) e Double.parseDouble(String) per convertire una stringa in un double
  
• Può esservi utile usare le Collection con i relativi metodi per l'ordinamento e i Reader con i relativi metodi per leggere da file di testo...
  

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. 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, ossia il 24 giugno 2009 ore 09:00, sia in forma cartacea (1 copia), sia via posta elettronica (2 copie, una per docente, indirizzi: coppola@uniud.it e mizzaro@dimi.uniud.it). Si richiede un unico messaggio (inviato dal proprio indirizzo email ufficiale. Messaggi da fiorellino88@gmail.com o simili non verranno presi in considerazione):

• con oggetto "Progetto per Programmazione [TWM]",
• 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 l'esame nell'appello del 24, 29 giugno 2009, 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?
• 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, preferite le variabili locali ai metodi.
• 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.

Ventitreesima lezione

(e qui c'è il codice d'esempio)

S.

Avviso

La lezione di teoria di giovedì 28 maggio è sospesa. Le ultime due lezioni del corso (per la parte di teoria) saranno quindi martedì 26 maggio e giovedì 4 giugno (il 2 giugno è festa...)

S.

Ventunesima (e ventiduesima) lezione

(e il codice degli esempi è qui).
S.

Ventesima lezione

(arrivati al 22).
S.

Diciannovesima lezione

(arrivato al 24).

E qui trovate il codice dell'esempio giocattolo su package e javadoc.

S.

Come incide il laboratorio sul voto finale d'esame

Mizzaro ed io ci siamo riuniti con i docenti di laboratorio e siamo arrivati alla conclusione che, quasi sicuramente, l'autovalutazione concorrerà al voto finale in questo modo:

• ordineremo tutti gli studenti del primo anno secondo 4 criteri diversi (ottenendo così 4 classifiche diverse)
  
  1. punteggio risolutore,
  2. punteggio valutatore,
  3. numero di esercizi risolti (in realtà useremo il valore di steadiness che dipende dal numero di esercizi risolti. Chi volesse saperne di più può andare a leggersi l'articolo di Mizzaro che parla di queste cose),
  4. numero di esercizi valutati (anche in questo caso useremo il valore di steadiness);
• divideremo ognuna delle 4 classifiche in tre;
• se uno studente si trova nella parte alta di una classifica si prende +1 punti, se si trova nella parte bassa si prende -1 punti, se si trova nella parte di mezzo si prende 0 punti;
  
• ogni studente avrà un bonus dato dalla media armonica dei quattro punteggi ottenuti nelle quattro classifiche;
• il bonus viene aggiunto o tolto dal voto finale.

Buon lavoro e buon divertimento >:->

Diciottesima lezione

(arrivati al 36).
S.

Sondaggio

Vi chiedo di rispondere alle seguenti domande. Grazie,
S.

Sedicesima lezione

(arrivato al 17).
Attendo commenti e reazioni...

Quindicesima lezione

(arrivato al 27).

Quattordicesima lezione

(arrivati al 36)

Tredicesima lezione

(prima lezione con Stefano Mizzaro: commenti, please!)
S.

Dodicesima lezione

P.S. Lo so, a lezione vi ho raccontato di... questo. I concetti, comunque, sono quelli. Non vi preoccupate.

Undicesima lezione

Vacanze di Pasqua

Per staccare un po' dai continui esercizi di programmazione che, sono sicuro, state facendo e rifacendo, vi consiglio un video su cui riflettere:

Decima lezione

OT...

...ovvero off-topic...

Cercasi volontari per aiutare a gestire un blog durante la campagna elettorale per le europee.
Se interessati contattarmi via posta elettronica.

N.B.
Non sono previsti sconti di nessun tipo all'esame. Non ci sperate nemmeno...

Reazioni

Non so bene come interpretare il fatto che per gli ultimi post non c'é più nessuno che li reputi divertenti, ma qualcuno li reputa interessanti o eccezionali...
Qualche studente di Stanford ha forse iniziato a visitare il blog?

Nona lezione

Ottava lezione

Tu vo' fa l'americano

Per chi volesse confrontare le lezioni di Udine con quelle di Stanford...



Per chi ne volesse di più.

N.B.
Quand'ero giovane io,
non c'era tutto questo ben di Dio...

Settima lezione

Un po' in ritardo...

Questionario

Sesta lezione

Quinta lezione

Informazione importante (?)

Non va mica per niente bene che gli studenti abbiano dei portatili più belli di quello del prof...

Quarta lezione

Terza lezione

Seconda lezione

Giovedì 5 marzo alle 12:30 in aula I.

Prima lezione

Introduzione al corso.
3 marzo 2009 ore 14.30 aula I