(Attenzione, alcune delle informazioni su questo sito web, ed in particolare quelle scritte in grigio e/o su sfondo giallo, potrebbero riferirsi all'edizione precedente del corso di Analisi e progettazione del software)
(E' disponibile anche un elenco completo degli avvisi.)
Risultati dell'esame di Analisi e progettazione del software del 19 settembre 2019:
La prova scritta potrà essere visionata esclusivamente durante l'orario di ricevimento studenti, e comunque entro trenta giorni dalla pubblicazione di questo avviso.
Gli orali relativi all'appello del 19 settembre si terranno nelle seguenti date:
Gli studenti che devono sostenere la prova orale sono invitati a contattare il docente, per posta elettronica, al più presto, per concordare in quale data sostenere l'orale.
La verbalizzazione (ovvero, la registrazione) dell'esame (che viene svolta dal docente e non richiede la presenza degli studenti) avverrà con le seguenti modalità:
In caso di problemi contattare il docente, per posta elettronica, al più presto.
Le lezioni del corso di Analisi e progettazione del software sono terminate.
Gli studenti che intendono frequentare il corso di Analisi e progettazione del software in questo anno accademico, e in particolare quelli che intendono partecipare alle prove in itinere e quelli che intendono sostenere l'esame con progetto, sono invitati a registrarsi al corso usando l'apposito modulo di registrazione.
Gli studenti Erasmus, invece, sono invitati a leggere queste informazioni, e a registrarsi al corso usando quest'altro modulo di registrazione.
Dall'appello di giugno-luglio 2018, in via sperimentale, gli esercizi di progettazione potranno contenere alcuni "test di accettazione", che verranno utilizzati per la valutazione del progetto proposto, e che vanno interpretati come segue.
Intuitivamente, i test di accettazione sono degli scenari che descrivono la
responsabilità del sistema, durante l'esecuzione di un caso d'uso, di
raccogliere e memorizzare delle informazioni che saranno poi necessarie per
supportare la corretta esecuzione di altre operazioni di sistema di altri casi
d'uso.
Il progetto proposto dovrà pertanto assegnare tali responsabilità, in
modo tale che sia poi possibile progettare per queste altre operazioni di
sistema in modo semplice e
senza richiedere alcuna modifica del progetto proposto.
Per esempio, il progetto proposto sul libro di testo nel capitolo 21 relativamente al caso d'uso Elabora vendita soddisfa il seguente test di accettazione:
Viceversa, il progetto proposto sul libro di testo nel capitolo 21 relativamente al caso d'uso Elabora vendita NON soddisfa il seguente test di accettazione:
Infatti, in questo caso, è possibile supportare l'esecuzione
dell'operazione di sistema proposta, ma non in modo
semplice (sarebbe infatti necessario scandire tutte le vendite e
controllare se in ciascuna vendita è stato acquistato quell'articolo).
Sarebbe stato possibile supportare questa operazione in modo semplice se,
piuttosto, nella progettazione per il caso d'uso Elabora vendita
fosse stata realizzata anche una navigabilità dagli articoli (descrizioni
prodotto) alle vendite.
Si noti che la soluzione di un esercizio NON richiede di effettuare anche la progettazione per le altre operazioni di sistema di altri casi d'uso indicate tra i test di accettazione. Richiede solo di progettare per il caso d'uso di interesse in modo tale che sia poi possibile progettare per queste altre operazioni di sistema in modo semplice e senza richiedere alcuna modifica del progetto proposto.
Il corso di Analisi e progettazione del software presenta gli aspetti fondamentali della modellazione, analisi e progettazione del software, con riferimento alle tecniche di analisi e progettazione orientata agli oggetti ed allo sviluppo, iterativo, incrementale e agile.
Lo studente che abbia superato il corso dovrà essere in grado di progettare autonomamente applicazioni software di media complessità, nonché partecipare al progetto di applicazioni software di grande complessità.
Costituiscono un prerequisito fondamentale di questo corso i corsi di Basi di dati I e di Programmazione orientata agli oggetti. Prerequisiti specifici per il corso di Analisi e progettazione del software sono descritti in questo documento.
(Attenzione, alcune delle informazioni su questa parte del sito web, e in particolare quelle scritte in grigio e quelle dopo la riga gialla, potrebbero riferirsi all'edizione precedente del corso di Analisi e progettazione del software)
Legenda adottata nei lucidi
| Data | Argomento (anche con riferimento ai capitoli e alle sezioni del libro di testo) |
Lucidi (non sostituiscono il libro) |
|
|
||
|
4 marzo 2019 |
*. Introduzione al corso di Analisi e progettazione del software | |
| 1. Introduzione all'analisi e alla progettazione orientata agli oggetti (Capitolo 1) | ||
|
6 marzo 2019 |
2. Sviluppo iterativo ed evolutivo ed agile (Capitolo 2, da 2.1 a 2.9) | |
|
|
3. Agile (Capitolo 3) | |
| 7 marzo 2019 | 4. Studi di caso (Capitolo 4) | |
|
|
5. Ideazione (Capitolo 5, cenni) | |
| 6. Requisiti evolutivi (Capitolo 6) | aps06 | |
| 7. Casi d'uso (Capitolo 7, da 7.1 a 7.8) | aps07 | |
|
|
||
|
11 marzo 2019 |
non ci sarà lezione |
|
|
13 marzo 2019 |
7. Casi d'uso (Capitolo 7, da 7.8 a 7.13, 7.17, da 7.20 a 7.22) | |
| 8. Altri requisiti (Capitolo 8, cenni) | ||
| 9. Storie utente (Capitolo 9, da 9.1 a 9.3, 9.8) | aps09 | |
| 10. Iterazione 1: Concetti fondamentali (Capitolo 10, cenni) | ||
| 14 marzo 2019 | * Alcune idee sui sistemi software e la loro architettura | aps92 |
| 11. Verso l'analisi a oggetti | aps11 | |
| * Dalla progettazione concettuale alla modellazione di dominio | aps91 | |
| 12. Modellazione di dominio (Cap.12, da 12.1 a 12.2) | aps12 (solo lucidi aggiuntivi) | |
|
|
||
|
18 marzo 2019 |
non ci sarà lezione |
|
|
20 marzo 2019 |
non ci sarà lezione |
|
|
21 marzo 2019 |
12. Modellazione di dominio (Cap. 12, da 12.2 a 12.6, nonché 12.20) | |
|
|
||
|
25 marzo 2019 |
12. Modellazione di dominio (Cap.12, da 12.7 a 12.15) | |
|
27 marzo 2019 |
12. Modellazione di dominio (Cap.12, da 12.15 a 12.22) | |
|
28 marzo 2019 (3 ore) |
Esercitazione OOA: ERedit (requisiti), modellazione di dominio | |
| 13. Operazioni di sistema e diagrammi di sequenza di sistema (Cap. 13) | aps13 (solo lucidi aggiuntivi) | |
|
|
14. Contratti delle operazioni di sistema (Cap. 14) | aps14 (solo lucidi aggiuntivi) |
|
|
||
|
1 aprile 2019 |
non ci sarà lezione |
|
|
3 aprile 2019 |
non ci sarà lezione |
|
|
4 aprile 2019 (in aula N10) |
14. Contratti delle operazioni di sistema (Cap. 14) | |
| 15. Dai requisiti alla progettazione, iterativamente (Cap. 15) | ||
|
|
||
| 8 aprile 2019 | Esercitazione OOA: Acme Eat (requisiti, esercizi su modellazione di dominio) | |
| 10 aprile 2019 | Esercitazione OOA: ERedit (requisiti), operazioni di sistema, contratti delle operazioni per loginUtente, nuovoDiagramma, apriDiagramma, nuovaEntità, nuovaRelazione | |
| 16. Architettura logica (Cap. 16) | aps16 (solo lucidi aggiuntivi) | |
| 11 aprile 2019 | 16. Architettura logica (Cap. 16) | |
| 17. Verso la progettazione a oggetti (Cap. 17) | ||
| 19. Diagrammi delle classi (Cap. 19, da 19.1 a 19.4) | aps19 (solo lucidi aggiuntivi) | |
|
|
||
|
15 aprile 2019 |
non ci sarà lezione, ma verrà recuperata martedì 16 aprile dalle 14:00 alle 16:00 in aula N15 (Via della Vasca Navale 109) |
|
|
16 aprile 2019 (ore 14:15, aula N15) |
18. Diagrammi di interazione (Cap. 18, da 18.1 a 18.4) | aps18 (solo lucidi aggiuntivi) |
|
17 aprile 2019 |
non ci sarà lezione |
|
| 18 aprile 2019 | Esercitazione OOA: Acme Eat (requisiti, esercizi su operazioni di sistema) | |
| Esercitazione OOA: ERedit (requisiti), contratti delle operazioni per nuovoAttributo e cancellaAttributo | ||
|
|
||
| 19-28 aprile 2019 | Vacanze di Pasqua e ponte di primavera | |
|
|
||
|
29 aprile 2019 |
non ci sarà lezione |
|
|
1 maggio 2019 |
Festa del lavoro |
|
| 2 maggio 2019 | 19. Diagrammi delle classi (Cap. 19, paragrafo 19.19) | |
| 20. GRASP: Progettazione di oggetti con responsabilità (Cap. 20, da 20.1 a 20.8) | aps20a (solo lucidi aggiuntivi) | |
|
3 maggio 2019 (ore 10:15, aula N16) |
21. Esempi di progettazione a oggetti con i pattern GRASP (Cap. 21, da 21.1 a 21.4, fino a enterItem) | aps21a (solo lucidi aggiuntivi) |
|
|
||
| 6 maggio 2019 | 21. Esempi di progettazione a oggetti con i pattern GRASP (Cap. 21, paragrafo 21.4, enterItem) | |
| 22. Progettare per la visibilità (Cap. 22) | aps22 (solo lucidi aggiuntivi) | |
|
8 maggio 2019 |
21. Esempi di progettazione a oggetti con i pattern GRASP (Cap. 21, paragrafo 21.4, da getTotal alla fine del paragrafo) | |
| 9 maggio 2019 | 23. Trasformare i progetti in codice (Cap. 23, da 23.1 a 23.12) | aps23a (solo lucidi aggiuntivi) |
| Esercitazione OOD: ERedit (requisiti): loginUtente | ||
|
|
||
|
13 maggio 2019 |
non ci sarà lezione, ma verrà recuperata martedì 14 maggio dalle 14:00 alle 16:00 in aula N15 (Via della Vasca Navale 109) |
|
|
14 maggio 2019 (ore 14:15, aula N15) |
Esercitazione OOD: ERedit (requisiti): caricaDiagramma, nuovoDiagramma, nuovaEntità, nuovoAttributo | |
|
15 maggio 2019 |
non ci sarà lezione, ma verrà recuperata venerdì 17 maggio dalle 10:00 alle 12:00 in aula N16 (Via della Vasca Navale 109) |
|
| 16 maggio 2019 | Esercitazione OOD: ERedit (requisiti): nuovaRelazione | |
|
|
20. GRASP: Progettazione di oggetti con responsabilità (Cap. 20, da 20.9 a 20.11, introduzione ad accoppiamento e coesione) | aps20b (solo lucidi aggiuntivi) |
|
17 maggio 2019 |
20. GRASP: Progettazione di oggetti con responsabilità (Cap. 20, introduzione ad accoppiamento e coesione, da 20.12 a 20.13) | |
|
|
||
| 20 maggio 2019 | Esercitazione OOD: Acme Eat (requisiti, esercizi di progettazione orientata agli oggetti) | |
| 22 maggio 2019 | Esercitazione OOD: Acme Eat (requisiti, esercizi di progettazione orientata agli oggetti) | |
| 20. GRASP: Progettazione di oggetti con responsabilità (Cap. 20, 20.14) | ||
| 21. Esempi di progettazione a oggetti con i pattern GRASP (Cap. 21, 21.5) | aps21b (solo lucidi aggiuntivi) | |
|
23 maggio 2019 |
non ci sarà lezione, ma verrà recuperata venerdì 24 maggio dalle 10:00 alle 12:00 in aula N16 (Via della Vasca Navale 109) |
|
| 24 maggio 2019 | 21. Esempi di progettazione a oggetti con i pattern GRASP (Cap. 21, 21.5) | |
| 23. Trasformare i progetti in codice (Paragrafo 23.13) | aps23b | |
| 24. Sviluppo guidato dai test e Refactoring (Cap. 24, cenni) | aps24 (solo lucidi aggiuntivi) | |
| 26. Iterazione 2: Altri pattern (Cap. 26) | aps26 | |
| 27. Rapido aggiornamento dell'analisi (e del progetto) (Cap. 27) | aps27 (solo lucidi aggiuntivi) | |
| 34. Raffinamento del modello di dominio (Cap. 34, da 34.1 a 34.2) | aps34 (solo lucidi aggiuntivi) | |
|
|
||
|
27 maggio 2019 |
non ci sarà lezione, ma verrà recuperata martedì 28 maggio dalle 14:00 alle 16:00 in aula N15 (Via della Vasca Navale 109) |
|
|
28 maggio 2019 (ore 14:15, aula N15) |
34. Raffinamento del modello di dominio (Cap. 34, da 34.3 a 34.14) | |
|
29 maggio 2019 |
non ci sarà lezione, ma verrà recuperata venerdì 31 maggio dalle 10:00 alle 12:00 in aula N16 (Via della Vasca Navale 109) |
|
| 30 maggio 2019 | Prima prova intermedia | |
|
31 maggio 2019 (ore 10:15, aula N16) |
34. Raffinamento del modello di dominio (Cap. 34, 34.17) | |
| 35. Altri SSD e contratti (Cap. 35, cenni) | ||
| 28. GRASP: altri oggetti con responsabilità (Cap. 28, da 28.1 a 28.2) | aps28 (solo lucidi aggiuntivi) | |
|
|
||
| 3 giugno 2019 | 28. GRASP: altri oggetti con responsabilità (Cap. 28, da 28.3 a 28.4) | |
| 29. Applicare i design pattern GoF: introduzione, Adapter, Factory, Singleton e conclusione sul problema dei servizi esterni (Cap. 29, da 29.1 a 29.6 e 29.11, cenni) | aps29a (solo lucidi aggiuntivi) | |
| 5 giugno 2019 | 29. Applicare i design pattern GoF: Strategy, Facade, Observer (Cap. 29, 29.7 (in dettaglio), 29.9 (cenni) e 29.10 (cenni) | aps29b (solo lucidi aggiuntivi) |
| 37. Raffinamento dell'architettura logica: collaborazioni tra strati (Cap. 37, 37.2 e 37.4, cenni) | ||
|
|
39. Ulteriore progettazione a oggetti con i pattern GoF: Repository e Template Method (Cap. 39, 39.2 (cenni), 39.10 (in dettaglio), 39.11 (cenni) e 39.12 (cenni)) | |
| 6 giugno 2019 | Esercitazione OOA/D: AcmePayroll (requisiti, esercizi di analisi e progettazione) | |
|
|
||
| le lezioni del corso sono terminate | ||
|
|
||
| 13 giugno 2019 | Seconda prova intermedia | |
|
|
||
|
|
||
| In questa tabella, tutto ciò che segue questa riga si riferisce all'anno accademico precedente |
|
|
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
25 maggio 2015 |
Seminario congiunto relativo ai corsi di APS e SIW su Fhoster: Information Systems on Demand |
|
|
27 maggio 2015 |
* Introduzione alla gestione della persistenza e della concorrenza (cenni) | |
|
|
||
| Esercitazione OOA/D: | ||
|
|
* SOLID: Altri principi di progettazione a oggetti (cenni) | |
|
|
In preparazione.
Per ciascuna prova in itinere o homework, i requisiti sono descritti in un documento diverso da quello contenente gli esercizi della prova in itinere o homework.
| Homework | Requisiti | Data pubblicazione | Consegna elettronica | Consegna cartacea | |
|---|---|---|---|---|---|
| 1 | Acme Eat: Analisi - Modellazione di dominio | Acme Eat | 28 marzo 2019 |
entro la mezzanotte di domenica 7 aprile |
subito prima dell'inizio della lezione di lunedì 8 aprile |
| 2 | Acme Eat: Analisi - Operazioni di sistema | Acme Eat | 8 aprile 2019 |
entro la mezzanotte di martedì 16 aprile mercoledì 17 aprile |
subito prima dell'inizio della lezione di mercoledì 17 aprile giovedì 18 aprile |
| 3 | Acme Eat: Progettazione - Caso d'uso UC1 | Acme Eat | 9 maggio 2019 |
entro la mezzanotte di domenica 19 maggio |
subito prima dell'inizio della lezione di lunedì 20 maggio |
| 4 | Acme Payroll: Analisi e progettazione | Acme Payroll | 31 maggio 2019 | non va consegnato | non va consegnato |
Uno studente potrà consegnare le proprie soluzioni degli homework, scritte a mano su carta e realizzate individualmente, come segue:
Saranno accettate e corrette solo soluzioni puntuali e che comprendono sia la consegna cartacea che quella elettronica. Invece, consegne ritardatarie oppure solo cartacee oppure solo elettroniche non verranno prese in considerazione.
Inoltre:
Un'ulteriore precisazione: la frase "entro la mezzanotte del giorno X" vuol dire "entro la mezzanotte tra il giorno X e il giorno successivo a X"; dunque, il giorno X è un giorno valido per effettuare la consegna.
Programma definitivo del corso di Analisi e progettazione del software per gli studenti dell'ordinamento 270, per l'anno accademico 2018-2019 – l'indicazione dei capitoli fa riferimento all'edizione italiana del 2016 del libro di testo Applicare UML e i pattern
I concetti introdotti durante il corso sono esemplificati con riferimento ai seguenti studi di caso, che sono parte integrante del programma d'esame:
Il programma definitivo del corso di Analisi e progettazione del software per gli studenti dell'ordinamento 509 è quello dell'anno accademico 2009-2010 – l'indicazione dei capitoli fa riferimento all'edizione italiana del 2005 del libro di testo Applicare UML e i pattern
I concetti introdotti durante il corso sono esemplificati con riferimento ai seguenti studi di caso, che sono parte integrante del programma d'esame:
In alternativa, anche se meno consigliato, è possibile utilizzare la terza edizione del libro:
Oppure la versione originale in inglese della terza edizione del libro:
I concetti introdotti durante il corso sono esemplificati con riferimento ai seguenti studi di caso, che sono parte integrante del programma d'esame:
Ulteriori studi di caso che possono essere utilizzati nel corso:
Modalità d'esame relativa agli appelli ordinari di Analisi e progettazione del software per gli studenti dell'ordinamento 270:
In caso di appelli straordinari, la modalità d'esame di Analisi e progettazione del software potrà, a secondo delle circostanze, essere diversa. Ad esempio, solo esame scritto, solo esame orale, oppure progetto e esame orale, oppure progetto e esame scritto. Contattare il docente per chiarimenti.
E' necessaria una precisazione importante per gli studenti
dell'ordinamento 509.
Normalmente,
questi studenti devono sostenere l'esame di Analisi e progettazione del software
per studenti 509 da 5 cfu.
Tuttavia, studenti dell'ordinamento 509 che avessero inserito l'esame di Analisi
e progettazione del software nel loro piano di studi dall'anno accademico
2010-2011 in poi, devono invece probabilmente
sostenere l'esame di Analisi e progettazione del software per studenti 270 da 6
cfu.
Nel dubbio, contattare il docente con opportuno anticipo rispetto alle date
d'esame.
La modalità d'esame relativa agli appelli ordinari di Analisi e progettazione del software per gli studenti dell'ordinamento 509 è quella dell'anno accademico 2009-2010, come segue:
In caso di appelli straordinari, la modalità d'esame di Analisi e progettazione del software potrà, a secondo delle circostanze, essere diversa. Ad esempio, solo esame scritto, solo esame orale, oppure progetto e esame orale, oppure progetto e esame scritto. Contattare il docente per chiarimenti.
Nell'anno accademico 2018-2019 sono previste le seguenti date d'esame (attenzione, potrebbero ancora cambiare):
Per partecipare agli esami è necessario prenotarsi ad esso presso il portale dello studente GOMP (gli studenti dell'ordinamento 270 al corso di codice 20801962, gli studenti dell'ordinamento 509 che devono sostenere l'esame da 5 cfu al corso di codice 20801503, gli studenti dell'ordinamento 509 che devono sostenere l'esame da 6 cfu al corso di codice 20801962). La prenotazione va normalmente fatta entro quattro giorni lavorativi prima della data dell'appello (che corrispondono a circa una settimana effettiva).
Chi avesse problemi a prenotarsi presso il sito delle prenotazioni è invitato caldamente a contattare il docente per posta elettronica entro gli stessi termini.
Per motivi organizzativi, gli studenti non prenotati che comunque non contatteranno il docente entro 24 ore dall'esame non saranno ammessi all'esame stesso.
Dell'anno accademico 2011-2012
Dell'anno accademico 2008-2009
Dell'anno accademico 2006-2007
Dell'anno accademico 2005-2006 (la modalità d'esame potrebbe essere diversa da quella prevista per questo anno accademico)
Dell'anno accademico 2004-2005 (la modalità d'esame potrebbe essere diversa da quella prevista per questo anno accademico)
Dell'anno accademico 2003-2004 (la modalità d'esame potrebbe essere diversa da quella prevista per questo anno accademico)
Dell'anno accademico 2002-2003 (con le stesse modalità dell'anno accademico 2003-2004, ma con un programma leggermente diverso, e un livello di approfondimento minore per alcuni degli argomenti trattati)
In passato, si sono verificate delle
situazioni spiacevoli con alcuni studenti Erasmus.
(Ci tengo a sottolineare il fatto che ciò è avvenuto solo con alcuni
studenti Erasmus: altri studenti Erasmus si sono comportati correttamente, ed
hanno studiato in modo assolutamente dignitoso).
A causa di tali avvenimenti, gli studenti Erasmus interessati a frequentare e sostenere l'esame di Analisi e progettazione del software devono:
Si ricorda inoltre che al corso di Analisi e progettazione del software sono attribuiti 6 CFU (crediti formativi universitari), e che pertanto l'impegno richiesto ad uno studente in possesso dei prerequisiti del corso è di circa 6x25=150 ore.
Il docente sottolinea che finora ha trattato - e continuerà a trattare - gli
studenti Erasmus allo stesso modo - dunque, né meglio né peggio - degli
studenti locali.
In particolare (anche se non ci dovrebbe essere bisogno di dirlo) uno studente
Erasmus che studia bene la materia verrà promosso all'esame, mentre uno studente
Erasmus che studia poco o studia male la materia verrà bocciato all'esame -
esattamente come verrebbe bocciato all'esame uno studente locale che studia poco
o studia male. Questo indipendentemente da qualunque fatto o situazione che non
riguarda strettamente lo studio e la comprensione della materia. E con l'ovvia
considerazione che decidere se uno studente ha studiato bene o male è
responsabilità della commissione d'esame - e non dello studente.
En pasado, se han verificado unas situaciones desagradables con unos
estudiantes Erasmus.
(Quiero acentuar que esto ha pasado solo con unos estudiantes Erasmus:
otros estudiantes se han comportado correctamente y han siempre estudiado de una
manera absolutamente decente.)
Por esos eventos, los estudiantes Erasmus que son interesados a frecuentar y dar el examen de Analisi e progettazione del software tienen que:
Se recuerda tambien que al curso de Analisi e progettazione del software se dan 6 CFU (crediti formativi universitari), y que entonces el empeño que se pide a un estudiante que ya posee los requisitos del curso es más o menos de 6x25=150 horas .
El profesor acentua que hasta ahora ha tratado – y seguirá tratando- los
estudiantes Erasmus de la misma manera – es decir ni mejor ni pejor –
de los estudiantes locales .
En particular, aunque no sea necesario decirlo, un estudiante Erasmus que
estudia bien la materia aprobará el examen, mientras un estudiante Erasmus que
estudia poco o mal la materia suspenderá el examen – de la misma manera de un
estudiante local que estudia poco o estudia mal. Eso independientemente de todos
los aspectos que no conciernen propiamente el estudio y la comprensión de la
materia. Y, por supuesto,considerando tambien que es la Comision de Examen que
decide si un estudiante ha estudiado poco o mal – y no el estudiante mismo.
