How the exam takes place

Transcript

1 00.01 General information about the exam How the exam takes place General information about the exam The exam consists of a project (to be developed individually or by groups of two students), a written exam, and an oral exam. The project, which changes at each exam session, has to be submitted at least 10 days before the written exam. It is passed if the mark is at least 18/30; the mark is valid until the second exam session after the one in which the project is submitted. In case of late submission, a 3/30 penalty is applied for each day after the deadline. Should the project be resubmitted in a subsequent exam call, the mark of the previously submitted project is canceled; if the resubmission takes place in the same exam session, a 5/30 penalty is applied to the mark of the newly submitted project because the developers can benefit from the correction of the previously submitted project (the correction of the new project may reveal errors that went undetected during the correction of the previous one). The written exam, which changes at each exam call and can be taken only if the project has been passed, consists of 9 questions plus 2 exercises to carry out in 90 minutes. It is passed if the mark is at least 18/30; the mark is valid only for the exam call in which the written exam is taken. The oral exam, which can be taken only if the project and the written exam have been passed, consists of a discussion of the project and of the written exam, plus further questions. If passed, it determines an adjustment between -5/30 and 5/30 of the average of the two previous marks, thus yielding the final mark. The student must register to the written exam through the Esse3 system (this is possible only in case of regular payment of tuition fees). Moreover, the student must come to the written exam and to the oral exam equipped with academic record book and black or blue pen. c 2015 Marco Bernardo 1/10

2 00.01 General information about the exam L esame consiste in un progetto (da sviluppare individualmente o in gruppi di due studenti), una prova scritta e una prova orale. Il progetto, che cambia ad ogni sessione d esame, deve essere consegnato almeno 10 giorni prima della prova scritta. Esso è superato se il voto è di almeno 18/30; il voto rimane valido fino alla seconda sessione d esame successiva a quella in cui il progetto viene consegnato. In caso di consegna tardiva, viene applicata una penale di 3/30 per ogni giorno di ritardo. Qualora il progetto venga riconsegnato in un successivo appello d esame, il voto del progetto precedentemente consegnato viene annullato; se la riconsegna avviene nella medesima sessione, al voto del nuovo progetto consegnato viene applicata una penale di 5/30 perché gli sviluppatori possono beneficiare della correzione del progetto precedentemente consegnato (la correzione del nuovo progetto potrebbe svelare errori che erano passati inosservati durante la correzione di quello precedente). La prova scritta, che cambia ad ogni appello d esame e può essere sostenuta solo se il progetto è stato superato, consiste in 9 domande più 2 esercizi da svolgere in 90 minuti. Essa è superata se il voto è di almeno 18/30; il voto rimane valido solo per l appello d esame in cui la prova scritta viene sostenuta. La prova orale, che può essere sostenuta solo se il progetto e la prova scritta sono stati superati, consiste in una discussione del progetto e della prova scritta, più ulteriori domande. Se superata, essa determina un aggiustamento compreso tra -5/30 e 5/30 della media dei due precedenti voti, producendo così il voto finale. Lo studente deve registrarsi alla prova scritta tramite il sistema Esse3 (ciò è possibile solo in caso di regolare pagamento delle tasse universitarie). Inoltre lo studente deve presentarsi alla prova scritta e alla prova orale munito di libretto universitario e di penna nera o blu. c 2015 Marco Bernardo 2/10

3 00.02 General information about the project General information about the project The project consists of implementing an ANSI C program or library by following the methodology for developing software in the small presented during the course. The project has to be developed individually or by groups of two students. The projects exhibiting basically the same software will not be taken into consideration and their developers will not be admitted to the written exam. Any violation of what established in the following about the project submission, the report preparation, and the software development will determine a decrease of the project mark. c 2015 Marco Bernardo 3/10

