Regole relative all'esame

Si riportano qui di seguito le regole di svolgimento e di gestione degli esami relativamente all'anno di corso 2020/2021. 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, in laboratorio (o online). 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), gli altri tre distribuiti nelle due sessioni estiva (Giu-Lug) e autunnale (Sep) in modalità da definirsi.

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, sopraggiunga un evento che vi impedisca la partecipazione all'esame. Se invece la lista è già chiusa, si mandi anche una mail al docente per segnalare l'assenza.

L5. Correttezza vuole che lo studente che partecipa ad un appello sia preparato su tutti gli argomenti pertinenti del corso, ossia quelli discussi in aula e laboratorio.

L6. A seguito della regola L5, nel caso lo studente fallisca i primi due appelli (dei 6) e voglia provare anche il terzo, dovrà contattare il docente via mail per richiedere lo sblocco della registrazione, altrimenti impossibile. Non vi sono altri vincoli sugli appelli successivi.

L7. Per prassi di Ateneo, in merito alle modalità di rifiuto/accettazione voti, si stabilisce che:  lo studente ha diritto a rifiutare il voto conseguito in una prova di laboratorio al più una volta; (ii) tale rifiuto va espresso seduta stante, oppure entro il giorno successivo della prova stessa mediante mail al docente: altrimenti, il voto sarà considerato fissato una volta per tutte.

Svolgimento della prova di laboratorio

S0. Causa Covid, potrà essere necessario svolgere la prova online. Questo richiederà allo studente di avere a casa una opportuna configurazione di lavoro, che comprende: una stanza dove si svolgerà l'esame da soli, una connession di rete stabile, un PC (fisso o portatile) con microfono e telecamera, nel PC installato correttamente Eclipse e JDK 11, nel PC poter eseguire Zoom, uno smartphone che verrà utilizzato (via Google Meet) come webcam di sorveglianza. Istruzioni specifiche saranno diponibili ad ogni appello alla pagina di iscrizione all'esame. Chi non avesse a disposizione la configurazione di cui sopra dovrà contattare il docente.

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 saranno comunicate le modalità specifiche di attribuzione del punteggio, che prevedono come condizione necessaria il completamento di almeno un esercizio: solo in tal caso si valuteranno gli altri esercizi anche se parzialmente svolti.

S4. All'esame non si potrà consultare alcun tipo di materiale se non quello fornito contestualmente 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 è 4, numero che permette di cimentarsi con gli aspetti di "team" di progettazione e implementazione, e che richiede organizzazione e capacità di lavorare con qualità. 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 4 sono possibili se opportunamente motivate, ma si noti che tendono a portano a progetti di qualità complessiva più bassa.

P2. Nel concepire un possibile progetto, ogni studente tenga conto che dovrà investire nell'attività di progetto circa 80 ore di lavoro (ossia né molte di più, né molte di meno, pena decurtazione del voto acquisito sia in un caso che nell'altro). Lo studente dovrà sempre tenere traccia delle ore di lavoro svolte e fornirle al docente a richiesta.

P3. Sebbene lavorare in più persone ad una classe comune non sia da escludersi, ogni studente dovrà essere completo e unico responsabile di una parte chiaramente identificata a priori del progetto, e che giustifichi un lavoro di programmazione autonoma di 40-50 ore. Ci potrà essere intersezione fra le parti degli studenti del gruppo, ma tendenzialmente non ampia. Si consiglia una suddivisione per funzionalità dell'applicazione, che consenta ad ognuno di occuparsi per la sua parte sia di aspetti di "modello", che di interfaccia grafica, eccetera.

P4. In fondo a questo documento sono elencate alcune tipologie di proposte, ma spetterà agli studenti ispirarsi a queste per concepire un progetto preciso. Qualora il progetto includa aspetti tecnologici che esulano da questo corso (Rete, Database, Web), questi non verranno considerati per il computo delle ore (80) e non verranno valutati in dettaglio: il grosso della valutazione riguarderà la parte di progettazione e programmazione OO. Ci si raccomanda quindi di identificare un progetto che permetta di cimentarsi con un design non banale. Il motto del progetto deve essere "poco ma buono": meglio realizzare poche funzionalità ma farlo molto bene! Quindi si usi un approccio incrementale, dove prima si realizzanoo poche funzionalità obbligatorie, e poi compatibilmente col tempo se ne aggiungono di opzionali.

P5. Concepita una proposta di progetto, gli studenti la sottoporranno ai docenti con un post sul forum "Progetti" simile a quello di prova "pepper-mgr" che verrà inserito per primo nel forum. Il subject della proposta dovrà essere completo di: deadline scelta (A-E, vedere P6), 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 dell'obiettivo del progetto e 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.

P6. 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. Le deadline possibili per la consegna, distribuite lungo tutto il 2021, ossia: (A) 25/2/2021, (B) 25/4/2021, (C) 25/6/2021, (D) 25/8/2021, (E) 25/10/2021. Gli studenti possono solo scegliere la prossima deadline disponibile o quella successiva. Gli studenti laureandi si decidano per tempo perché non saranno concesse ulteriori deadline.

P7. Non sono mai concesse proroghe: una consegna corretta con meno di una settimana di ritardo comporterà una penalizzazione piuttosto moderata, una consegna ripetutamente non corretta comporterà una penalizzazione più consistente, mentre un ritardo di più di una settimana comporterà una penalizzazione considerevole e l'automatico rinvio alla deadline successiva. Quindi, gli studenti che incontrassero importanti problemi organizzativi nel loro progetto (ad esempio, membri che non si rendono più disponibili), tali da mettere in pericolo la deadline, sono tenuti a comunicare la cosa al docente con almeno 2 settimane di anticipo rispetto alla deadline stessa, con mail che abbia tutti i partecipanti in CC.

