Commenti all’esempio del treno Nell’esempio del treno si è iniziato dalle attività generiche e/o attività operative che tipicamente costituiscono i passi.

Presentazione sul tema: "Commenti all’esempio del treno Nell’esempio del treno si è iniziato dalle attività generiche e/o attività operative che tipicamente costituiscono i passi."— Transcript della presentazione:

1 Commenti all’esempio del treno Nell’esempio del treno si è iniziato dalle attività generiche e/o attività operative che tipicamente costituiscono i passi 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. Del Sistema), Cap 7 (Ing. Dei Req.) Cap 8 (Modellazione Analitica)

2 Commenti indipendenti dalla notazione Si è iniziato lo svolgimento di attività quali la fattibilità e la determinazione dei requisiti Si è osservato come la richiesta del committente non indica necessariamente in modo preciso cosa si vuole ottenere dal software ma cosa si vuole ottenere dal software+ambiente Si è osservato come la notazione (DFD) aiuta a 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 è osservato come la notazione permette di mostrare parzialmente ed analizzare le alternative possibili (associandovi un costo e un tempo) ed escludere quelle non accettate dal committente (sia per tempi e costi sia per altri motivi), gestendo anche i conflitti interni (negoziazione dei requisiti)

3 Il DFD aiuta a completare la matrice Funzioneidtipoprioritàrischiodescrizionefonteriftempocosto F1BassaAltoTesto|DFDInterv sita del… G 1, … Tasks1000

4 Tracciabilità (§7.2.7) Ridurre CodeFar usare il software ai clienti Pagare CC+++- Funzione Rif.

5 Descrivere Requisiti Il diagramma DFD può essere usato in vari casi per descrivere requisiti ma, come detto, il diagramma potrebbe essere troppo complesso 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 come affermazioni in linguaggio naturale (anche se derivanti da diagrammi DFD o da altre notazioni)

6 Descrivere i Requisiti: 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 requisiti descrive in modo naturale un flusso di dati inteso nel senso DFD

7 Commenti dipendenti dalla notazione (DFD) 1.Utilità della notazione 1.Aiuta a rappresentare (anche solo parzialmente) ciò che è interno ed esterno al software che si vuole/deve sviluppare 2.Aiuta a decomporre una funzione complessa in funzioni più semplici (detto anche raffinamento) 2.Problemi della notazione 1.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; 2.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) 3.Ciò che si chiama funzione può in realtà nascondere uno stato 4.Orientato alle funzioni e cioè alla parte meno stabile dei requisiti (poco adatto nei processi evolutivi) 5.Orientato alla decomposizione funzionale che non promuove il riuso 6.Solo i flussi di dati sono disponibili per rappresentare i legami tra terminatori (esterni), funzioni e data-store 7.Si deve porre attenzione ai “flussi materiali” che non dovrebbero essere parte di un DFD

8 Come rispondere ai seguenti problemi? 1.Quale funzione crea il biglietto in un data-store? 2.Come leggere la funzione ValutareCosto? 3.Se il cliente richiede di riusare i viaggi trovati ma per passeggeri diversi? 4.Cosa accadrebbe al data-store biglietti se si aggiungesse un programma fedeltà? 5.Cosa accadrebbe se entrambe le funzioni ValutareDisponibilità&Costo e ValutareCosto potessero visualizzare il costo? 6.Come si fa a rappresentare il fatto che un cliente non è contento dei viaggi proposti da Ricercare e ne vuole altri? 7.Il biglietto inteso come “stampa o copia cartacea” non dovrebbe essere incluso (non permettendo di rappresentare che il biglietto arriva al cliente)

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)