Procedural and logic programming
00.01 General information about the exam
applied computer science
urbino worldwide campus
How the exam takes place
00.01 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
Procedural and logic programming
00.01 General information about the exam
applied computer science
urbino worldwide campus
• 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
Procedural and logic programming
00.02 General information about the project
applied computer science
urbino worldwide campus
00.02 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
Procedural and logic programming
00.02 General information about the project
applied computer science
urbino worldwide campus
• 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
Procedural and logic programming
00.03 Project submission
applied computer science
urbino worldwide campus
00.03 Project submission
• The project must be submitted to [email protected] 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 e-mail must be “PLPr project submission” for on-line students and
“consegna progetto PPL” for face-to-face students.
• The body of the e-mail must contain the names, the serial numbers, and the year of enrollment
(first, second, third, other) of the developers.
• The e-mail 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 e-mail 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
Procedural and logic programming
00.03 Project submission
applied computer science
urbino worldwide campus
• Il progetto deve essere consegnato a [email protected] 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 e-mail deve essere “consegna progetto PPL” per gli studenti in presenza e
“PLPr project submission” per gli studenti on-line.
• Il corpo della e-mail deve contenere i nominativi, i numeri di matricola e l’anno di corso
(primo, secondo, terzo, fuori corso) degli sviluppatori.
• L’e-mail 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 e-mail 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
Procedural and logic programming
00.04 Report preparation
applied computer science
urbino worldwide campus
00.04 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
Procedural and logic programming
00.04 Report preparation
applied computer science
urbino worldwide campus
• 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
Procedural and logic programming
00.05 Software development
applied computer science
urbino worldwide campus
00.05 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
Free
Free
Free
Free
of
of
of
of
of
goto statements.
exit statements.
continue statements.
break statements not occurring at the end of a case of a switch.
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
Procedural and logic programming
00.05 Software development
applied computer science
urbino worldwide campus
• 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
Privo
Privo
Privo
Privo
di
di
di
di
di
istruzioni goto.
istruzioni exit.
istruzioni continue.
istruzioni break che non si trovano alla fine di un case di uno switch.
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