Analisi e progettazione del software

Anno accademico 2010-2011

(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 
• introduzione al corso 
• lezioni
• homework
• programma
• programma per gli studenti dell'ordinamento 509
• materiale didattico
• esami
• esami per gli studenti dell'ordinamento 509
• testi di prove d'esame

Avvisi

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

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

• Sviluppo iterativo e incrementale. Unified Process.
• Analisi dei requisiti. Casi d'uso.
• Analisi orientata agli oggetti. Modello di dominio. Diagrammi di sequenza di sistema. Contratti delle operazioni.
• Progettazione orientata agli oggetti. Diagrammi di interazione. Diagrammi delle classi di progetto.
• Dalla progettazione orientata agli oggetti alla programmazione orientata agli oggetti.
• Principi di analisi e progettazione orientata agli oggetti. Pattern GRASP.
• Design patterns.
• Progettazione dell'architettura logica. Pattern architetturali.
• Gestione della persistenza degli oggetti. (cenni)
• Unified Modeling Language.

Prerequisiti

Costituiscono un prerequisito fondamentale di questo corso i corsi di Basi di dati e di Programmazione orientata agli oggetti.

Lezioni

Argomenti delle lezioni svolte 

Homework

Le soluzioni agli homework, scritte individualmente e a mano, vanno fatte pervenire al docente all'inizio delle lezioni del corso oppure al ricevimento studenti, e comunque nei tempi indicati nella seguente tabella:

Notare che, per ciascun homework, i requisiti sono descritti in un documento diverso da quello contenente gli esercizi dell'homework.

Alcune precisazioni sulla consegna degli homework:

• Il termine ultimo per la consegna degli homework va inteso come "all'inizio della lezione del giorno X" e non "entro la mezzanotte del giorno X".
• Chi realizza la propria soluzione di un homework nei tempi stabiliti ma è impossibilitato ad effettuarne la consegna nei tempi stabiliti, può seguire la seguente procedura (da adottare solo in casi veramente eccezionali):
  1. effettuare una scansione dell'elaborato ed inviarla per posta elettronica al docente comunque entro i tempi stabiliti;
  2. consegnare l'elaborato (in originale e comunque conforme a quello inviato in modo elettronici) all'inizio della lezione successiva alla data prevista per 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 2010-2011 – l'indicazione dei capitoli fa riferimento all'edizione italiana del libro di testo Applicare UML e i pattern  

• Introduzione all'analisi e progettazione orientata agli oggetti – Capitolo 1
• Processi per lo sviluppo del software; processo a cascata; processo iterativo, evolutivo e agile; Unified Process (UP) – Capitolo 2 (di cui da 2.6 a 2.9 e 2.12 solo cenni)
• Introduzione agli studi di caso POS NextGen e Monopoly Game System – Capitolo 3
• Ideazione – Capitolo 4 (cenni)
• Requisiti: Requisiti – Capitolo 5
• Requisiti: Casi d'uso – Capitolo 6 (da 6.1 a 6.13, nonché 6.17, 6.20 e 6.21)
• Requisiti: Altri requisiti – Capitolo 7 (cenni)
• Elaborazione: Iterazione 1 – Capitolo 8
• Analisi orientata agli oggetti: Modelli di dominio – Capitolo 9
• Analisi orientata agli oggetti: Diagrammi di sequenza di sistema – Capitolo 10
• Analisi orientata agli oggetti: Contratti delle operazioni – Capitolo 11
• Dai requisiti alla progettazione – Capitolo 12
• Architettura logica e diagrammi dei package di UML – Capitolo 13
• Verso la progettazione a oggetti – Capitolo 14
• Diagrammi di interazione di UML – Capitolo 15
• Diagrammi delle classi di UML – Capitolo 16 (normalmente in dettaglio, con le seguenti eccezioni: 16.15 cenni, 16.16 cenni, saltare 16.18, saltare 16.20)
• Progettazione orientata agli oggetti: Progettazione basata sull'assegnazione di responsabilità; pattern GRASP (information expert, creator, low coupling, high cohesion, controller) – Capitolo 17
• Progettazione orientata agli oggetti: Realizzazione di casi d'uso con i pattern GRASP – Capitolo 18
• Progettazione orientata agli oggetti: Progettare per la visibilità – Capitolo 19
• Progettazione orientata agli oggetti: Trasformare i progetti in codice – Capitolo 20 (tranne 20.12)
• Progettazione orientata agli oggetti: Sviluppo guidato dai test e Refactoring – Capitolo 21 (cenni)
• Progettazione orientata agli oggetti: Strumenti per UML e UML come progetto – Capitolo 22 (cenni)
• Elaborazione: Iterazione 2 – Capitolo 23
• Analisi orientata agli oggetti: Rapido aggiornamento dell'analisi – Capitolo 24
• Analisi orientata agli oggetti: Raffinamento del modelli di dominio – Capitolo 31 (da 31.1 a 31.9, in dettaglio; 31.10, cenni; da 31.11 a 31.15 e 31.17, in dettaglio)
• Progettazione orientata agli oggetti: Altri pattern GRASP (polymorphism, pure fabrication, indirection, protected variations) – Capitolo 25
• Progettazione orientata agli oggetti: Progettazione basata sull'uso dei design pattern GoF: adapter, factory, singleton, strategy, facade, observer (in dettaglio), proxy (cenni) – Capitolo 26 
• Raffinamento dell'architettura logica: collaborazioni tra strati – Capitolo 34 (34.2 e 34.4)
• Ulteriore progettazione a oggetti con i pattern GoF – Capitolo 36 (36.9 e 36.10)
• SOLID: Altri principi per la progettazione a oggetti (cenni) – dispensa aps91 a cura del docente
• Introduzione a Domain-Driven Design ed alla persistenza di oggetti (cenni) – dispensa aps92 a cura del docente

I concetti introdotti durante il corso sono esemplificati con riferimento ai seguenti studi di caso, che sono parte integrante del programma d'esame:

• il sistema POS NextGen;
• il sistema Monopoly Game System;
• il sistema ERedit;
• il sistema VideoRental;
• il sistema PortaleEsami;
• il sistema AcmeBay.

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 libro di testo Applicare UML e i pattern  

• Introduzione all'analisi e progettazione orientata agli oggetti – Capitolo 1
• Processi per lo sviluppo del software; processo a cascata; processo iterativo, evolutivo e agile; Unified Process (UP) – Capitolo 2 (di cui da 2.6 a 2.9 e 2.12 solo cenni)
• Introduzione agli studi di caso POS NextGen e Monopoly Game System – Capitolo 3
• Ideazione – Capitolo 4 (cenni)
• Requisiti: Requisiti – Capitolo 5
• Requisiti: Casi d'uso – Capitolo 6 (da 6.1 a 6.13, nonché 6.17, 6.20 e 6.21)
• Requisiti: Altri requisiti – Capitolo 7 (cenni)
• Elaborazione: Iterazione 1 – Capitolo 8
• Analisi orientata agli oggetti: Modelli di dominio – Capitolo 9
• Analisi orientata agli oggetti: Diagrammi di sequenza di sistema – Capitolo 10
• Analisi orientata agli oggetti: Contratti delle operazioni – Capitolo 11
• Dai requisiti alla progettazione – Capitolo 12
• Architettura logica e diagrammi dei package di UML – Capitolo 13
• Verso la progettazione a oggetti – Capitolo 14
• Diagrammi di interazione di UML – Capitolo 15
• Diagrammi delle classi di UML – Capitolo 16 (normalmente in dettaglio, con le seguenti eccezioni: 16.15 cenni, 16.16 cenni, saltare 16.18, saltare 16.20)
• Progettazione orientata agli oggetti: Progettazione basata sull'assegnazione di responsabilità; pattern GRASP (information expert, creator, low coupling, high cohesion, controller) – Capitolo 17
• Progettazione orientata agli oggetti: Realizzazione di casi d'uso con i pattern GRASP – Capitolo 18
• Progettazione orientata agli oggetti: Progettare per la visibilità – Capitolo 19
• Progettazione orientata agli oggetti: Trasformare i progetti in codice – Capitolo 20 (tranne 20.12)
• Progettazione orientata agli oggetti: Sviluppo guidato dai test e Refactoring – Capitolo 21 (cenni)
• Progettazione orientata agli oggetti: Strumenti per UML e UML come progetto – Capitolo 22 (cenni)
• Elaborazione: Iterazione 2 – Capitolo 23
• Analisi orientata agli oggetti: Rapido aggiornamento dell'analisi – Capitolo 24
• Analisi orientata agli oggetti: Raffinamento del modelli di dominio – Capitolo 31 (da 31.1 a 31.9, in dettaglio; 31.10, cenni; da 31.11 a 31.15 e 31.17, in dettaglio)
• Progettazione orientata agli oggetti: Altri pattern GRASP (polymorphism, pure fabrication, indirection, protected variations) – Capitolo 25
• Progettazione orientata agli oggetti: Progettazione basata sull'uso dei design pattern GoF: adapter, factory, singleton, strategy, facade, observer (in dettaglio), proxy (cenni) – Capitolo 26 
• Raffinamento dell'architettura logica: collaborazioni tra strati – Capitolo 34 (34.2 e 34.4)
• Ulteriore progettazione a oggetti con i pattern GoF – Capitolo 36 (36.9 e 36.10)
• SOLID: Altri principi per la progettazione a oggetti (cenni) – dispensa aps91 a cura del docente
• Introduzione a Domain-Driven Design ed alla persistenza di oggetti (cenni) – dispensa aps92 a cura del docente

I concetti introdotti durante il corso sono esemplificati con riferimento ai seguenti studi di caso, che sono parte integrante del programma d'esame:

• il sistema POS NextGen;
• il sistema Monopoly Game System;
• il sistema ERedit;
• il sistema VideoRental;
• il sistema PortaleEsami;
• il sistema AcmeBay.

Materiale didattico

Libro di testo

• Craig Larman
  Applicare UML e i pattern – Analisi e progettazione orientata agli oggetti
  ISBN: 8871922700
  Pearson Education Italia, 2005

È anche possibile utilizzare la versione originale in inglese dello stesso libro:

• Craig Larman
  Applying UML and patterns – an introduction to object-oriented analysis and design and iterative development
  Third edition (22 ottobre 2004)
  ISBN: 0131489062
  Prentice Hall PTR, 2005

In questo caso, è utile sapere che c'è una corrispondenza un po' strana tra i capitoli della versione italiana e quelli della versione inglese (perlomeno nella prima stampa, non so se anche nelle ristampe in circolazione adesso; l'ordine giusto è quello del libro in italiano). Infatti, nella terza edizione inglese (almeno nella sua prima stampa) alcuni capitoli sono stati collocati nel posto sbagliato. In generale, la corrispondenza tra capitoli dovrebbe essere chiara dai titoli dei capitoli stessi.

Più precisamente: Normalmente i capitoli corrispondono (ad esempio, 7 inglese con 7 italiano), con queste eccezioni:

• il capitolo 22 inglese fa parte della parte III (non della parte IV)
• i capitoli 23 e 24 vanno scambiati (23 diventa 24 e viceversa)
• i capitoli 31 e 32 vanno scambiati
• i capitoli 35 e 36 vanno scambiati
• i capitoli 37 e 38 vanno scambiati

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

• Martin Fowler
  UML distilled - terza edizione
  Pearson Education Italia, 2004
  Una introduzione concisa ad UML.
• Eric Gamma, Richard Helm, Ralph Johnson e John Vlissides
  Design patterns – elements of reusable object-oriented software
  Addison-Wesley, 1995
  Il libro fondamentale sui design pattern.
• Eric Gamma, Richard Helm, Ralph Johnson e John Vlissides
  Design patterns – elementi per il riuso di software a oggetti
  Addison-Wesley, Pearson Education Italia, 2002
  Edizione italiana del libro di cui sopra.
• Frank Buchmann, Regine Meunier, Peter Sommerlad e Michael Stal
  Pattern-oriented software architecture – a system of patterns
  John Wiley & Sons, 1996
  Libro fondamentale sui pattern architetturali, in cui viene descritto Layers.
• Robert C. Martin
  Agile software development - principles, patterns, and practices
  Prentice Hall, 2003
  Un altro ottimo libro di progettazione orientata agli oggetti. L'approccio però è diverso da quello del Larman e di questo corso. Ottimo per chi vuole approfondire i temi di questo corso. 
• Robert C. Martin, M. Martin
  Agile principles, patterns, and practices in C# 
  Prentice Hall, 2007
  Ripropone i temi del libro precedente, approfondendoli di più. Fa riferimento al linguaggio C# e non a Java. (Entrambi i libri sono ricchi di esempi e di codice.)
• Eric Evans
  Domain-Driven Design
  Addison-Wesley, 2004
  Altro buon libro di analisi e progettazione orientata agli oggetti. Fornisce un buon contesto (più ampio) in cui applicare i metodi proposti da Larman. Anche questo molto buono per chi vuole approfondire i temi di questo corso.
• Cheesman & Daniels
  UML Components - un semplice processo per la specifica di software basato su componenti
  Addison-Wesley, 2002
  Mostra una metodologia per la progettazione di software basto su componenti - la metodologia, relativa ad un contesto tecnologico più avanzato, ha molti punti in comune con l'approccio proposto da Larman.

Sito web del corso

• cabibbo.dia.uniroma3.it/aps

Forum/newsgroup del corso

• Attualmente ospiti del Forum di Analisi e progettazione del software presso StudentiDIA.org Forum
• La partecipazione al forum è libera, ma richiede un comportamento civile e responsabile.
  Si consiglia di leggere Etica e norme di buon uso dei servizi di rete, nonché il regolamento del forum stesso.

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:

• il sistema POS NextGen;
• Monopoly Game System;
• il sistema ERedit (requisiti);
• il sistema abcBid (requisiti);
• il sistema AcmeU (requisiti);
• la colazione di Rosa
  • requisiti, analisi e progettazione (versione del 9 gennaio 2006);
  • codice (versione del 9 gennaio 2006, workspace compresso per Eclipse contenente varie versioni de La colazione di Rosa);

Regolamento ufficiale del Monopoli

• Regolamento del Monopoli
• Regolamento del Monopoly (in inglese)

Esami (ordinamento 270)

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

Esame con progetto

• progetto:
  • alcuni giorni (2 o 3) prima dello scritto viene proposto uno studio di caso – con esercizi di analisi e progettazione
  • lo studente consegna, alla prova scritta, un elaborato relativo a tale studio di caso – scritto a mano ed individualmente
  • il progetto cambia ad ogni appello
• prova scritta, della durata di 160 minuti circa:
  • la prova scritta verte su un ampliamento oppure su una variante del progetto di cui sopra
  • la prova scritta comprende: esercizi di analisi OO (12 punti circa) nonché esercizi di progettazione OO + teoria (18 punti circa)
• eventuale prova orale (a discrezione del docente)

Esame senza progetto

• prova scritta, della durata di 160 minuti circa:
  • la prova scritta comprende: esercizi di analisi OO (12 punti circa) nonché esercizi di progettazione OO + teoria (18 punti circa)
• eventuale prova orale (a discrezione del docente)
• il voto massimo per chi sostiene l'esame con questa modalità è 24

Esame con homework

• homework:
  • lo studente ha partecipa a tutti gli homework proposti, nei tempi stabiliti - e la relativa valutazione è complessivamente positiva
  progetto:
  • alcuni giorni (2 o 3) prima dello scritto viene proposto uno studio di caso – con esercizi di analisi e progettazione
  • lo studente consegna, alla prova scritta, un elaborato relativo a tale studio di caso – scritto a mano ed individualmente
  • il progetto cambia ad ogni appello
• prova scritta, della durata di 160 minuti circa:
  • la prova scritta verte su un ampliamento oppure su una variante del progetto di cui sopra
  • la prova scritta comprende: esercizi di analisi OO (12 punti circa) nonché esercizi di progettazione OO + teoria (18 punti circa)
• eventuale prova orale (a discrezione del docente)
• se lo studente ha ottenuto una valutazione almeno sufficiente alla prova scritta, allora il risultato della valutazione degli homework (al massimo 4) si somma al voto della prova scritta
• questa modalità d'esame è valida esclusivamente per gli studenti che non hanno mai sostenuto in passato l'esame di Analisi e progettazione del software ed  esclusivamente al primo appello (giugno-luglio 2011)

Esami (ordinamento 509)

La modalità d'esame di Analisi e progettazione del software per gli studenti dell'ordinamento 509 è quella dell'anno accademico 2009-2010, come segue: 

Esame con progetto

• progetto:
  • alcuni giorni (2 o 3) prima dello scritto viene proposto uno studio di caso – con esercizi di analisi e progettazione
  • lo studente consegna, alla prova scritta, un elaborato relativo a tale studio di caso – scritto a mano ed individualmente
  • il progetto cambia ad ogni appello
• prova scritta, della durata di 160 minuti circa:
  • la prova scritta verte su un ampliamento oppure su una variante del progetto di cui sopra
  • la prova scritta comprende: esercizi di analisi OO (12 punti circa) nonché esercizi di progettazione OO + teoria (18 punti circa)
• eventuale prova orale (a discrezione del docente)

Esame senza progetto

• prova scritta, della durata di 160 minuti circa:
  • la prova scritta comprende: esercizi di analisi OO (12 punti circa) nonché esercizi di progettazione OO + teoria (18 punti circa)
• eventuale prova orale (a discrezione del docente)
• il voto massimo per chi sostiene l'esame con questa modalità è 24

Esame con homework

• homework:
  • lo studente ha partecipa a tutti gli homework proposti, nei tempi stabiliti - e la relativa valutazione è complessivamente positiva
  progetto:
  • alcuni giorni (2 o 3) prima dello scritto viene proposto uno studio di caso – con esercizi di analisi e progettazione
  • lo studente consegna, alla prova scritta, un elaborato relativo a tale studio di caso – scritto a mano ed individualmente
  • il progetto cambia ad ogni appello
• prova scritta, della durata di 160 minuti circa:
  • la prova scritta verte su un ampliamento oppure su una variante del progetto di cui sopra
  • la prova scritta comprende: esercizi di analisi OO (12 punti circa) nonché esercizi di progettazione OO + teoria (18 punti circa)
• eventuale prova orale (a discrezione del docente)
• se lo studente ha ottenuto una valutazione almeno sufficiente alla prova scritta, allora il risultato della valutazione degli homework (al massimo 4) si somma al voto della prova scritta
• questa modalità d'esame è valida esclusivamente per gli studenti che non hanno mai sostenuto in passato l'esame di Analisi e progettazione del software ed  esclusivamente al primo appello (giugno-luglio 2011)

Date d'esame

Nell'anno accademico 2010-2011 sono previste le seguenti date d'esame (attenzione, potrebbero ancora cambiare):

• giugno-luglio 2011, data ancora da stabilire
• settembre 2011, data ancora da stabilire
• febbraio 2012, data ancora da stabilire

Per partecipare agli esami è necessario prenotarsi ad esso presso il portale dello studente (studenti dell'ordinamento 270) oppure presso il sito prenota.uniroma3.it (studenti dell'ordinamento 509). 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 2008-2009

• 18 giugno 2009 (Scale e Serpenti)
• vedi anche Scale e serpenti su Wikipedia ed un esempio di tabellone del gioco

Dell'anno accademico 2006-2007 

• 20 febbraio 2007 (abcBid - parziale) - riflessioni sulla soluzione del compito abcBid

Dell'anno accademico 2005-2006 (la modalità d'esame potrebbe essere diversa da quella prevista per questo anno accademico) 

• 21 settembre 2006 (AcmeU)

Dell'anno accademico 2004-2005 (la modalità d'esame potrebbe essere diversa da quella prevista per questo anno accademico) 

• 10 febbraio 2005 (VideoRental)

Dell'anno accademico 2003-2004 (la modalità d'esame potrebbe essere diversa da quella prevista per questo anno accademico)

• 6 febbraio 2004 (Course-it)
• 7 luglio 2004 (La Colazione di Rosa)
• 17 settembre 2004 (RelEdit)

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)

• 7 febbraio 2003 (OsBet)
• 11 luglio 2003 (ERedit)
• 17 settembre 2003 - deprecato - il docente non discuterà più lo svolgimento dell'esame su T-man