Progetto per l'appello del 19, 22 settembre 2017

1. Premessa

Leggete bene tutte le istruzioni! In particolare i paragrafi 4. Modalità e 5. Raccomandazioni.

2. Introduzione

Si implementi un'applicazione che consente di leggere da file alcune note "segrete" (in realtà, cifrate) e di visualizzarle in seguito all'inserimento di una password.

3. Descrizione del lavoro

Ogni nota deve avere un identificatore numerico univoco, una data, e il contenuto (che è  memorizzato in modo cifrato). Si prevedano almeno tre tipi di note, che si differenziano per il contenuto:

1. Numero: oltre all'indentificativo e alla data contiene un int.
2. Account: oltre all'indentificativo e alla data contiene due campi relativi a username e password.
3. Testo: oltre all'indentificativo e alla data contiene un campo di testo libero.

 Il programma deve avere un'interfaccia utente grafica, che deve consentire di:

• caricare da file un elenco di note cifrate (si scelga un opportuno formato del file);
• visualizzare tramite un componente grafico opportuno l'elenco delle note con identificativo numerico e data;
• visualizzare tramite un componente grafico opportuno una nota in seguito alla sua selezione; identificativo numerico e data vengono visualizzate in chiaro, il contenuto invece nel suo formato cifrato;
• permettere di inserire una master password (tramite un altro componente opportuno) e, se questa è corretta, visualizzare la nota in chiaro. Scegliere liberamente come memorizzare e gestire la master password (ossia, non serve una soluzione "a prova di bomba");
• terminare l'esecuzione tramite un comando da menu.

La finestra del programma deve essere ridimensionabile e i componenti devono scalare automaticamente quando l'utente modifica le dimensioni della finestra.

La codifica va effettuata usando il Cifrario di Cesare, o un altro metodo più sofisticato. Il programma deve consentire di aggiungere facilmente nuovi metodi di cifratura.

Si devono implementare almeno le seguenti classi:

• Nota, per rappresentare una singola nota;
• NoteSegrete, contenente il programma principale;
• FrameNoteSegrete, per l'interfaccia utente grafica;
• Codifica, contenente i metodi per cifrare e decifrare;

