Programmazione ad oggetti 2013/2014

    Main     News     Info     Lab     Schedule     Projects     Exam

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 2013/2014 e successivi. 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à quando un gruppo ha terminato le attività del suo progetto, e lo vuole discutere. 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.

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, si avverta il docente per tempo nel caso che, una volta registratisi e la lista sia chiusa, sopraggiunga un evento che vi impedisca la partecipazione all'esame. Contestualmente, ci si cancelli anche dalla lista di iscrizione 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 Android e 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

S3. La prova risulta superata se la metà degli esercizi proposti (1 su 2, o 2 su 3) è svolta correttamente (esito positivo del test), e 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 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 100 ore di lavoro (ossia né molte di più, né molte di meno). 

P3. Lo studente dovrà 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.

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 minuscoli), titolo, membri del gruppo, mezza pagina di descrizione del risultato atteso e delle funzionalità da includere, suddivisione del lavoro fra i partecipanti. Si veda in fondo alla pagina la modalità effettiva.

P7. Una volta accettato, il progetto dovrà essere completato e discusso entro 3 mesi (auspicabilmente molto meno). Saranno concesse proroghe solo in casi assolutamente eccezionali.

P8. Si auspica che gli studenti sviluppino il progetto in modalità cooperativa, utilizzando Mercurial ed un repository BitBucket con nome OOP13-acronimo, che consentirà ai docenti di accedere più facilmente ai sorgenti per rispondere ad eventuali domande e per la valutazione finale.

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), e la relazione è stata prodotta. 

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), ed infine conclusioni (con auto-valutazione). Esempio di relazione: http://apice.unibo.it/xwiki/bin/download/Courses/OOP1314-esame/acme-exams-relazione.pdf

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 pre-consegnato. A fronte della pre-consegna si riceveranno eventuali feedback per un suo miglioramento (da realizzarsi in poche ore), e quindi ci sarà la consegna definitiva (senza ulteriori feedback).

C5. La discussione di un progetto, successivo alla consegna avverrà in uno dei due seguenti casi: quando tutti gli studenti del gruppo hanno sostenuto la prova di laboratorio, oppure dopo l'ultimo appello della sessione.

C6. La discussione avverrà con tutti i membri del gruppo: comincerà con una demo di non più di 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).

C7. Alla fine della discussione, e in caso di valutazione positiva, ogni studente che ha anche sostenuto la prova di laboratorio riceverà una proposta di voto finale, che potrà verbalizzare seduta stante.

C8. In casi eccezionali, il docente potrebbe richiedere agli studenti una integrazione al loro lavoro.

Altri aspetti

A1. Nella valutazione finale, si partirà dal risultato della prova di laboratorio, e a questa si apporterà un fattore addizionale (tipicamente compreso fra [-5,+7]) dipendentemente dall'esito della prova di progetto.

A2. 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.

A3. Un voto complessivo conseguito sarà ritenuto valido fino alla fine della sessione successiva, dopo andrà registrato o sarà perso.

A4. Un voto della prova di laboratorio rimarrà invece valido 1 anno solare.

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. Possibili esempi:
    • Gestionale di una semplice attività commerciale (p.e. un'edicola).
    • Gestione del fantacalcio
    • Gestionale di un database di riviste, CD, DVD, etc.
  • Game: Una applicazione con semplice GUI che realizza un game primitivo, ad esempio:
  • Android App: Sviluppo di una semplice APP Android di interesse, anche di tipo “simil-gestionale” (vedi sopra) ma sviluppata per Android. Ad esempio:
    • Calendario
    • Gestione note
    • 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

Interazioni durante il progetto

1 Per proporre un progetto, uno dei componenti crei una discussione sul forum: http://easi.polocesena.unibo.it/mod/forum/view.php?id=2715 , facendo attenzione a indicare di non volerne ricevere le notifiche, per evitare di essere notificati di qualunque mail di qualunque progetto. Il subject della discussione sia esattamente (senza apici) "acronimo, titolo, cognome_autore1, cognome_autore2, ..", e il corpo contenga la descrizione del risultato atteso e delle funzionalità da includere, e la proposta di suddivisione del lavoro fra i partecipanti. Si noti che tutte le interazioni successive per questo progetto avverrano attaverso risposte all'ultimo post di questa discussione.
2 I docenti accetteranno la proposta rispondendo al post iniziale, eventualmente suggerendo qualche proposta di modifica.
3 Ove necessario, gli studenti potranno porre domande su quanto stanno facendo, indicando il repository al quale accedere ai sorgenti.
4 Gli studenti pre-consegneranno relazione e codice sorgente
5 I docenti daranno feedback
6 Gli studenti consegneranno la versione finale.

Failed to execute the [velocity] macro. Cause: [Nested scripts are not allowed. Current Script Macro [velocity] (source [xwiki:Courses.Pages.Generic.Sheet]) is executed inside Script Macro [velocity] (source [xwiki:Courses.Pages.Generic.Sheet])]. Click on this message for details.

exam / course pages
course series