Corso di Laurea in Tecnologie Web e Multimediali
Esame di Programmazione e laboratorio, A.A. 2004/05
Progetto per il secondo appello (11,15/04/2005):
Implementazione di uno scout semplificato per il basket

Premessa

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

Introduzione

Si richiede di implementare un programma che permetta di tenere le statistiche di tiro di un giocatore di basket, in modo semplificato. In gergo si dice "fare lo scout" di un giocatore.

Descrizione del lavoro

Il programma deve permettere di visualizzare la metà di un campo da basket. La finestra del programma deve essere ridimensionabile e il disegno del campo da gioco deve scalare automaticamente quando l'utente modifica le dimensioni della finestra.

Quando l'utente clicca sul campo da gioco il programma deve memorizzare il tiro e visualizzarlo con una x nel punto dove si è cliccato. L'interfaccia grafica deve permettere di specificare se il tiro è stato segnato (tramite un pulsante "Tiro segnato" da premere subito dopo aver cliccato sul campo da gioco), nel qual caso deve essere visualizzato con una x cerchiata. Anche i tiri, segnati e non, devono "scalare" quando la finestra viene modificata nelle dimensioni.

Infine l'interfaccia deve permettere di aggiungere tiri liberi segnati o no che però non vengono visualizzati sul campo.

Nelle due figure potete vedere un esempio di interfaccia con visualizzati tre tiri non segnati e un tiro segnato. Come potete vedere il disegno del campo e dei tiri rimane coerente anche modificando le dimensioni della finestra.

Il nome del giocatore di cui si vuol fare lo scout deve essere passato al programma sulla linea di comando. Ad esempio

java nomeProgramma Pippo

Quando il programma viene chiuso deve stampare sulla consolle le statistiche di gioco secondo questo esempio:

Pippo:
liberi: 4 su 6
tiri dal campo: 2 su 3

dove con liberi si intende tiri liberi.

Il programma deve essere composto almeno delle seguenti classi:

Il Tiro deve memorizzare le sue coordinate, quanti punti vale (1 se è un tiro libero e 2 se è un tiro dal campo) e se è stato segnato o meno. Deve implementare almeno i seguenti metodi e costruttori:

SegnaPunti deve essere un ActionListener e deve memorizzare i tiri effettuati in un array di oggetti Tiro. Potete limitare la dimensione dell'array con una costante. SegnaPunti deve implementare almeno i seguenti metodi:

Il CampoDaGioco deve essere un componente grafico che disegna il campo con tutti i tiri effettuati. Deve avere un'unità di misura la cui lunghezza in pixel dipende dalle dimensioni del componente grafico. Il CampoDaGioco ha anche un SegnaPunti che tiene traccia di tutti i tiri fatti. CampoDaGioco deve implementare almeno i seguenti metodi:

AscoltaTiriLiberi deve essere un ActionListener per i tiri liberi. Deve implementare almeno il metodo public void actionPerformed(ActionEvent) che aggiunge un tiro libero al segna punti del campo da gioco.

AscoltaTiri deve essere un MouseListener per i tiri dal campo. Deve implementare almeno il metodo public void mouseClicked(MouseEvent) che aggiunge un tiro al campo da gioco.

Infine Scout deve contenere il metodo main che costruisce e visualizza l'interfaccia grafica.

Una possibile interfaccia è mostrata in figura. Ovviamente, questa è 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 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 11 aprile 2005 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:

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 (11, 15 aprile 2005), e va quindi consegnato entro la scadenza del 11 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:

Altre raccomandazioni:

Per eventuali dubbi rivolgersi ai docenti, o durante l'orario di ricevimento o per posta elettronica.