Differenze tra le versioni di "Ingegneria del software Turno 2/2005-2006"

Da WikiDsy.
(Secondo Compitino)
Riga 1: Riga 1:
[[Categoria:Corsi]][[Categoria:Corsi Informatica]][[Categoria:Corsi Secondo Semestre]]
+
[[Categoria:Corsi]][[Categoria:Corsi Informatica]][[Categoria:Corsi Secondo Semestre]][[Corsi 2005-2006]]
  
 
== News ==
 
== News ==

Versione delle 17:12, 30 giu 2006

Corsi 2005-2006

News

07/03/06: Orario

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

06/04/06: Primo Compitino

Il compitino si terrà, invece del giorno 28/04 come precedentemente segnalato, il 05/05 in aula 200 alle 17:30

20/04/06: Primo Compitino in data 05/05

E' stato confermato dal prof. Ornaghi che il compitino sarà il 5 maggio ore 17.30 aula 200 settore didattico Via Celoria.

04/05/06: Lezione di preparazione al compitino

Il giorno 04/05 durante il normale orario di lezione il prof si è reso disponibile a fare esercizi in preparazione al compitino.

Secondo Compitino

Il secondo compitino si terrà il 23/06 in aula Beta alle 17.00. Sono ammessi al secondo compitino gli studenti non insufficienti nel primo compitino.

Lezioni cancellate/spostate

Lezione del 27/04/2006

 AVVISO: causa indisponibilita' dell'aula Beta, la lezione del 27/04/2006
 sara' in via Celoria, aula 303

Lezione del 18/05/2006

 AVVISO: la lezione del 18 maggio non si terra' a causa impegno in commissione elettorale
 per il CDA dell'Universita'.

Risultati Primo Compitino

 AVVISO: i risultati del primo compitino sono stati pubblicati qui.

Appelli

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

Anni precedenti

Informazioni generali

Docenti

Mario Ornaghi

Corsi di laurea

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.

Prerequisiti al corso

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

Orario di ricevimento studenti

Informazioni specifiche

Siti del corso

Forum del corso, e affini

 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

Video delle lezioni

Appunti

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

Altro materiale in Internet

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

Esami passati, tesine, compiti ..

Diario del corso

Lezione del 07/03/2006

  • Introduzione al corso
 (slide disponibili qui)

Lezione del 09/03/2006

 (slide disponibili qui)

Lezione del 14/03/2006

 (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
 (slide disponibili qui)

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)

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
    • 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 eredità, 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)

Lezione del 06/04/2006

  • UML
    • Generalizzazione fra classi
    • Stereotipi predefiniti per classi
      • sintassi grafica
  • Semantica type -> instance e la generalizzazione
  • UML
    • Relazione di realizzazione nei diagrammi di classe
    • Semantica delle interfacce
    • Le associazioni
      • I link
    • Diagrammi di classe
      • Diagrammi di oggetti e semantica dei diagrammi di classe
        • Semantica type -> instance dei diagrammi di classe
        • Associazioni, generalizzazione, ereditarietà
        • I livelli del modello e degli oggetti nella modellazione
 (slide disponibili qui)

Lezione del 11/04/2006

Ultima lezione valida per il compitino.
La prossima lezione si terrà giovedì 20/04.

  • I diagrammi di classe nella programmazione OO.
  • Le associazioni nel disegno
    • navigazione
    • vincoli di molteplicità
    • associazione di composizione
    • associazione "parte di"
  • Ripasso
 (slide disponibili qui)

Lezione del 20/04/2006

  • I diagrammi di classe nella costruzione del modello concettuale
  • Preparazione per il compitino: dettaglio ed alcuni esempi
 (slide disponibili qui)

Lezione del 27/04/2006

  • Diagrammi UML per il disegno di livelli più alti
    • Diagrammi di Package
      • Package come moduli
      • import/export con i package
    • Diagrammi di Componenti
    • Diagrammi di Deployment
  • Soluzione esercizi lezione precedente
 (slide disponibili qui)

Lezione del 02/05/2006

  • Le specifiche nel processo di produzione
  • Analisi dei requisiti
    • Analisi OO
    • Funzioni del sistema
  • Analisi concettuale
    • Glossario
  • UML: Casi d'uso
    • Sistema ed attori
    • Presentazione
    • Classificazione
    • Estensioni ed inclusioni
    • Casi d'uso rispetto a disegno e specifica
  • Esercizio in preparazione al compitino
 (slide disponibili qui)