(ma l'implementazione ottimale contiene almeno altre quattro classi...)

4. 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 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ì 19 settembre 2017 ore 15:30. La consegna va effettuata sia in forma cartacea (1 copia, consegnatela all'inizio della prova scritta o depositatela nella "Drop-box" sulla porta dello studio di Mizzaro), 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 destinatario l'indirizzo stefano.mizzaro  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'appello del 19, 22 settembre 2017 e va quindi consegnato entro la scadenza. Non si accetteranno ritardi per nessun motivo. Per gli appelli successivi saranno predisposti altri progetti.

5. 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 4. Modalità e 5. Raccomandazioni. 

Progetto per l'appello del 6,8 settembre 2017

1. Premessa

Leggete bene tutte le istruzioni! In particolare i paragrafi 4. Modalità e 5. Raccomandazioni.

2. Introduzione

Si implementi un'applicazione che consente di leggere da file alcune note "segrete" (in realtà, cifrate) e di visualizzarle in seguito all'inserimento di una password.

3. Descrizione del lavoro

Ogni nota deve avere un identificatore numerico univoco, una data, e il contenuto (che è  memorizzato in modo cifrato). Si prevedano almeno tre tipi di note, che si differenziano per il contenuto:

1. Numero: oltre all'indentificativo e alla data contiene un int.
2. Account: oltre all'indentificativo e alla data contiene due campi relativi a username e password.
3. Testo: oltre all'indentificativo e alla data contiene un campo di testo libero.

 Il programma deve avere un'interfaccia utente grafica, che deve consentire di:

• caricare da file un elenco di note cifrate (si scelga un opportuno formato del file);
• visualizzare tramite un componente grafico opportuno l'elenco delle note con identificativo numerico e data;
• visualizzare tramite un componente grafico opportuno una nota in seguito alla sua selezione; identificativo numerico e data vengono visualizzate in chiaro, il contenuto invece nel suo formato cifrato;
• permettere di inserire una master password (tramite un altro componente opportuno) e, se questa è corretta, visualizzare la nota in chiaro. Scegliere liberamente come memorizzare e gestire la master password (ossia, non serve una soluzione "a prova di bomba");
• terminare l'esecuzione tramite un comando da menu.

La finestra del programma deve essere ridimensionabile e i componenti devono scalare automaticamente quando l'utente modifica le dimensioni della finestra.

La codifica va effettuata usando il Cifrario di Cesare, o un altro metodo più sofisticato. Il programma deve consentire di aggiungere facilmente nuovi metodi di cifratura.

Si devono implementare almeno le seguenti classi:

• Nota, per rappresentare una singola nota;
• NoteSegrete, contenente il programma principale;
• FrameNoteSegrete, per l'interfaccia utente grafica;
• Codifica, contenente i metodi per cifrare e decifrare;

(ma l'implementazione ottimale contiene almeno altre quattro classi...)

4. 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 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 mercoledì 6 settembre 2017 ore 09:00. La consegna va effettuata sia in forma cartacea (1 copia, consegnatela all'inizio della prova scritta o depositatela nella "Drop-box" sulla porta dello studio di Mizzaro), 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 destinatario l'indirizzo stefano.mizzaro  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'appello del 6, 8 settembre 2017 e va quindi consegnato entro la scadenza. Non si accetteranno ritardi per nessun motivo. Per gli appelli successivi saranno predisposti altri progetti.

5. 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 4. Modalità e 5. Raccomandazioni. 

N.B. È stato proclamato uno sciopero a cui ho intenzione di aderire. Se lo sciopero verrà confermato, il primo appello della sessione autunnale (ossia, l'appello del 6 settembre 2017) non si terrà. Il progetto sarà comunque lo stesso anche per l'appello successivo (del 19,22/9/2017), e quindi il lavoro non verrà sprecato.

Progetto per l'appello del 10, 13 luglio 2017

1. Premessa

Leggete bene tutte le istruzioni! In particolare i paragrafi 4. Modalità e 5. Raccomandazioni.

2. Introduzione

Si implementi un'applicazione che consente di leggere da file alcune note "segrete" (in realtà, cifrate) e di visualizzarle in seguito all'inserimento di una password.

3. Descrizione del lavoro

Ogni nota deve avere un identificatore numerico univoco, una data, e il contenuto (che è  memorizzato in modo cifrato). Si prevedano almeno tre tipi di note, che si differenziano per il contenuto:

1. Numero: oltre all'indentificativo e alla data contiene un int.
2. Account: oltre all'indentificativo e alla data contiene due campi relativi a username e password.
3. Testo: oltre all'indentificativo e alla data contiene un campo di testo libero.

 Il programma deve avere un'interfaccia utente grafica, che deve consentire di:

• caricare da file un elenco di note cifrate (si scelga un opportuno formato del file);
• visualizzare tramite un componente grafico opportuno l'elenco delle note con identificativo numerico e data;
• visualizzare tramite un componente grafico opportuno una nota in seguito alla sua selezione; identificativo numerico e data vengono visualizzate in chiaro, il contenuto invece nel suo formato cifrato;
• permettere di inserire una master password (tramite un altro componente opportuno) e, se questa è corretta, visualizzare la nota in chiaro. Scegliere liberamente come memorizzare e gestire la master password (ossia, non serve una soluzione "a prova di bomba");
• terminare l'esecuzione tramite un comando da menu.

La finestra del programma deve essere ridimensionabile e i componenti devono scalare automaticamente quando l'utente modifica le dimensioni della finestra.

La codifica va effettuata usando il Cifrario di Cesare, o un altro metodo più sofisticato. Il programma deve consentire di aggiungere facilmente nuovi metodi di cifratura.

Si devono implementare almeno le seguenti classi:

• Nota, per rappresentare una singola nota;
• NoteSegrete, contenente il programma principale;
• FrameNoteSegrete, per l'interfaccia utente grafica;
• Codifica, contenente i metodi per cifrare e decifrare;

(ma l'implementazione ottimale contiene almeno altre quattro classi...)

4. 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 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 lunedì 10 luglio 2017 ore 09:00. La consegna va effettuata sia in forma cartacea (1 copia, consegnatela all'inizio della prova scritta o depositatela nella "Drop-box" sulla porta dello studio di Mizzaro), 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 destinatario l'indirizzo stefano.mizzaro  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'appello del 10, 13 luglio 2017 e va quindi consegnato entro la scadenza. Non si accetteranno ritardi per nessun motivo. Per gli appelli successivi saranno predisposti altri progetti.

5. 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 4. Modalità e 5. Raccomandazioni. 

Progetto per l'appello del 19,22/6/2017

1. Premessa

Leggete bene tutte le istruzioni! In particolare i paragrafi 4. Modalità e 5. Raccomandazioni.

2. 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...)

3. 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... Anzi, meglio: dovete implementare 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...

4. 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 lunedì 19 giugno 2017 ore 9:00. La consegna va effettuata sia in forma cartacea (1 copia, consegnatela all'inizio della prova scritta o depositatela nella "Drop-box" sulla porta dello studio di Mizzaro), 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 essere indirizzato all'email di Mizzaro che trovate su tutti i lucidi del corso,
• 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 19, 22 giugno 2017, e va quindi consegnato entro la scadenza. Non si accetteranno ritardi per nessun motivo. Per gli appelli successivi saranno predisposti altri progetti.

5. 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 4. Modalità e 5. Raccomandazioni.

Progetto per l'appello del 7, 9 / 2 / 2017

Il progetto è lo stesso dei tre appelli precedenti; la sua descrizione è la seguente.

1. Premessa

Leggete bene tutte le istruzioni! In particolare i paragrafi 4. Modalità e 5. Raccomandazioni.

2. Introduzione

Si richiede di implementare un programma che permetta di leggere da file e visualizzare in forma aggregata i voti di una classe di studenti, in modo semplificato.

3. Descrizione del lavoro

Il programma deve visualizzare un'interfaccia utente grafica contenente almeno 3 pulsanti e 3 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 voti", il programma deve leggere da un file di testo i nomi e i voti ottenuti dagli studenti, e visualizzare i voti letti nell'area di testo a sinistra. Ad esempio, se il file con i voti contiene (notate che uno studente può aver ricevuto più voti, come è normale):

Meni 2
Cino 3
Dino 7
Gino 9
Cino 5
Lino 4
Mino 10
Cino 1
Nino 1
Pino 7
Pino 5
Cino 3
Rino 7
Dino 8
Gino 10
Tino 9
Meni 10
Meni 5
Pino 5
Cino 4
Vino 7
Leo 9
Cino 1
Pino 2
Meo 4
Neo 7
Cino 2
Teo 5
Pino 8
Meni 2
Toni 4
Cino 2
Pino 3
Meni 8
Cino 6
Lino 3
Mino 8
Cino 2
Nino 1
Pino 7
Meo 7
Meo 5
Pino 6
Meo 6
Neo 6
Cino 6

dopo aver cliccato su "Leggi voti" l'interfaccia utente si presenta come illustrato in figura 2.

Figura 2

Notate che il file di testo ha un formato predefinito: su ogni riga si trovano il nome dello studente e il voto ricevuto.
Quando poi l'utente clicca sul pulsante "Calcola", il programma deve calcolare le medie di ogni studente e visualizzarle nell'area di testo centrale, e calcolare e visualizzare un istogramma "verticale" (non orizzontale) con il numero di occorrenze ricevuto per ogni singolo voto nell'area di testo a destra. Con i dati visti in precedenza, il risultato è quello illustrato in figura 3.

Figura 3

Il pulsante "Esci" serve, ovviamente, a chiudere la finestra e terminare l'esecuzione del programma. Infine, aggiungete anche una barra dei menu, con un menu "File" con una voce "Salva" per salvare le medie e l'istogramma su due file di testo. I nomi dei tre file (uno in input e due in output) vanno passati al programma sulla linea di comando secondo questa sintassi:

java NomeProgramma FileConVoti FileMedie FileIstogramma

Si noti che 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 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)
• RegistroVoti
• Progetto

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

4. 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 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ì 7 febbraio 2017 ore 9:00. La consegna va effettuata sia in forma cartacea (1 copia, consegnatela all'inizio della prova scritta o depositatela nella "Drop-box" sulla porta dello studio di Mizzaro), 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, eddy.maddalena 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'appello del 7, 9 Febbraio 2017, e va quindi consegnato entro la scadenza. Non si accetteranno ritardi per nessun motivo. Per gli appelli successivi saranno predisposti altri progetti.

5. 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 4. Modalità e 5. Raccomandazioni.