Courses » OOP1516 » Regole relative all’esame

Regole relative all'esame

Si riportano qui di seguito le regole di svolgimento e di gestione degli esami relativamente agli studenti dell'anno di corso 2015/2016. 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.

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 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 o, qualore non disponibile, se è funzionalmente completa.

S3. All'inizio della prova sarà comunicato il numero di esercizi svolti correttamente 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. Il numero preferito è 3, 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 (10 caratteri alfanumerici minuscoli, inclusi eventualmente solo del simbolo "-"), membri del gruppo, titolo in esteso. Il corpo della proposta sia mezza pagina che includa (i) descrizione del risultato atteso, (ii) lista delle funzionalità necessarie, (iii) lista di funzionalità opzionali aggiuntive, (iv) challenge previste, (v) suddivisione del lavoro fra i partecipanti. Gli studenti non comincino i progetti prima di avere ricevuto risposta spositiva.

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) 1/2/2016, (B) 1/3/2016, (C) 31/5/2016, (D) 21/8/2016, (E) 25/9/2016. Gli studenti possono scegliere la prossima deadline disponibile o quella successiva.

P8. Gli studenti sviluppino il progetto in modalità cooperativa, utilizzando Mercurial ed un repository BitBucket con nome OOP15-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: (i) 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 (potrebbe essere provato in Linux, MacOS X o Windows), e dovrà contenere una configurazione pronta per una DEMO significativa del sistema -- ossia non una configurazione vuota. Non possono essere consegnati altri file e non possono essere consegnate risorse esterne al jar eseguibile, a meno di aver contrattato tale consegna in anticipo coi docenti, via post sul proprio thread nel forum.

P9. All'atto della consegna, la sezione "sources" dovrà contenere tutti i file rilevanti per il progetto come tracciati da Mercurial (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, e il repository è strutturato come da regole P8 e P9.

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, azioni volte ad anticipare cambiamenti futuri, e ulteriori UML di dettaglio), test effettuati, 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 dichiarandolo verrà considerato positivamente.

C4. Completato il progetto, questo dovrà essere consegnato entro la deadline. In rari casi a fronte della consegna si potrebbero ricevere eventuali feedback per un suo miglioramento (da realizzarsi in poche ore).

C5. La discussione avverrà con tutti i membri del gruppo: comincerà con una demo di circa 5 minuti (al massimo) 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 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 ritenute valide fino alla fine della sessione d'esame successiva. Si contatti il docente con largo anticipo se si sta per perdere un voto acquisito.

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
  • *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
    • ..si controlli anche questa lista
E' possibile che i docenti abbiano qualche proposta di progetto: se interessati li si contatti.

La lista dei progetti dello scorso anno è 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=OOP14+-+

Esempi di progetto eccellenti includono "converger" e "groove-pumpkin".

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