4 00.02 General information about the project Il progetto consiste nell implementazione di un programma o di una libreria ANSI C seguendo la metodologia per sviluppare software in the small presentata durante il corso. Il progetto deve essere sviluppato individualmente o in gruppi di due studenti. I progetti che esibiscano praticamente il medesimo software verranno tutti annullati e i relativi sviluppatori non verranno ammessi alla prova scritta. Ogni inosservanza di quanto stabilito in seguito a proposito della consegna del progetto, della preparazione della relazione e dello sviluppo del software determinerà una riduzione del voto del progetto. c 2015 Marco Bernardo 4/10

5 00.03 Project submission Project submission The project must be submitted to at least 10 days before the written exam. The project should preferably be sent from an address of the domain campus.uniurb.it. In case of group of two students, the address of the second student must be in cc. The subject of the must be PLPr project submission for on-line students and consegna progetto PPL for face-to-face students. The body of the must contain the names, the serial numbers, and the year of enrollment (first, second, third, other) of the developers. The must have a.tar.gz or.zip attachment comprising only: A report called report.pdf. All the.c and.h files that have been developed, each with an appropriate name. The makefile. The project evaluation will be communicated via at least 3 days before the written exam to the same address from which the project was sent and to the address of the possible second student. c 2015 Marco Bernardo 5/10

6 00.03 Project submission Il progetto deve essere consegnato a marco.bernardo@uniurb.it almeno 10 giorni prima della prova scritta. Il progetto va preferibilmente inviato da un indirizzo del dominio campus.uniurb.it. In caso di gruppo di due studenti, l indirizzo del secondo studente deve comparire in cc. L oggetto della deve essere consegna progetto PPL per gli studenti in presenza e PLPr project submission per gli studenti on-line. Il corpo della deve contenere i nominativi, i numeri di matricola e l anno di corso (primo, secondo, terzo, fuori corso) degli sviluppatori. L deve avere un allegato.tar.gz o.zip comprendente esclusivamente: Una relazione denominata relazione.pdf. Tutti i file sorgenti.c e.h che sono stati sviluppati, ciascuno con un nome significativo. Il makefile. La valutazione del progetto verrà comunicata via almeno 3 giorni prima della prova scritta allo stesso indirizzo dal quale il progetto era stato spedito e all indirizzo dell eventuale secondo studente. c 2015 Marco Bernardo 6/10

7 00.04 Report preparation Report preparation The report should be written in correct English or Italian. The report should start with a cover page showing at least the developer names and should contain the following six sections (each starting on a new page): 1. Problem specification. Write faithfully the statement of the assigned problem. 2. Problem analysis. Identify the input data (which are provided) and the output data (which have to be produced) of the problem, together with the major relationships between them to be exploited in order to solve the problem, in a way that abstracts from the algorithmical aspects that will be subsequently designed. 3. Algorithm design. Within the framework of the given problem and its analysis, illustrate and motivate the major design choices (input and output representation, idea at the basis of the solution, employed data structures, etc.) and show the major steps together with possible refinements of the algorithm devised to solve the problem, in a way that abstracts from the characteristics of the ANSI C language (the steps of the algorithm must not be written in ANSI C). 4. Algorithm implementation. Complete and translate the algorithm in ANSI C language, then include in the report all the.c and.h files that have been developed, as well as the makefile. 5. Program testing. Conduct at least 10 meaningful tests of the complete execution of the program (we remind that compilation is not part of execution), by faithfully showing for each test both the input data provided via keyboard/file and the corresponding results written onto screen/file (in the case that a library is developed, it is necessary to write a test program that includes the library and uses its functions). 6. Program verification. Choose within the program a sequence of at least three noninput/output statements whose postcondition is not trivially a tautology and verify formally their correctness through Hoare triples. c 2015 Marco Bernardo 7/10

