Analisi e progettazione del software

Anno accademico 2019-2020

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


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

La prova scritta potrà essere visionata nel ricevimento studenti, che in questo periodo avviene in modalità telematica su Teams, previo appuntamento da concordare per posta elettronica.
La prova scritta potrà essere visionata comunque entro trenta giorni dalla pubblicazione di questo avviso.

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.


Modalità di svolgimento degli esami di profitto del corso di Analisi e progettazione del software a seguito dell’emergenza sanitaria e fino al ripristino della situazione di normale attività accademica

L'esame di Analisi e progettazione del software si svolgerà normalmente come segue:

In caso di impedimenti comprovati o di situazioni straordinarie, si prega di contattare il docente al più presto.


Indicazioni importanti circa lo svolgimento delle prove intermedie e degli esami dell'Analisi e progettazione del software:

In caso di problemi, contattare il docente, per posta elettronica, al più presto.


Le videolezioni del corso sono temporaneamente disponibili sulle piattaforme Teams e Stream di ateneo.

Per accedere alle risorse del corso su Teams e su Stream, contattare il docente per posta elettronica.

In particolare, le videolezioni sono temporaneamente disponibili su Teams come segue:

In caso di problemi, contattare il docente al più presto, per posta elettronica.


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.


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 Numero lezione Argomento
(anche con riferimento ai capitoli e alle sezioni del libro di testo)
Lucidi
(non sostituiscono il libro)

2 marzo 2020

1 e 2 *. Introduzione al corso di Analisi e progettazione del software

aps00

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

aps01

3 marzo 2020

3 e 4 2. Sviluppo iterativo ed evolutivo ed agile (Capitolo 2, Introduzione, da 2.1 a 2.9)

aps02

 

  3. Agile (Capitolo 3)

aps03

4 marzo 2020

  non ci sarà lezione

 

   

 

9 marzo 2020 5 e 6 4. Studi di caso (Capitolo 4)

aps04

 

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

 10 marzo 2020

7 e 8 7. Casi d'uso (Capitolo 7, da 7.8 a 7.13, 7.17, 7.21 e 7.22)  
    8. Altri requisiti (Capitolo 8, cenni) aps08
    9. Storie utente (Capitolo 9, Introduzione, da 9.1 a 9.3, 9.8) aps09
11 marzo 2020 9 e 10 10. Iterazione 1: Concetti fondamentali (Capitolo 10, cenni) aps10
    * Alcune idee sui sistemi software e la loro architettura apsA
    11. Verso l'analisi a oggetti aps11
    * Dalla progettazione concettuale alla modellazione di dominio apsB

   

 

16 marzo 2020 11 e 12 12. Modellazione di dominio (Cap.12, da 12.1 a 12.9, nonché 12.20) aps12a (prima parte)

17 marzo 2020

13 e 14 12. Modellazione di dominio (Cap. 12, da 12.10 a 12.15) aps12b (seconda parte)

18 marzo 2020

15 e 16 12. Modellazione di dominio (Cap. 12, da 12.16 a 12.22)  

   

 

23 marzo 2020

  non ci sarà lezione

 

24 marzo 2020 17 e 18 Esercitazione OOA: ERedit (requisiti), modellazione di dominio (in diretta alle ore 14:30 sulla piattaforma Teams)  
25 marzo 2020 19 e 20 13. Operazioni di sistema e diagrammi di sequenza di sistema (Cap. 13) aps13

 

  14. Contratti delle operazioni di sistema (Cap. 14) aps14

   

 

30 marzo 2020 21 e 22 14. Contratti delle operazioni di sistema (Cap. 14)  
    15. Dai requisiti alla progettazione, iterativamente (Cap. 15)  
    17. Verso la progettazione a oggetti (Cap. 17) aps17
    19. Diagrammi delle classi (Cap. 19, da 19.1 a 19.7 e da 19.10 a 19.15) aps19
31 marzo 2020 23 e 24 Esercitazione OOA: DeliverEat (requisiti, esercizi su modellazione di dominio)  
1 aprile 2020 25 e 26 Esercitazione OOA: ERedit (requisiti), operazioni di sistema, contratti delle operazioni per loginUtente, nuovoDiagramma, apriDiagramma, nuovaEntità, nuovoAttributo, nuovaRelazione  

   

 

6 aprile 2020 27 e 28 18. Diagrammi di interazione (Cap. 18, da 18.1 a 18.4) aps18
    19. Diagrammi delle classi (Cap. 19, paragrafo 19.19)  
7 aprile 2020 29 e 30 Esercitazione OOA: DeliverEat (requisiti, esercizi su operazioni di sistema)  
    16. Architettura logica (Cap. 16) aps16

8 aprile 2020

  non ci sarà lezione

 

 

 

10-14 aprile 2020   Vacanze di Pasqua e ponte di primavera  

   

 

15 aprile 2020 31 e 32 20. GRASP: Progettazione di oggetti con responsabilità (Cap. 20, da 20.1 a 20.8) aps20a

   

 

20 aprile 2020 33 e 34 21. Esempi di progettazione a oggetti con i pattern GRASP (Cap. 21, da 21.1 a 21.4, fino a enterItem) aps21a
21 aprile 2020 35 e 36 21. Esempi di progettazione a oggetti con i pattern GRASP (Cap. 21, paragrafo 21.4, enterItem)  
    22. Progettare per la visibilità (Cap. 22) aps22

22 aprile 2020

37 e 38 21. Esempi di progettazione a oggetti con i pattern GRASP (Cap. 21, paragrafo 21.4, da getTotal alla fine del paragrafo)  

 

 

