Programmazione ad oggetti 2016/2017

Main

News

Info

Resources

Exam

Regole relative all’esame (a.a. 16/17)

Si riportano qui di seguito le regole di svolgimento e di gestione degli esami relativamente all'anno di corso 2016/2017. 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 e tantomeno per laureandi. 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. Contestualmente, si mandi anche una mail al docente con motivazione.

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.

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 dovrà contattare il docente via mail per richiedere lo sblocco della registrazione, altrimenti impossibile.

Svolgimento della prova di laboratorio

S1. La tipica struttura di una prova di laboratorio (che può tuttavia subire variazioni) consta di 2 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 un esercizio avviene appena lo studente reputa di averlo finito, e comunque se e solo se la funzionalità da realizzare soddisfa il test previsto per quell'esercizio o, qualora non disponibile, se l'esercizio è funzionalmente completo.

S3. All'inizio della prova sarà comunicato il numero di esercizi svolti correttamente necessari al superamento della prova (di norma 1 su 2): 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. Il numero preferito è 3, numero che permette di cimentarsi con gli aspetti di "team" di progettazione e implementazione. Agli studenti che non riuscissero a formare un tale gruppo, si chiede di dichiarare per tempo la propria disponibilità sul forum "Progetti-gruppi", in modo da favorire l'aggregazione spontanea di studenti in nuovi gruppi. Eccezioni a gruppi di 3 sono possibili se opportunamente motivate, ma portano a maggiori possibilità di valutazioni negative del progetto.

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. Ogni studente dovrà essere completo responsabile di una sua sottoparte identificata a priori del progetto. Ci potrà essere intersezione fra le parti degli studenti del gruppo, ma questa dovrà essere indicativamente 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 con un post sul forum "Progetti" simile a quello di prova "pepper-mgr". Il subject della proposta dovrà essere completo di: deadline scelta (A-E, vedere P7), acronimo (tassativamente non più di 10 caratteri alfanumerici minuscoli, inclusi eventualmente solo del simbolo "-"), membri del gruppo, titolo in esteso. Il corpo della proposta sia mezza pagina circa e includa  descrizione del risultato atteso, (ii) lista delle funzionalità necessarie, (iii) lista di funzionalità opzionali aggiuntive, (iv) challenge previste, (v) suddivisione di massima del lavoro fra i partecipanti. Gli studenti non comincino i progetti prima di avere ricevuto risposta positiva.

P7. Gli studenti dovranno decidere all'atto della formulazione della proposta a quale deadline fare riferimento, e dovranno completare e consegnare il risultato (software + relazione) in tempo, senza proroghe, e pena valutazione negativa del risultato (proporzionale al ritardo). Le deadline possibili per la consegna sono: (A) 15/2/2017, (B) 20/3/2017, (C) 31/5/2017, (D) 21/8/2017, (E) 25/9/2017. Gli studenti possono solo scegliere la prossima deadline disponibile o quella successiva.

P8. Gli studenti sviluppino il progetto in modalità cooperativa, utilizzando Git ed un repository BitBucket con nome OOP16-acronimo, che consentirà ai docenti di accedere più facilmente ai sorgenti e per la valutazione finale. All'atto della consegna tale repository dovrà essere pubblico, e nella sezione "download" ci dovrà essere:  un file PDF per la relazione e (ii) un singolo file JAR eseguibile dell'applicazione. Quest'ultimo dovrà essere eseguibile indipendentemente dalla piattaforma supportante Java 8 (sarà provato in Linux, ed eventualmente in Windows/MacOS X), e dovrà contenere una configurazione pronta per una DEMO significativa del sistema -- ossia non una configurazione vuota. Non possono essere consegnati altri file o risorse esterne al jar eseguibile, eccetto eventuali file necessari alla demo, che dovranno essere caricabili dall'interno dell'applicazione. Il software dovrà funzionare senza problemi, partendo da una configurazione vuota, anche scaricando il solo file jar.

