Progetto del Software

Informazioni generali dell'insegnamento

Nome dell'insegnamento:Progetto del Software [MN1-1279]
Docente:Giacomo Cabri
Corso di Studio:Informatica [16-209]
Tipologia:Caratterizzante
CFU:6
Periodo Didattico:Secondo Ciclo Semestrale

Obiettivo dell'insegnamento

L'insegnamento intende fornire gli strumenti modellistici e metodologici necessari per la specifica dei requisiti, l'analisi, la progettazione e lo sviluppo di sistemi software complessi. Lo strumento principale utilizzato è il modello UML (Unified Modelling Language).

Programma dell'insegnamento

  • Concetti generali
    • Software come prodotto industriale.
    • Concetto di modularità.
    • Ciclo di sviluppo del software e modelli.
  • Specifica dei requisiti del software, standard IEEE 830 SRS.
  • Il modello UML: casi d'uso, diagrammi delle attività diagramma delle classi, diagrammi di stato, diagrammi di sequenza.
  • Design patterns.

Orario delle lezioni

Orario per l'AA 2012/13:
  • Lun 9.00 - 11.00, Aula V Matematica;
  • Gio 14.00 - 17.00, Aula IV Matematica;
Orario per l'AA 2011/12:
  • Lun 9.00 - 11.00, Aula V Dipartimento di Matematica;
  • Mar 14.00 - 17.00, Aula E Dipartimento di Fisica;

Avvisi (in ordine cronologico inverso)

  • Le lezioni dell'AA 2012/13 inizieranno giovedì 7 marzo 2013.
  • ---
  • L'esame del 6/6/2012 si terrà in aula V a Matematica e NON in aula F.
  • A causa del terremoto, l'esame del 29/6/2012 e' rinviato a mercoledi' 6/6/2012 alle ore 11 in aula F.
  • La lezione del 21 maggio 2012 è spostata alle ore 11 e sarà una lezione Erasmus insieme ad un collega francese;
  • Il 29 maggio 2012 si terrà un preappello scritto valido per l'orale; chi è interessato a partecipare deve iscriversi su ESSE3;
  • Le lezioni di lunedì 26 e martedì 27 marzo 2012 non si terranno a causa di un impegno all'estero del docente
  • La lezione di martedì pomeriggio è spostata in aula E a Fisica sempre dalle 14 alle 17.

Materiale didattico

Slide

Testi consigliati

  • C. Ghezzi, D. Mandrioli, M. Jazayeri. Ingegneria del Software (2/Ed.). Pearson Education Italia
  • M. Fowler. UML Distilled (4/Ed.). Pearson Education Italia. La versione inglese è scaricabile gratuitamente
  • E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns. Pearson Education Italia

Per approfondire

  • C. S. Horstmann. Progettazione del Software e Design Pattern in Java. Apogeo Education
  • C. Ghezzi et al. Ingegneria del Software. Mondadori Informatica
  • B. Eckel. Thinking in Patterns with Java. Disponibile dal sito http://www.mindview.net
  • A. Binato, A. Fuggetta, L. Sfardini. Ingegneria del software Creatività e metodo. Pearson Education Italia

Riferimenti

Strumenti software

Per disegnare diagrammi UML è possibile usare diversi strumenti. Si segnala: Programma per simulare Macchine a stati finiti: Programma per simulare Reti di Petri:

Esami

L'esame permette di acquisire 6 CFU e si compone di 2 parti.
  • Una prima parte di verifica della conoscenza delle basi e degli strumenti della progettazione del software.
    Può essere scritta (pre appello) o orale (contestualmente alla discussione del progetto).
  • Una seconda parte di verifica della capacità di utilizzare gli strumenti della progettazione del software.
Per la seconda parte è richiesto lo sviluppo di un progetto con queste modalità:
  • Ogni studente chiede al docente l'attribuzione di una traccia; ogni traccia è individuale.
  • Il docente fornisce allo studente la traccia e da quel momento lo studente ha 15 giorni per consegnare l'elaborato.
  • L'elaborato deve essere inviato in un unico file PDF al docente via email.
  • L'elaborato viene discusso durante un appello orale, a cui lo studente deve iscriversi tramite ESSE3.
  • La documentazione da presentare nell'elaborato è composta almeno da:
    • Documento SRS con almeno i seguenti punti:
      1. Introduzione
      1.1 Obiettivo
      1.2 Campo d'applicazione
      1.4 Fonti
      2. Descrizione generale
      2.1 Inquadramento
      2.2 Macro funzionalità
      2.3 Caratteristiche degli utenti
      3. Specifica dei requisiti
      3.2 Requisiti funzionali
      3.3 Requisiti non funzionali
      Il documento deve essere coerente e il più possibile completo.
    • Diagrammi dei casi d'uso e delle attività che descrivano una analisi dell'applicazione.
    • Diagrammi delle classi e di sequenza che descrivano la progettazione dell'applicazione.
    • Almeno un design pattern individuato come soluzione ad un problema.