Ingegneria del software Turno 2/2005-2006

News

07/03/06: Orario

L'orario delle lezioni viene modificato in 17:45 - 19:15

28/03/06: Preparazione al compitino

La lezione del 27/04/2006 sarà in preparazione al compitino, che si svolgerà la settimana seguente in data da destinarsi.

Appelli

• 20/4/2006
• 22/6/2006
• 18/7/2006
• 21/9/2006
• 19/10/2006
• 25/1/2007

Informazioni generali

Docenti

Mario Ornaghi

Corsi di laurea

• Informatica

Modalità d'esame

• Compitini e, per chi non ha fatto o superato i compitini, orale tradizionale
• Orale:
  • per chi ha fatto i compitini: verbalizzazione del voto dei compitini, con eventuali brevi domande nel caso di incertezze;
  • per chi non ha fatto i compitini o non è soddisfatto del voto dei compitini orale dettagliato; il voto sarà determinato dall’orale.

Orari e luogo delle lezioni

• Martedì 17:45-19:15 Aula Beta (218 posti, via Comelico 39)
• Giovedì 17:45-19:15 Aula Beta (218 posti, via Comelico 39)
• link al corso su DSI

Informazioni specifiche

Siti del corso

• http://www.dsy.it/forum/forumdisplay.php?s=&forumid=85 (hosted forum del professor Ornaghi)

Forum del corso, e affini

• Forum sul Dsy di Ingegneria del Software (in comune con turno 1)
• http://www.dsy.it/forum/forumdisplay.php?s=&forumid=85 (hosted forum del professor Ornaghi)

 NOTA: per avere la password del Forum chiedere in questo thread

Materiale didattico

Programma del corso

• Parte I. Generalità e Progettazione
  • Introduzione all’ingegneria del software;
  • Ciclo di vita del Software
  • Qualità e Principi
  • Cenni su Requisiti ed Analisi
  • Progettazione ed Architetture
• Parte II. Analisi, Specifica e Verifica
  • Analisi, specifica e verifica nel ciclo di vita
  • Specifica
    • Operazionale vs dichiarativa
    • formale vs informale
  • Verifica
    • Testing
    • Analisi
    • Tools
• Parte III. Analisi, Progettazione e programmazione OO (Object Oriented)
  • Sarà interfogliata alle parti I e II, specializzandole al caso OO
    • In particolare, Principi di OOA&P: patterns
  • Introdurrà e userà UML

Testi

• Ghezzi, Jazayeri, Mandrioli: Ingegneria del Software - fondamenti e principi, 2° ed., Prentice Hall
  • per la parte UML
    C. Larman: Applicare UML e i pattern – 3° ed., Pearson 2005

Altro materiale consigliato

• Gamma et al: Design Patterns. Prima edizione italiana. Addison-Wesley Italia, 2002
• M. Fowler. UML distilled. Prima edizione italiana. Addison Wesley Italia, 2000

Appunti