P9. All'atto della consegna, la sezione "sources" dovrà contenere tutti i file rilevanti per il progetto come tracciati da Git (il codice sorgente, i file di configurazione Eclipse del progetto, le risorse esterne, eventuali librerie inserite manualmente nel classpath). Il progetto, una volta clonato, dovrà essere direttamente importabile in Eclipse, e dovrà compilare all'interno del suddetto IDE. Realizzare un progetto non importabile (ad esempio perché non si sono tracciati i giusti file), o tracciare file non necessari (ad esempio i .class compilati) comporta una maggior possibilità di valutazioni negative del progetto. 

Consegna e discussione del progetto

C1. Un progetto si ritiene ultimato quando tutti gli studenti hanno raggiunto il monte ora sopra indicato, è stato realizzato l'insieme delle funzionalità necessarie, il codice è opportunamente commentato (con commenti javadoc), la relazione è stata prodotta in formato corretto, e il repository è strutturato come da regole P8 e P9.

C2. La relazione dovrà seguire l'esempio che verrà fornito in fondo a questa pagina, ed includere tutte le sezioni in essa descritte. Per velocizzare le operazioni di correzione, si richiede che la struttura del documento ricalchi esattamente quanto proposto dai docenti. Si noti che il compito della relazione è duplice:  spingervi a relazionare correttamente il vostro artefatto software e il suo processo di sviluppo, (ii) aiutare i docenti a comprendere l'organizzazione del codice senza dover guardare per intero i sorgenti: se non sarà efficace da questo punto di vista allora il progetto non potrà essere valutato positivamente.

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 dichiarandolo verrà considerato positivamente.

C4. Completato il progetto, questo dovrà essere consegnato entro la deadline. A fronte di una consegna non corretta, si riceveranno eventuali feedback per la sua correzione (da realizzarsi in poche ore).

C5. La discussione avverrà con tutti i membri del gruppo: comincerà con una demo di circa 5 minuti dell'applicazione svolta da un membro del gruppo sul suo PC (se possibile), poi ci sarà una discussione generale sull'architettura del sistema, e quindi il docente discuterà con ogni studente la sua parte (circa 10 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, contando al 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 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. Il punteggio della prova di progetto rimarrà comunque valido.

F3. I voti di entrambe le prove sono ritenuti validi per tutto l'anno accademico in cui sono stati conseguiti. Qualora siano stati conseguiti in agosto/settembre, saranno ritenuti validi fino a marzo dell'anno successivo.

Esempi di progetti

Ricordando allo studente che ha massima libertà nel proporre progetti, forniamo qui di seguito esempi possibili/consigliati:

• *Produttività*: applicazione di utilità, ad esempio editor di codice; strumenti per la matematica (studio di funzione, integrazione, derivazione), la controllistica (diagrammi di bode, nyquist...), o altre discipline; strumenti per la creazione di grafici; strumenti per il disegno tecnico o di schemi, eccetera.
• *Multimedia*: applicazione di manipolazione o visualizzazione di file multimediali (editor di immagini, audio, riproduttore video, applicazione per il disegno, modellazione in tre dimensioni, eccetera).
• *Game*: applicazione che realizza un gioco, sia esso nuovo o clone di un game esistente
• *Simulazione*: simulazione di un sistema fisico naturale o artificiale, come quelli proposti qui: http://modelingcommons.org/

Si ricorda che, qualunque sia il progetto, è consentito (ed anzi raccomandato) l'uso di librerie Java esistenti non presentate a lezione (jmonkeyengine, tvdb, guava, swt...), come quelle presenti in questa lista: http://bit.ly/awesome-java

E' possibile che i docenti abbiano qualche proposta di progetto: se interessati li si contatti. 

Una lista dei progetti dell'a.a. 15/16 è reperibile al seguenti link (ad ogni progetto si segua il link "Fork of" per accedere al repository originale, che include anche la relazione):

https://bitbucket.org/danysk/profile/repositories?search=OOP15+

Fra questi, esempi di progetti complessivamente "molto buoni" e quindi considerabili come buon riferimento, sono: spaceimpactredux, hsm, delirium, jwave, aboidsim, atlas.

Modalità di svolgimento e di valutazione del progetto

• Per proporre un progetto, uno dei componenti crei una discussione sul forum (seguendo il template di discussione già creato)
• 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