27 aprile 2020 39 23. Trasformare i progetti in codice (Cap. 23, da 23.1 a 23.12) aps23a
    * Retrospettiva sull'iterazione 1 apsC

28 aprile 2020

  non ci sarà lezione

 

29 aprile 2020

  non ci sarà lezione

 

30 aprile 2020 40 e 41 Esercitazione OOD: ERedit (requisiti): loginUtente, caricaDiagramma, nuovoDiagramma, nuovaEntità, nuovoAttributo  

   

 

4 maggio 2020

42 e 43 20. GRASP: Progettazione di oggetti con responsabilità (Cap. 20, da 20.9 a 20.11, introduzione ad accoppiamento e coesione, 20.12) aps20b
5 maggio 2020 44 e 45 Esercitazione OOD: ERedit (requisiti): nuovaRelazione  

 

  20. GRASP: Progettazione di oggetti con responsabilità (da 20.13 a 20.14)
6 maggio 2020 46 21. Esempi di progettazione a oggetti con i pattern GRASP (Cap. 21, 21.5) aps21b
    23. Trasformare i progetti in codice (Paragrafo 23.13) aps23b

   

 

11 maggio 2020 47 e 48 24. Sviluppo guidato dai test e Refactoring (Cap. 24, cenni) aps24
    26. Iterazione 2: Altri pattern (Cap. 26) aps26
    27. Rapido aggiornamento dell'analisi (e del progetto) (Cap. 27) aps27
    34. Ulteriore modellazione di dominio (Cap. 34, da 34.1 a 34.6) aps34
12 maggio 2020 49 34. Ulteriore modellazione di dominio (Cap. 34, da 34.7 a 34.11, 34.13 (cenni), 34.14 e 34.17) aps34

13 maggio 2020

  non ci sarà lezione

 

14 maggio 2020
dalle 9:30
50 e 51 Esercitazione OOD: DeliverEat (requisiti, esercizi su progettazione orientata agli oggetti)  

   

 

18 maggio 2020
dalle 10:00
52 e 53 Esercitazione OOD: DeliverEat (requisiti, esercizi su progettazione orientata agli oggetti)  
    35. Altri SSD e contratti (Cap. 35, cenni) aps35
    28. GRASP: altri oggetti con responsabilità (Capitolo 28, 28.1 e 28.2) aps28
19 maggio 2020 54 e 55 28. GRASP: altri oggetti con responsabilità (Capitolo 28, 28.3 e 28.4)  
    29. Applicare i design pattern GoF: introduzione, Adapter, Factory, Singleton (in dettaglio) e conclusione sul problema dei servizi esterni (Cap. 29, da 29.1 a 29.4 (cenni), 29.5 (in dettaglio), 26.6 (cenni) e 29.11) aps29a
    29. Applicare i design pattern GoF: Strategy (in dettaglio) (Cap. 29, 29.7 (in dettaglio)) aps29b

20 maggio 2020

  non ci sarà lezione

 

   

 

25 maggio 2020   Prima prova intermedia (ore 10:00)  
26 maggio 2020 56 e 57 29. Applicare i design pattern GoF: Facade, Observer (Cap. 29, 29.9 (cenni) e 29.10 (cenni)  
    37. Raffinamento dell'architettura logica: collaborazioni tra strati (Cap. 37, 37.2 e 37.4, cenni) aps37a

 

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

aps39a

27 maggio 2020

  non ci sarà lezione

 

 

 

1 giugno 2020

  non ci sarà lezione

 

2 giugno 2020

  non ci sarà lezione (Festa della Repubblica)

 

3 giugno 2020
dalle 14:30
58 e 59 Esercitazione OOA/D: AcmePayroll (studio di caso)  

 

 

    le lezioni del corso sono terminate  

 

 

11 giugno 2020   Seconda prova intermedia  

 

 

   

 

  In questa tabella, tutto ciò che segue questa riga si riferisce all'anno accademico precedente

 

   

 

 

 

   

 

 


Prove in itinere e homework

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 DeliverEat: Analisi - Modellazione di dominio Acme DeliverEat 25 marzo 2020 entro la mezzanotte di
lunedì 30 marzo
no
2 Acme DeliverEat: Analisi - Operazioni di sistema Acme DeliverEat 31 marzo 2020 entro la mezzanotte di
lunedì 6 aprile
no
3 Acme DeliverEat: Analisi - OOD UC1 Acme DeliverEat 5 maggio 2020 entro la mezzanotte di
mercoledì 13 maggio
no
           

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

Programma definitivo del corso di Analisi e progettazione del software per gli studenti dell'ordinamento 270, per l'anno accademico 2019-2020 – 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 (in caso di normale attività didattica)

Modalità di svolgimento degli esami di profitto per gli appelli ordinari del corso di Analisi e progettazione del software, in caso di normale attività didattica (altrimenti si vedano le indicazioni relative allo svolgimento degli esami a seguito dell'emergenza sanitaria e fino al ripristino della normale attività didattica): 

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 (modalità di svolgimento a seguito dell'emergenza sanitaria e fino al ripristino della normale attività didattica)

Modalità di svolgimento degli esami di profitto del corso di Analisi e progettazione del software a seguito dell’emergenza sanitaria e fino al ripristino della situazione di normale attività accademica

L'esame di Analisi e progettazione del software si svolgerà come segue:

In caso di impedimenti comprovati o di situazioni straordinarie, si prega di contattare il docente al più presto.


Date d'esame

Nell'anno accademico 2019-2020 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.