Programmazione ad oggetti 2014/2015
| Main | News | Info | Schedule | Exam |
Si riportano qui di seguito le regole di svolgimento e di gestione degli esami relativamente agli studenti dell'anno di corso 2014/2015. Ogni studente è tenuto a conoscere le regole di cui sotto al momento in cui sostiene l'esame, e a leggere il presente documento prima di chiedere informazioni al docente. Per qualunque aspetto che esuli da quanto riportato qui sotto si contatti il docente.
Aspetti generali
L'esame si articola di due prove, la prova di "laboratorio" e il "progetto". La prima si terrà in appelli appositamente predisposti, nel laboratorio VELA. La seconda si terrà dopo che un gruppo ha terminato le attività del suo progetto e effettuata la consegna. Quindi per "appello", intendiamo un appello per la prova di laboratorio, e diremo che è stata sostenuta quando la si è sostenuta con esito positivo.
Iscrizione alla prova di laboratorio
L1. Vi saranno 6 appelli, tre nella sessione invernale (Gen-Feb), due in quella estiva (Giu-Lug) e una in quella autunnale (Sep).
L2. Non verranno effettuati altri appelli oltre a questi 6, per nessun motivo. Gli studenti si organizzino per tempo.
L3. Per partecipare ad un esame è necessario iscriversi presso le liste AlmaEsami. Le liste chiudono circa 5-6 giorni prima dell'esame. Chi non risulterà iscritto al momento della chiusura della lista non sarà ammesso all'esame, senza alcuna eccezione. Il sistema AlmaEsami è certificato e non perde traccia delle registrazioni, quindi lo studente è invitato a non contestare una sua eventuale assenza in lista, e quindi non si presenti all'esame se non è regolarmente iscritto. Vista in un altro modo, si consideri che sapersi registrare correttamente su AlmaEsami è precondizione per passare la prova di laboratorio.
L4. L'esame è un momento amministrativo ufficiale, e come tale va affrontato con la dovuta serietà: di conseguenza, chi si iscrive ad un esame è tenuto a presentarsi. In particolare, ci si cancelli dalla lista per tempo nel caso che, una volta registratisi e la lista sia chiusa, sopraggiunga un evento che vi impedisca la partecipazione all'esame.
L5. Lo studente che partecipa ad un appello è tenuto a presentarsi preparato su tutti gli argomenti pertinenti del corso, e non semplicemente per tentare la fortuna. Tali argomenti includono tutti quelli discussi in aula e laboratorio, esclusa la parte C#.
L6. A seguito della regola L5, nella sessione invernale si auspica che lo studente non partecipi a tutte e tre le prove. Nel caso fallisca le prima due e voglia essere ammesso a partecipare alla terza, lo studente contatti il docente via mail per un eventuale ricevimento.
Svolgimento della prova di laboratorio
S1. La tipica struttura di una prova di laboratorio (che può tuttavia subire variazioni) consta di 2 o 3 esercizi per una durata complessiva di 1.5 ore circa. Il voto sarà noto appena finito l'esame.
S2. Durante tale esame, la correzione di ogni esercizio avviene appena lo studente reputa di aver finito, e comunque se e solo se la funzionalità da realizzare soddisfa il test previsto per quell'esercizio (sia esso espresso con JUnit o un semplice test qualitativo).
S3. All'inizio della prova sarà comunicato il numero di esercizi svolti correttamente (esito positivo del test) necessari al superamento della prova (di norma 1 su 2 o 2 su 3): solo in caso di prova superata si valuteranno gli altri esercizi anche se parzialmente svolti.
S4. All'esame non si potrà consultare alcun tipo di materiale se non quello fornito dal docente, che comunque include il javadoc delle librerie del JDK.
Scelta e svolgimento del progetto
P1. La prova di progetto è sviluppata da gruppi di studenti, normalmente da 1 a 3. Eccezioni sono possibili se opportunamente motivate.
P2. Nel concepire un possibile progetto, ogni studente tenga conto che dovrà investire nell'attività di progetto circa 80-100 ore di lavoro (ossia né molte di più, né molte di meno).
P3. Lo studente dovrà sempre tenere traccia delle ore di lavoro svolte e fornirle al docente a richiesta.
P4. Nel caso di progetto di gruppo, ogni studente dovrà essere completo responsabile di una sua sottoparte identificata a priori. Ci potrà essere intersezione fra le parti, ma questa dovrà essere non più del 30% del progetto complessivo.
P5. In fondo a questo documento sono presenti alcune proposte, ma spetterà agli studenti ispirarsi a queste per concepire un progetto preciso. Qualora il progetto includa aspetti tecnologici che esulano da questo corso (Android, rete, database, Web), questi non verranno considerati per il computo delle ore (80-100) e non verranno valutati in dettaglio: il grosso della valutazione riguarderà la parte di progettazione e programmazione OO.
P6. Concepita una proposta di progetto, gli studenti la sottoporranno ai docenti, che forniranno dei feedback prima del suo effettivo inizio. Tale proposta dovrà essere completa di: acronimo (10 caratteri alfanumerici minuscoli, inclusi eventualmente solo del simbolo -), titolo in esteso, membri del gruppo, mezza pagina di descrizione del risultato atteso e della lista di funzionalità da includere, suddivisione del lavoro fra i partecipanti. Si veda in fondo alla pagina la modalità effettiva.
P7. All'atto dell'accettazione, gli studenti dovranno decidere a quale deadline fare riferimento, e dovranno completare e consegnare il risultato (software + relazione) in tempo, senza proroghe, e pena valutazione negativa del risultato. Le deadline possibili per la consegna sono: (A) 10/1/2015, (B) 1/3/2015, (C) 31/5/2015, (D) 31/8/2015, (E) 25/9/2015. Gli studenti sono caldamente invitati a scegliere la prossima deadline disponibile, o eventualmente la successiva.
P8. Gli studenti sviluppino il progetto in modalità cooperativa, utilizzando Mercurial ed un repository BitBucket con nome OOP14-acronimo, che consentirà ai docenti di accedere più facilmente ai sorgenti e per la valutazione finale. All'atto della consegna tale repository sia reso pubblico, contenga nella sezione "sources" i sorgenti del codice, e nella sezione "download": 
il PDF della relazione e (ii) il JAR dell'applicazione. Si contatti il docente per concordare una consegna diversa se dovessere essere necessario.
Consegna e discussione del progetto
C1. Un progetto si ritiene ultimato quando tutti gli studenti hanno raggiunto il monte ora sopra indicato, è stato realizzato un insieme significativo delle funzionalità ipotizzate all'inizio, il codice è opportunamente commentato (con commenti javadoc), la relazione è stata prodotta, e il repository è strutturato come da regola P8.
C2. La relazione dovrà includere (seguendo l'esempio che verrà fornito in fondo a questa pagina) le seguenti sezioni: analisi del problema, progetto architetturale (attraverso 3-4 diagrammi UML), progettazione di dettaglio (una per ogni membro, con indicazione e spiegazione dei pattern utilizzati, decisioni di progettazione, e ulteriori UML di dettaglio), ed infine conclusioni (con auto-valutazione).
C3. Nella relazione (e nella documentazione del codice) lo studente è tenuto ad indicare con assoluta precisione la provenienza di codice scritto da altri presente nella propria parte di progetto: impossessarsi di codice scritto da altri e rivenderlo come proprio è un atto di plagio, e verrà considerato come fatto gravissimo. Al contrario, aver trovato buone librerie di altri ed averle usate con successo verrà considerato positivamente.
C4. Completato il progetto, questo dovrà essere consegnato entro la deadline. A fronte della consegna si potrebbero ricevere eventuali feedback per un suo miglioramento (da realizzarsi in poche ore), e quindi ci sarà la consegna definitiva (senza ulteriori feedback).
C5. La discussione avverrà con tutti i membri del gruppo: comincerà con una demo di circa 5 minuti (tassativi) dell'applicazione, svolta da un membro del gruppo, e quindi il docente discuterà con ogni studente la sua parte (circa 10-15 minuti a testa). Durante quest'ultima fase, lo studente si prepari ad illustrare la parte di sua pertinenza, cercando in modo molto conciso di mettere in buona luce gli aspetti più significativi (decisioni non banali di progettazione, pattern, eccetera).
C7. Alla fine della discussione, e in caso di valutazione positiva, ogni studente riceverà un voto in 30-esimi per la prova di progetto, e potrà verbalizzare seduta stante il voto finale.
C8. In casi eccezionali, il docente potrebbe richiedere agli studenti una integrazione al loro lavoro.
Aspetti finali
F1. La valutazione finale è ottenuta con media ponderata fra i risultati della prova di laboratorio e quella di progetto, contanto il 60% la prova delle due che ha dato la valutazione più alta, e 40% l'altra.
F2. Lo studente può ritentare la prova di laboratorio (senza dover rifare quella di progetto) in caso non fosse contento di un voto conseguito in precedenza, ma nel fare ciò perderà tale voto indipendentemente dall'esito del nuovo esame, ossia anche se si ritira durante la prova.
F3. I voti di entrambe le prove sono ritenute valide fino alla fine della sessione d'esame successiva. Si contatti il docente con largo anticipo se questa evenienza dovesse accadere.
Esempi di progetti
Ricordando allo studente che ha massima libertà nel proporre progetti, forniamo qui di seguito esempi possibili:
- *Applicazioni di tipo “simil-gestionale”*: Una applicazione con GUI che permette di gestire (inserire, editare, cancellare) contenuti di varia natura (specifici per il tipo di applicazione scelta), consentendo di salvare su disco, ricaricare, i dati etc.
- *Game*: Una applicazione con semplice GUI che realizza un game primitivo, nuovo o clone di un game esistente
- *Android App*: Sviluppo di una semplice APP Android di interesse, anche di tipo “simil-gestionale” (vedi sopra) ma sviluppata per Android.
- Gestione appuntamenti
- *Android-to-Java*: Ispirandosi a qualche APP Android (o iOS), realizzare il corrispondente programma in Java.
- *Simulation*: Un programma che realizzi una semplice simulazione di un sistema fisico naturale/artificiale come ad esempio quelli proposti qui: http://modelingcommons.org/.
- *New Libraries*: Una libreria riusabile, insieme ad una sua applicazione concreta in una anche semplice applicazione Java. Ad esempio:
- Libreria di componenti grafici
- Componenti grafici avanzati (ad esempio un visualizzatori del grafico di una funzione, o di un diagramma)
- Libreria di strutture dati non presenti nelle API di Java
- *Existing Libraries*: Utilizzo di una libreria esistente (trovabile in rete, non vista a lezione), per costruire una applicazione dimostrativa di degna complessità. Ad esempio:
- openGL: grafica ad alte prestazioni
- TVDB: caricamento di film dalla rete
- UnfoldedMaps: caricamento mappe
- Java 3D: gestione oggetti tridimensionali
- vlcj: player di filmati in Java
- SWT: libreria alternativa a Swing
E' possibile che i docenti abbiano qualche proposta di progetto: se interessati li si contatti.
Modalità di svolgimento e di valutazione del progetto: Under Construction
- Per proporre un progetto, uno dei componenti crei una discussione sul forum (modalità precisa da definirsi)
- I docenti accetteranno la proposta rispondendo al post iniziale, eventualmente suggerendo qualche proposta di modifica.
- Ove necessario, gli studenti potranno porre domande su quanto stanno facendo
- Gli studenti consegneranno relazione e codice sorgente
- I docenti daranno eventuali feedback su micro-modifiche e i docenti realizzeranno le poche modifiche
- Nel giro di qualche settimana (dipendentemente dalla coda) ci sarà la discussione
