Analisi e progettazione del software

Anno accademico 2016-2017

(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)

Prof. Luca Cabibbo


Avvisi

(E' disponibile anche un elenco completo degli avvisi.)


Sono state effettuate delle verbalizzazioni relative all'appello dell'11 settembre 2017.

Tutti gli studenti (compresi quelli che si sono ritirati dall'esame) sono invitati a:

  1. consultare il portale dello studente per verificare che il voto sia stato registrato correttamente - in caso di problemi contattare il docente per posta elettronica
  2. in caso di buon esito della registrazione, trascrivere il voto registrato sul proprio libretto o sul proprio statino, insieme alla data dell'esame (11 settembre 2017, in questo caso) - la firma del docente sul libretto o sullo statino non è necessaria

Risultati dell'esame di Analisi e progettazione del software dell' 11 settembre 2017:

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 dell'11 settembre si terranno nella seguente data:

Gli studenti che non possono sostenere l'esame orale in tale data sono invitati a contattare il docente, per posta elettronica, al più presto.

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, 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.
Perché? Per sapere chi e quanti siete. Per conoscere i vostri indirizzi di posta elettronica, nel caso dovessi contattarvi. Perché la registrazione è necessaria per partecipare alle prove in itinere. Perché la registrazione è necessaria per sostenere l'esame con progetto.

Gli studenti Erasmus, invece, sono invitati a leggere queste informazioni, e a registrarsi al corso usando quest'altro  modulo di registrazione.


Le lezioni del corso di Analisi e progettazione del software si svolgeranno:

In pratica, le lezioni del corso di Analisi e progettazione del software inizieranno normalmente alle ore 10:15 (puntuali!). Si raccomanda la massima puntualità anche da parte degli studenti.

Dunque, il corso avrà inizio mercoledì 1 marzo alle ore 10:15 in aula N11


Introduzione al corso

Obiettivo formativo

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

Contenuti

Prerequisiti

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.


Lezioni

(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

Argomenti delle lezioni svolte 

Data Argomento
(anche con riferimento ai capitoli e alle sezioni del libro di testo)
Lucidi
(non sostituiscono il libro)

1 marzo 2017

*. Introduzione al corso di Analisi e progettazione del software

aps00

  1. Introduzione all'analisi e alla progettazione orientata agli oggetti (Capitolo 1)

aps01

2 marzo 2017

2. Sviluppo iterativo ed evolutivo ed agile (Capitolo 2, da 2.1 a 2.9)

aps02

 

3. Agile (Capitolo 3)

aps03

  4. Studi di caso (Capitolo 4)

aps04

 

 

6 marzo 2017 * Dalla progettazione concettuale alla modellazione di dominio aps91
  Esercitazione: Modellazione di dominio: VideoRental (requisiti, pagine 1 e 2, più pagina 3 (solo esercizio A1))  

8 marzo 2017

5. Ideazione (Capitolo 5, cenni)  
  6. Requisiti evolutivi (Capitolo 6) aps06
  7. Casi d'uso (Capitolo 7, da 7.1 a 7.8) aps07

9 marzo 2017

7. Casi d'uso (Capitolo 7, da 7.9 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

 

13 marzo 2017 10. Iterazione 1: Concetti fondamentali (Capitolo 10, cenni)  
  * Alcune idee sui sistemi software e la loro architettura aps92
  11. Verso l'analisi a oggetti aps11
  12. Modellazione di dominio (Cap.12, da 12.1 a 12.3) aps12 (solo lucidi aggiuntivi)

15 marzo 2017

12. Modellazione di dominio (Cap. 12, da 12.3 a 12.13)  

16 marzo 2017

12. Modellazione di dominio (Cap.12, da 12.14 a 12.15)  

 

20 marzo 2017

12. Modellazione di dominio (Cap.12, da 12.16 a 12.22)  
  13. Operazioni di sistema e diagrammi di sequenza di sistema (Cap. 13) aps13 (solo lucidi aggiuntivi)
22 marzo 2017 13. Operazioni di sistema e diagrammi di sequenza di sistema (Cap. 13)  

 

14. Contratti delle operazioni di sistema (Cap. 14) aps14 (solo lucidi aggiuntivi)
23 marzo 2017 Esercitazione OOA: ERedit (requisiti), modellazione di dominio, operazioni di sistema, contratti delle operazioni per nuovoDiagramma, nuovaEntità  

 

27 marzo 2017 Esercitazione OOA: ERedit (requisiti), contratto delle operazioni per nuovoAttributo  
  15. Dai requisiti alla progettazione, iterativamente (Cap. 15)  
  16. Architettura logica (Cap. 16) aps16 (solo lucidi aggiuntivi)

29 marzo 2017

non ci sarà lezione

 

30 marzo 2017 17. Verso la progettazione a oggetti (Cap. 17)  
  19. Diagrammi delle classi (Cap. 19) aps19 (solo lucidi aggiuntivi)
  18. Diagrammi di interazione (Cap. 18, da 18.1 a 18.2) aps18 (solo lucidi aggiuntivi)

 

3 aprile 2017 Esercitazione OOA: Acme PlayMusic (requisiti, esercizi su modellazione di dominio)  
5 aprile 2017 18. Diagrammi di interazione (Cap. 18, da 18.2 a 18.6)  
  20. GRASP: Progettazione di oggetti con responsabilità (Cap. 20, da 20.1 a 20.2) aps20a (solo lucidi aggiuntivi)
6 aprile 2017 20. GRASP: Progettazione di oggetti con responsabilità (Cap. 20, da 20.3 a 20.8)  

 

10 aprile 2017 Esercitazione OOA: Acme PlayMusic (requisiti, esercizi su operazioni di sistema)  
12 aprile 2017 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)

13 aprile 2017

non ci sarà lezione

 

 

 

14-18 aprile 2017 Vacanze di Pasqua  

 

19 aprile 2017 Esercitazione OOA: Acme PlayMusic (requisiti, esercizi su operazioni di sistema)  
  21. Esempi di progettazione a oggetti con i pattern GRASP (Cap. 21, paragrafo 21.4, fino a getTotal)  
  22. Progettare per la visibilità (Cap. 22) aps22 (solo lucidi aggiuntivi)

20 aprile 2017

21. Esempi di progettazione a oggetti con i pattern GRASP (Cap. 21, paragrafo 21.4, da getTotal alla fine del paragrafo)  
  23. Trasformare i progetti in codice (Cap. 23, da 23.1 a 23.12) aps23a (solo lucidi aggiuntivi)
     

24 aprile 2017

non ci sarà lezione

 

26 aprile 2017 Esercitazione OOD: ERedit (requisiti): nuovoDiagramma, nuovaEntità, nuovoAttributo  
27 aprile 2017 Esercitazione OOD: ERedit (requisiti): nuovaRelazione, cancellaRelazione  

 

20. GRASP: Progettazione di oggetti con responsabilità (Cap. 20, da 20.9 a 20.13) aps20b (solo lucidi aggiuntivi)
     

3 maggio 2017

20. GRASP: Progettazione di oggetti con responsabilità (Cap. 20, 20.13 e 20.14)  
  21. Esempi di progettazione a oggetti con i pattern GRASP (Cap. 21, 21.5) aps21b (solo lucidi aggiuntivi)
  23. Trasformare i progetti in codice (Paragrafo 23.13) aps23b
4 maggio 2017 Esercitazione OOD: Acme PlayMusic (requisiti, esercizi di progettazione)  
     

8 maggio 2017

non ci sarà lezione

 

10 maggio 2017 24. Sviluppo guidato dai test e Refactoring (Cap. 24, paragrafo 24.1) 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.9) aps34 (solo lucidi aggiuntivi)
11 maggio 2017 34. Raffinamento del modello di dominio (Cap. 34, da 34.10 e 34.14)  
  35. Altri SSD e contratti (Cap. 35)  
  28. GRASP: altri oggetti con responsabilità (Cap. 28, 28.1 e 28.2) aps28 (solo lucidi aggiuntivi)
     
15 maggio 2017 Prima prova intermedia  
17 maggio 2017 28. GRASP: altri oggetti con responsabilità (Cap. 28, da 28.2 a 28.4)  
  29. Applicare i design pattern GoF: introduzione, Adapter e Factory (Cap. 29, da 29.1 a 29.4) aps29a (solo lucidi aggiuntivi)

18 maggio 2017

non ci sarà lezione

 

 

 

22 maggio 2017 29. Applicare i design pattern GoF: Singleton, conclusione sul problema dei servizi esterni (Cap. 29, 29.5, 29.6 e 29.11)  
  29. Applicare i design pattern GoF: Strategy, Facade, Observer (Cap. 29, 29.7, 29.9 e 29.10) aps29b (solo lucidi aggiuntivi)
24 maggio 2017 37. Raffinamento dell'architettura logica: collaborazioni tra strati (Cap. 37, 37.2 e 37.4)  

 

39. Ulteriore progettazione a oggetti con i pattern GoF: Repository e Template Method (Cap. 39, 39.2, 39.10, 39.11 e 39.12)

aps39a (solo lucidi aggiuntivi)

25 maggio 2017 Esercitazione OOA/D: AcmePayroll (requisiti, esercizi di analisi e progettazione)  

 

 

  le lezioni del corso sono terminate  

 

8 giugno 2017 Seconda prova intermedia  

 

 

   

 

 

 

   

 

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)