8 00.04 Report preparation La relazione deve essere scritta in corretta lingua italiana o inglese. La relazione deve iniziare con una pagina di copertina riportante almeno i nominativi degli sviluppatori e deve contenere le seguenti sei sezioni (ciascuna con inizio su una nuova pagina): 1. Specifica del problema. Riportare fedelmente l enunciato del problema assegnato. 2. Analisi del problema. Individuare gli input (dati che vengono forniti) e gli output (risultati che debbono essere prodotti) del problema, assieme alle principali relazioni intercorrenti tra di essi da sfruttare ai fini della soluzione del problema, astraendo dagli aspetti algoritmici che verranno successivamente progettati. 3. Progettazione dell algoritmo. Nel contesto del problema assegnato e della sua analisi, illustrare e motivare le principali scelte di progetto (rappresentazione degli input e degli output, idea alla base della soluzione, strutture dati utilizzate, ecc.) e riportare i principali passi con eventuali raffinamenti dell algoritmo creato per risolvere il problema, astraendo dalle caratteristiche del linguaggio ANSI C (i passi dell algoritmo non debbono assolutamente essere scritti in ANSI C). 4. Implementazione dell algoritmo. Completare e tradurre l algoritmo in linguaggio ANSI C, includendo nella relazione tutti i file.c e.h sviluppati, come pure il makefile. 5. Testing del programma. Effettuare almeno 10 test significativi di esecuzione completa del programma (si ricorda che la compilazione non fa parte dell esecuzione), riportando fedelmente per ciascun test sia i dati di input introdotti da tastiera/file che i risultati prodotti su schermo/file (nel caso di sviluppo di una libreria, è necessario scrivere un programma di test che include la libreria ed usa le sue funzioni). 6. Verifica del programma. Scegliere all interno del programma una sequenza di almeno tre istruzioni non di input/output la cui postcondizione non sia banalmente una tautologia e verificarne formalmente la correttezza mediante triple di Hoare. c 2015 Marco Bernardo 8/10

9 00.05 Software development Software development The software that has been developed (to be included in the fourth section of the report) should be: Readable: Equipped with adequate comments that recall the phases of analysis and design. Equipped with a comment for each function, formal parameter, and local variable. Free of design choices not described/motivated in the third section of the report. Free of identifiers that are not homogeneous or do not recall what they represent. Free of global variables. Indented (also avoid lines that wrap in the report because they are too long). Equipped with suitable spacing characters for functions and operators. Articulated in functions (avoid code redundancy). Consistent with the principles of structured programming: Free of goto statements. Free of exit statements. Free of continue statements. Free of break statements not occurring at the end of a case of a switch. Free of multiple return statements occurring in the body of the same function. Portable (avoid references to non-standard libraries or specific character encodings). Compilable through gcc with options: -ansi (compliance with the ANSI standard) -Wall (for catching all the warnings) in a way that neither error messages nor warnings are raised. Working correctly with respect to the assigned problem, without any limitation that can be overcome through dynamic memory allocation, and including tight input validation. c 2015 Marco Bernardo 9/10

10 00.05 Software development Il software sviluppato (da includere nella quarta sezione della relazione) deve essere: Leggibile: Dotato di opportuni commenti che richiamano le fasi di analisi e progettazione. Dotato di un commento per ogni funzione, parametro formale e variabile locale. Privo di scelte di progetto non descritte/motivate nella terza sezione della relazione. Privo di identificatori disomogenei o non evocativi di ciò che rappresentano. Privo di variabili globali. Indentato (evitare anche linee troppo lunghe che vanno a capo nella relazione). Dotato di appropriate spaziature per funzioni e operatori. Articolato in funzioni (evitare ridondanze di codice). Coerente coi principii della programmazione strutturata: Privo di istruzioni goto. Privo di istruzioni exit. Privo di istruzioni continue. Privo di istruzioni break che non si trovano alla fine di un case di uno switch. Privo di molteplici istruzioni return nel corpo della stessa funzione. Portabile (evitare riferimenti a librerie non standard o specifiche codifiche dei caratteri). Compilabile tramite gcc con opzioni: -ansi (conformità allo standard ANSI) -Wall (rilevazione di tutti i warning) senza che vengano segnalati errori o warning. Funzionante correttamente rispetto al problema assegnato, senza alcuna limitazione che sia superabile con l allocazione dinamica della memoria, nonché comprensivo della validazione stretta degli input. c 2015 Marco Bernardo 10/10