Lezione del 09/05/2006 e 11/05/2006

  • Le specifiche e il loro ruolo
    • Specifica dei requisiti
    • Specifica di disegno
    • Specifica dei vincoli
    • Specifica dei moduli
  • Utilità delle specifiche
    • Comprendere e precisare i requisiti dell’utente
    • Stabilire i requisiti del sistema verso l'implementazione
    • Specificare l’interfaccia fra sistema ed esterno
    • Fornire precisi punti di riferimento per le modifiche
  • Qualità principali delle specifiche
    • Comprensibilità, chiarezza e non ambiguità
    • Consistenza
    • Completezza
  • Stili di specifica
  • Specifiche dichiarative
    • UML, diagrammi di classe e vincoli
    • Raffinamenti, disegno e specifica dei moduli
  • I Vincoli ed OCL
    • I vincoli nella specifica
    • OCL
      • Sintassi, tipi base
      • Operazioni su collection, exists e forAll, Set, Bag, Sequence
      • Segnatura derivata dal modello
      • Semantica
  • Specifica UML dei contratti
    • Correttezza rispetto ai contratti ed ai vincoli
 (slide disponibili qui)

Lezione del 16/05/2006

 AVVISO: la lezione del 18 maggio non si terra' a causa impegno in commissione elettorale
 per il CDA dell'Universita'.
  • UML: Diagrammi di interazione
    • Diagrammi di collaborazione
      diagrammi di oggetti che mostrano come i messaggi passano da un oggetto all’altro in uno scenario tipico
    • Diagrammi di sequenza
      mostrano come i messaggi si susseguano e siano collegati nell’asse del tempo
      • messaggi e stacking
      • messaggi sincroni e asincroni e creazione oggetti
  • Automi
  • UML: Diagrammi di stato
  • UML: eventi
    • call events, signals e time/change events
 (slide disponibili qui)

Lezione del 18/05/2006

 SOSPESA

Lezione del 23/05/2006

  • Transizioni in UML
  • Stati in UML
  • Norma generale
    Quando il risultato di un metodo (o componente) non è costante, ma dipende dalla storia precedente, è bene descrivere il comportamento dell’oggetto mediante un diagramma di stato.
  • Specifiche in presenza di concorrenza; concorrenza nei diagrammi di stato
    • Attività interne
    • Attività interne concorrenti
    • Buffer, produttore, consumatore
  • Diagrammi di attività in UML
    • Transizioni nei diagrammi di attività
      • branch, fork, join
    • Uso
  • Reti di Petri
    • Modello di computazione: marcatura, condizione
    • Modello di computazione: abilitazione, scatto, eventi
    • Modello di computazione: sequenze di scatto e computazioni
 (slide disponibili qui)

Lezione del 25/05/2006

  • Reti di Petri
    • Concorrenza
  • Pattern (cenni)
    • GRASP (General Responsibility Assignment Software Patterns)
      • GRASP valutativi
      • GRASP basilari
        • Creator
        • Don't talk to strangers
        • Pure Fabrication
    • Pattern GRASP di disegno
      • Controller
      • Command
 (slide disponibili qui)

Lezione del 30/05/2006

 (slide disponibili qui)

Lezione del 01/06/2006

 (slide disponibili qui)

Lezione del 06/06/2006

 (slide disponibili qui)

Lezione del 08/06/2006

  • Strategie per il test empirico
    • Criteri di test mediante suddivisione del dominio
      • Principio di copertura completa
    • Insiemi di test minimali
    • Test in piccolo e in grande
  • Test in piccolo
    • Test con scatola trasparente (in piccolo)
      • Criterio di copertura delle istruzioni
      • Criterio di copertura degli archi
      • Criterio di copertura dei cammini
      • Copertura delle condizioni e delle condizioni multiple
        La copertura delle condizioni richiede che ogni condizione atomica sia esercitata almeno una volta per vero e almeno una volta per falso
    • Test con scatola nera (in piccolo)
      è guidato dalle specifiche. E' detto anche test funzionale
      • Criteri derivati da contratti
      • Uso di tabelle
    • Test di confine (boundary)
  • Oracoli


  • Test in grande
  • Test dei moduli
    • Stub e driver
  • Test di integrazione
    • Test di integrazione bottom-up / top-down (relazione “uses” aciclica)
    • Bottom-up e top-down modulari (relazione di sotto-modulo)
    • Test di integrazione object-oriented
  • Test di sistema
    • Test di sovraccarico
    • Test di robustezza
    • Test di (non) regressione


  • Strumenti per il testing
 (slide disponibili qui)