P8. Gli studenti sviluppino il progetto in modalità cooperativa, utilizzando Git ed un repository GitHub con nome OOP20-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 11 (sarà sicuramente provato in Linux, e probabilmente anche 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. Il software dovrà funzionare senza problemi, partendo da una configurazione vuota, anche scaricando il solo file jar.

P9. All'atto della consegna, il repository dovrà contenere tutti i file rilevanti per il progetto come tracciati da Git. Il progetto, una volta clonato, dovrà essere direttamente importabile in Eclipse, e dovrà compilare all'interno del suddetto IDE. Nel caso fosse presente un file build.gradle.kts, il progetto dovrà essere importabile usando "Import -> Existing Gradle Project". Altrimenti, dovrà essere importabile usando "Import -> Existing Projects into Workspace", ossia andranno tracciati i file di configurazione di Eclipse. 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.

Relazione del progetto

M1. La relazione del progetto, obbligatoriamente in formato PDF, andrà aggiunta alla radice repository col nome "report.pdf" (case sensitive) nel branch principale del progetto (di solito "master"). Si consiglia agli studenti di redigerla in LaTeX, anche se ciò non è obbligatorio. Gli studenti che dovesserlo redigerla in LaTeX possono tracciare i sorgenti della relazione in una cartella interna al progetto (separatamente dai sorgenti del medesimo), ma all'atto della consegna dovranno avere comunque il file "report.pdf" nella radice del repository.

M2. La struttura della relazione deve seguire pedissequamente quella del template fornito in laboratorio, e che verrà allegata in fondo alla pagina, e in particolare:  non è consentito inserire sezioni aggiuntive oltre a quelle previste, (ii) non è possibile omettere alcuna sezione che non sia esplicitamente dichiarata opzionale nel template, e (iii) non è consentito inserire una sezione con contenuti non conformi alle richieste. Si noti che il compito della relazione è duplice: spingervi a relazionare correttamente il vostro artefatto software e il suo processo di sviluppo, e 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 design del sistema non potrà essere valutato positivamente. Si ricordi che condizione necessaria perchè il design di un sistema sia di qualità è che sia stato descritto correttamente.

M4. Fallire nello strutturare correttamente la relazione comporterà un ritardo nell'accettazione del progetto, che non verrà corretto nel suo contenuto fintanto che la relazione non rispetterà dei requisiti minimi di qualità e conformità a quanto richiesto. Esempi di errori che possono portare ad una mancata accettazione del progetto sono:

• assenza di una sezione o di una sottosezione, o presenza senza adeguato contenuto informativo;
• assenza di una sezione per ciascuno studente laddove richiesto (ad esempio, un'unica sezione di design dettagliato per un progetto svolto da più studenti);
• diagrammi non leggibili;
• diagrammi estremamente caotici (schemi con dozzine classi, e/o schemi con classi con dozzine di metodi);
• presenza di sezioni non richieste (ad esempio l'elenco dei package, o delle classi, o dei metodi).

M5. 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 nell'apposita sezione) verrà considerato positivamente.

Consegna, discussione del progetto, e task C#

C1. Un progetto si ritiene ultimato quando tutti gli studenti hanno raggiunto il monte ora sopra indicato, è stato realizzato almeno l'insieme delle funzionalità necessarie, il codice è opportunamente commentato (con commenti javadoc), relazione e repository sono stati prodotti come sopra indicato.

C2. 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 e senza ulteriori errori).

C3. Il docente prenderà contatto col gruppo per la discussione dopo la deadline (mediamente nel giro di qualche settimane). 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 (max 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).

C4. Ogni studente selezioni un sottoinsieme autocontenuto delle classi del proprio progetto Java e ne effettui una trasposizione (anche parziale) in C# sfruttando le caratteristiche e rispettando le convenzioni di tale linguaggio. Si creino anche delle classi di test, specialmente laddove il codice non includa interazione con l'utente. Si noti che le classi Java non vanno in alcun modo alterate per facilitare la trasposizione in C#. Si tari tutto il lavoro affinché non richiedia più di 10 ore. Questo lavoro andrà consegnato entro le 2 settimane successive alla deadline del progetto: il gruppo crei un nuovo repository unico, con il codice C# di ogni componente in un folder a sé, e comunichi sul forum la corrispondente URL. 

C5. 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. In caso di valutazione negativa per uno studente, tipicamente dovuta a poco codice realizzato o a grossolani e ripetuti errori di programmazione object-oriented, verrà registrato sul libretto il non superamento della prova (come da prassi di ateneo -- vedere regola L7), e lo studente dovrà rimediare con un nuovo progetto o integrazione all'esistente.

Aspetti finali

F1. La valutazione finale è ottenuta con media ponderata fra i risultati della prova di laboratorio e quella di progetto (entrambe comprese fra 15 e 33), contando al 60% la prova delle due che ha dato la valutazione più alta, e 40% l'altra.

F2. I voti di entrambe le prove sono ritenuti validi fino a marzo 2022, dopo tale data si contatti il docente.

Esempi di progetti

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

• 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/
• 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).

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 (ad esempio nell'a.a. 17/18) è 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=OOP17+

Fra questi, esempi di progetti complessivamente "molto buoni" e quindi considerabili come buon riferimento, sono: bacteriasimulator, oop-ang, conway-sim, magnum-chaos, ga-game, arkanoid, e cctan. Si acceda analogamente a progetti più recenti. 

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 (nel farlo, dichiarino di aver seguito le regole P8, P9, e M1-5)
• I docenti daranno eventuali feedback su micro-modifiche e gli studenti realizzeranno le poche modifiche
• Nel giro di qualche settimana (dipendentemente dalla coda) ci sarà la discussione: si verrà contattati dai docenti