aps95

29 maggio 2015

Ricevimento studenti in aula

 

 

1 giugno 2015 non ci sarà lezione  
3 giugno 2015 Prova intermedia:  
5 giugno 2015 non ci sarà lezione  

 

 

8 giugno 2015 non ci sarà lezione  
10 giugno 2015 non ci sarà lezione  
12 giugno 2015 non ci sarà lezione  

 

 

  Esercitazione OOA/D:  

 

* SOLID: Altri principi di progettazione a oggetti (cenni)

aps94

 

 

 


Prove in itinere e homework

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 AcmePlayMusic: Analisi - Modellazione di dominio AcmePlayMusic 20 marzo 2017 entro la mezzanotte di
sabato 1 aprile
subito prima dell'inizio della lezione di
lunedì 3 aprile
2 AcmePlayMusic: Analisi - Operazioni di sistema AcmePlayMusic 27 marzo 2017 entro la mezzanotte di
venerdì 7 aprile
subito prima dell'inizio della lezione di
lunedì 10 aprile
3 AcmePlayMusic: Progettazione - Caso d'uso UC1 AcmePlayMusic 26 aprile 2017 entro la mezzanotte di
mercoledì 3 maggio
subito prima dell'inizio della lezione di
giovedì 4 maggio
4          
5 Acme Payroll: Analisi e progettazione Acme Payroll 22 maggio 2017 non va consegnato non va consegnato
           

Uno studente potrà consegnare le proprie soluzioni degli homework, scritte a mano 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 (ordinamento 270)

Programma preliminare del corso di Analisi e progettazione del software per gli studenti dell'ordinamento 270, per l'anno accademico 2016-2017 – 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:


Programma (ordinamento 509)

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:


Materiale didattico

Libro di testo

In alternativa, anche se meno consigliato, è possibile utilizzare la terza edizione del libro:

Errata corrige: figura 6.1 di pag. 66 e figura 6.4 di pagina 97

Oppure la versione originale in inglese della terza edizione del libro:

Ulteriori libri, utili per la consultazione (in ordine sparso)

Sito web del corso

Studi di caso 

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:


Esami (ordinamento 270)

Modalità d'esame relativa agli appelli ordinari di Analisi e progettazione del software per gli studenti dell'ordinamento 270: 

Esame con progetto

Esame senza progetto

Esame con prove in itinere

Appelli straordinari

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.


Esami (ordinamento 509)

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: 

Esame con progetto

Esame senza progetto

Esame con prove in itinere

Appelli straordinari

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.


Date d'esame

Nell'anno accademico 2016-2017 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.


Testi di prove d'esame di appelli conclusi

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)


Informazioni per studenti Erasmus

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.