• Lucidi A.A. 2005/2006

 (si possono scaricare solo 'dopo aver eseguito il login come utente Dsy e aver inserito la password)

• • Introduzione, lezioni da 01 a 04
• Lucidi A.A. 2004/2005

Altro materiale in Internet

Si consiglia l'utilizzo del software free ARGO, scaricabile gratuitamente da http://argouml.tigris.org

Diario del corso

Lezione del 07/03/2006

• Introduzione al corso

 (slide disponibili qui)

Lezione del 09/03/2006

• Nascita dell'ingegneria del software
• Ingegneria del software
  • definizioni
• Ciclo di vita del software
  • modello a cascata: analisi dei requisiti, disegno e specifica del sistema, codifica e verifica dei moduli, integrazione e verifica del sistema, rilascio e manutenzione
• Altri processi di sviluppo

 (slide disponibili qui)

Lezione del 14/03/2006

• Qualità del software
  • Classificazione delle qualità
    • Qualità interna, esterna, del prodotto, del processo
  • Le principali qualità
    • Qualità comportamentali (robustezza, affidabilità, completezza, usabilità)
    • Prestazioni
    • Manutenibilità
    • Utilizzabilità del software (riusabilità)

 (slide disponibili qui)

Lezione del 16/03/2006

• Qualità del software
  • Utilizzabilità
    • Riusabilità
    • Portabilità
      = capacità di un sistema software di essere adattato a piattaforme HDW e sistemi operativi o SFTW diversi
    • Interoperabilità
      = capacità di un sistema di cooperare con altri sistemi
• Qualità del disegno e del codice
  • Verificabilità
    = misura l’effettività (ai fini della verifica) di documentazione e moduli di verifica
  • Comprensibilità
    = misura della chiarezza di codice, disegno, specifiche, a parità di difficoltà intrinseca dell’ambito di problema
• Qualità del processo
  • Produttività
    = misura la produttività di un processo di produzione del software
  • Tempestività
    = capacità del processo di rispettare i tempi previsti
  • Visibilità

• I Principi
  • Sono orientati, in particolare, alle qualità affidabilità e modificabilità
    Sono:
    rigore e formalità
    seguire un procedimento disciplinato e rigoroso; usare metodi formali dove appropriato; formalizzare il problema
  • separazione (separation of concerns)
    trattare separatamente problematiche diverse

Lezione del 21/03/2006

• I Principi
  • modularità
    decomporre un sistema in parti coese e con basso accoppiamento, dette moduli
    • alta coesione
    • basso accoppiamento
  • astrazione
    astrarre dai dettagli non rilevanti rispetto allo scopo
  • anticipazione dei cambiamenti
    prevedere le possibili modifiche adattive, perfettive, di riuso
  • generalità
    chiedersi sempre se un problema può essere risolto come caso particolare di un problema più generale.
  • incrementalità
    procedere per incrementi

 (slide disponibili qui)

Lezione del 23/03/2006

• La fase di disegno o progetto
  • Analisi e specificazione dei requisiti
  • La fase di disegno (progetto)
    • Disegno architetturale
    • Disegno del software
• Caratteristiche di disegno
  • Tecniche di modularizzazione
    • I moduli: aspetti strutturali
    • La relazione "usa"
    • grado di accoppiamento

 (slide disponibili qui e qui)

Lezione del 28/03/2006

 Prima raccolta firme per il compitino, il foglio girerà ancora settimana prossima

• La Relazione "componente di"
  consente di documentare le scelte man mano fatte
  controllare gli effetti sui livelli alti di modifiche introdotte nei livelli più bassi, al fine di mantenere la consistenza della documentazione
  sviluppare famiglie di prodotti
  • Aspetti strutturali di usa e componente di
• Nozione di modulo
  • Interfaccia
    rappresenta tutto ciò che è necessario sapere per utilizzare un modulo M, e deve essere specificata in modo preciso e rigoroso
  • Incapsulamento o Information hiding
    nascondere gli aspetti implementativi
  • Pubblicazione delle interfacce
    • cosa pubblicare nelle interfacce
      trascurare i dettagli irrilevanti e mettere solo quelli essenziali rispetto allo scopo
    • come specificare le interfacce in modo rigoroso
• Notazioni per i moduli: requisiti essenziali
  • alcuni esempi
  • moduli generici

   (slide disponibili qui)

Lezione del 30/03/2006

Seconda raccolta firme per il compitino, il foglio girerà ancora settimana prossima.
In ogni caso basta una sola firma.

• Disegno nei sistemi concorrenti e distribuiti
  • I monitor
  • Guardians (tipico di ADA)
  • Software distribuito
    • legame Modulo - Macchina
    • comunicazione fra moduli
      chiamata procedura remota
      messaggi
    • duplicazione e distribuzione
• Architettura
  • Architettura di Sistema
    Struttura delle parti che compongono un’installazione completa + individuazione delle responsabilità delle parti + interconnessioni + eventualmente tecnologia
    • Architetture generali
      • pipeline
        l'uscita di un elemento è presa come ingresso dell'elemento successivo
      • blackboard
      • basate su eventi
        le varie componenti rispondono al verificarsi di determinati eventi
    • Architetture orientate a domini specifici
      • model - view - controller
      • client - server
  • Componenti
    insieme di componenti software di livello applicativo + relazioni strutturali fra essi + dipendenze che influiscono sul loro comportamento
    in generale è una parte software riusabile in più applicazioni distinte
    • Architettura come piattaforma per l'integrazione delle componenti
      ad esempio in ambiente distribuito CORBA (vedi wikipedia italia o inglese)
      interfacce di comunicazione definite in un linguaggio standard: IDL

   (slide disponibili qui)

Lezione del 04/04/2006

• Object Oriented Design (OOD) e Object Oriented Programming (OOP)
  • caratteristiche generali
    • OOP per il software di qualità
      facilita in particolare
      Utilizzabilità
      Manutenibilità
      che derivano da #Ereditarietà|eredità, #Polimorfismo|polimorfismo, classi astratte ed interfacce
    • OOP e principi
    • Collaborazione e responsabilità, aspetti architetturali
• OOP tramite UML
  • UML: generalità
    linguaggio di modellazione OO
    linguaggio grafico
    sintassi grafica organizzata a 4 livelli
    semantica type-instance
    formalismo aperto ad estensioni e personalizzazioni
    • UML per il disegno: aspetti architetturali
      diagrammi statici e dinamici
      relazioni fra moduli
      • generalizzazione
      • realizzazione
      • dipendenza
      • associazione
  • Diagrammi di classe
    • Oggetti e Classi in UML
    • Semantica di istanza delle classi implementative
      una classe implementativa è interpretata (nella semantica di istanza) come l’insieme delle sue istanze
      • Identità ed uguaglianza strutturale di oggetti
        un oggetto è uguale solo a sé stesso

 (slide disponibili qui)