Commenti all’esempio del treno

1. Commenti all’esempio del treno • Nell’esempio del treno si è iniziato dalle attività generiche che tipicamente servono per portare a termine i compiti iniziali in un qualunque modello di processo • Le considerazioni svolte si possono inquadrare nelle attività di fattibilità e/o nelle attività di determinazione dei requisiti (parzialmente coperte dall’attività comunicazioni ma, come detto, che possono sfruttare elementi di modellazione), parte della Ingegneria dei Requisiti, con considerazioni che sono tipiche della Ingegneria dei Sistemi • Rif. Pressman Cap 5 (Pratiche), Cap 6 (Ing. di Sistema), Cap 7 (Ing. dei Req.) Cap 8 (Modellazione Analitica)

2. Commenti indipendenti dalla notazione DFD • Si è osservato come la richiesta del committente non indica necessariamente in modo preciso/completo cosa si vuole ottenere dal software ma cosa si vuole ottenere dal software+ambiente • Si è osservata l’importanza di rappresentare in modo sistematico tutte le varie situazioni in cui il software dovrebbe essere coinvolto (in termini di Input ed Output) (estrazione, deduzione, acquisizione, raccogliere, identificare i requisiti) • Si è osservata l’importanza di rappresentare alternative possibili associandovi anche un tempo ed un costo (ai fini della negoziazione dei requisiti)

3. Il DFD aiuta a completare la solita matrice con le funzioni

4. Tracciabilità (§7.2.7) Rif. Funzione

5. Descrivere Requisiti determinati • Il diagramma DFD può essere usato in vari casi per descrivere requisiti ma, come detto, il diagramma potrebbe essere troppo complesso o incompleto per il committente • Tuttavia, il risultato di ciò che viene fatto anche con l’uso di strumenti quali il DFD, deve necessariamente essere presentato al committente il quale dovrebbe, in ultima analisi, prendere decisioni • I requisiti sono quindi spesso descritti anche come affermazioni in linguaggio naturale (anche se derivanti da diagrammi DFD o da altre notazioni)

6. Descrivere i Requisiti determinati: Esempio • “Il cliente che intende pagare con carta di credito deve avere la possibilità di fornire al software il numero della carta e la data di scadenza; per sviluppi futuri, deve essere possibile inserire il CIV” • Questo requisito descrive in modo testuale un flusso di dati inteso nel senso DFD

7. Commenti dipendenti dalla notazione (DFD) • Utilità della notazione • Aiuta a rappresentare (anche solo parzialmente) ciò che è interno ed esterno al software che si vuole/deve sviluppare • Aiuta a decomporre una funzione complessa in funzioni più semplici (detto anche raffinamento) • Problemi della notazione • Alcune scelte devono essere anticipate troppo e ciò può propagarsi negativamente nel resto dello sviluppo del software (propagazione dell’errore); il DFD è molto sensibile agli errori di modellazione; le alternative sono difficilmente gestibili • Quando il modello DFD diventa complesso esiste una confusione tra flussi che sono in alternativa e flussi che sono necessari per la produzione dell’output (potrebbe non essere usabile per progettare il software e neppure per descrivere i requisiti al e per il committente) • Ciò che si chiama funzione può/deve in realtà nascondere uno stato • Orientato alle funzioni e cioè alla parte meno stabile dei requisiti (poco adatto nei processi evolutivi) • Orientato alla decomposizione funzionale che non promuove il riuso • Solo i flussi di dati sono disponibili per rappresentare i legami tra terminatori (esterni), funzioni e data-store • Si deve porre attenzione ai “flussi materiali” che non dovrebbero essere parte di un DFD

8. Come rispondere ai seguenti problemi? • Quale funzione crea il biglietto in un data-store? • Come leggere la funzione Pagare o Verificare? • Quali viaggi vengono mostrati dalla funzione Ricercare? • Come si fa a rappresentare il fatto che un cliente non è contento dei viaggi proposti da Ricercare e ne vuole altri? • Come distinguere il caso in cui il biglietto non è stampato dal cliente? • Cosa accadrebbe se si aggiungessi il pagamento differito? • Se il cliente richiede di riusare i viaggi trovati ma per passeggeri diversi? • Cosa accadrebbe se si aggiungesse un programma fedeltà? • Come trattare il fatto che entrambe le funzioni Prenotare e Ricercare visualizzano sempre uno o più viaggi?

9. Soluzioni possibili • Una volta costruito, modificare il DFD usando una serie di linee guida • Combinare i DFD con l’uso di altre notazioni (ad esempio ER ma anche altro come i Casi d’Uso) • Usare notazioni diverse (ad esempio i Casi d’Uso)

10. Modificare un DFD usando linee guida • Un data-store deve essere gestito da una sola funzione • Distinguere le funzioni con flussi alternativi • Identificare funzioni simili a livelli successivi di decomposizione e farle emergere • Generalizzare il contenuto dei data-store • Etc.

11. Combinare DFD e ER • E’ possibile combinare i diagrammi DFD con i diagrammi ER (o altre notazioni per i dati): in generale, lo (gli) schema(i) ER dovrebbero riferirsi a (parte dei) data-store presenti nel DFD e vice-versa • Dalla combinazione è possibile generare tre metodi possibili: • ER, DFD (le informazioni sono più importanti) • DFD, ER (le funzioni sono più importanti) • DFD e ER insieme (funzioni e dati sono egualmente importanti)