Ingegneria del software: 3 marzo 2005

Separazione dei principi
Separazione delle responsabilità (non tutte le responsabilità alla stessa persona)
Separazione nel tempo (Prima si progetta poi si codifica)
Separazione nel considerare le qualità (non tutte le qualità vanno cercate immediatamente: es. prima mi preoccupo che sia robusto, solo un secondo momento che si portabile)
Separazione nelle viste da usare (es: flusso dei dati, flusso di controllo, della sicurezza, ecc. ecc.: fare diagrammi separati)
Aspetti legati al problema e legati all'implementazione (specifiche (il cosa) contro implentazione (il come))
Separazione in parti (modularizzazione: separare le parti. Non affrontare un programma in maniera monolitica, ma suddividerlo in parti)
L4: Il valore dei modelli dipende dalle viste che vengono scelte

UML ha 9 viste

1. Modularità:
   Utile per affrontare un problema (divido problemi complessi in problemi meno complessi: scomposizione top-down)
2. Riutilizzabilità: comporre un problema complesso da moduli esistenti (bottom-up)
3. Capire meglio parti complesse come somma di parti più semplici
4. Più manutenibile: a fronte di una modifica basta che controllo l'unità che lo contiene, non tutto il codice.

Quando la modularità é fatta bene: quando un modulo contiene solo le parti che gli competono.
Coesione (interna): tutto il contenuto del modulo ha un compito comune.
Disaccoppiamento (esterno): un modulo deve avere pochi riferiment esterni.
L 27: Una struttura é stabile se ha una forte coesione un alto disaccoppiamento.

Information hiding (incapsulamento?): L8: Solo ciò che é nascosto può essere cambiato senza rischi.
Astrazione Fornire dei layer che offrono funzionalità senza per forza sapere come vengono implementate

Principi

Rigore
Difficile da definire rigorosamente (affidabilità di un prodotto artistico?)

Formalità
Formalità é il rendere poco possibile interpretazioni sbagliate
La fase di coding é sempre formale, ma bisogna portare la formalità anche nelle altre fasi per avere i seguenti benefici:
correttezza (una cosa formale é più facilmente verificabile)
manutenibilità (ad esempio una documentazione chiara aiuta un nuovo programmatore a capire dovemettere le mani)
riusabilità

Information hiding (incapsulamento?):
L8: Solo ciò che é nascosto può essere cambiato senza rischi.
Astrazione
Fornire dei layer che offrono funzionalità senza per forza sapere come vengono implementate
Anticipazione del cambiamento
I requisiti i un programma sono estremamente mutevoli nel tempo (rieschieste altre funzionalità, ec.)
Bisogna immaginarsi diversi scenari di possibili evoluzioni per premunirsi da possibili
sviluppi.
Generalità
Ovvero non risolvere un problema specifico, ma cercare di risolvere un caso generale che può contenre quello specifico
Incrementalità
Non consegno subito un prodotto completo, ma continuo a proporre nuove release che portano nuove funzionalità.

L2 (di Boehm): Il costo di una modifica dipende da quanto é avanzato il progetto. La maggior parte degli errori avviene nelle prime fasi di un progetto.

Secondo eXtreme Programming invece la difficoltà delle modifiche converge (grazie a delle tecniche che Boehm non aveva)

Primo approccio:
Code & Fix (utente e programmatore coincidono)
Codifica e ripara -> Tutto nella testa del programmatore
Big bang
Nessun feedback durante la fase di programmazione e alla fine consegna: big bang!

Identificare le attività di sviluppo: workflow (cosa fare)
Dividere bene in workflow
Studio di fattibilità: feasibility study
Valuto se é fattibile, che risorse impiegare, ecc. ecc.
Analisi estramente difficile (il committente é sempre impreciso)
(spesso commissionata all'esterno)
Analisi e specifica dei requisiti
Capire cosa vuole il cliente
Identificare i problemi bloccanti (stakeholder)
Quali saranno le funzionalità richieste?
Quali le qualità richieste (robustezza, ecc.)
Possibili output:
Documento contrattuale approvato dal cliente
Manuale utente (o maschere di iterazione)