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)

Commenti indipendenti dalla notazione 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)

I casi d’uso aiutano a completare la matrice Caso d’Uso idtipoprioritàrischiodescrizionefonteriftempocosto CU11BassaAltoTestoInterv sita del… G 1, … Tasks1000 Scenario (Passo)

Tracciabilità (§7.2.7) Ridurre CodeFar usare il software ai clienti Pagare CC - Casa (CU1) +++- Pagare CC - Stazione -+ Caso d’Uso Rif.

Descrivere Requisiti Il diagramma Casi d’Uso può essere usato in vari casi per descrivere requisiti; a differenza dei DFD, il diagramma potrebbe essere non troppo complesso per il committente e potrebbe costituire un utile strumento di presentazione degli scenari (associati ai casi) Infatti, i casi d’uso come insiemi di scenari raggruppano, consistentemente, affermazioni in linguaggio naturale usate per descrivere gli scenari

Descrivere i Requisiti: Esempio “Il cliente che intende pagare con carta di credito inserisce il numero della carta e la data di scadenza; per sviluppi futuri, deve essere possibile inserire il CIV” Questo requisito descrive in modo naturale uno passo di uno scenario di un caso d’uso (Pagare CC ed in particolare quelli di Pagare CC – Casa e Pagare CC - Stazione)

Commenti dipendenti dalla notazione (Casi d’Uso) 1.Utilità della notazione 1.Aiuta a rappresentare (anche solo parzialmente) ciò che è interno ed esterno al software che si vuole/deve sviluppare (attori e pre e post condizioni) 2.Aiuta a decomporre uno scenario complesso in scenari più semplici che potrebbero essere riusati per descrivere altri scenari; ogni caso d’uso è orientato a produrre risultati d’interesse per l’attore principale, utile linea guida durante la costruzione di un diagramma (e quindi i casi d’uso dovrebbe essere fortemente indipendenti, anche temporalmente) 3.Permette di rimandare le scelte ed è, quindi, meno soggetto ad errori rispetto a DFD 4.Le pre e post-condizioni aiutano nella verifica e validazione per gli scenari descritti 2.Problemi della notazione 1.Non ha fondamenti teorici (ed è quindi parzialmente inadatta alla specifica dei requisiti) 2.La descrizione degli scenari non è standardizzata (quanti e quali passi o pre-post condizioni) 3.C’è una generale confusione sul significato dei singoli passi negli scenari (ad esempio, i passi possono essere unilaterali o collaborativi o a cosa il passo corrisponde effettivamente) 4.Non permette di capire in modo preciso se tutte le informazioni sono disponibili (evidente in un DFD) affinché un passo abbia senso 5.In mancanza d’esperienza, la notazione potrebbe essere usata per rappresentare delle funzioni (nel senso DFD) focalizzandosi anche troppo sul diagramma

Come rispondere ai seguenti problemi? 1.Un caso d’uso come insieme di scenari può essere descritto anche solo con pre e post-condizioni ma, comunque, non è evidente quante e quali essere tali condizioni. 1.Nel caso d’uso “ricercare” il passo “inserire partenza, arrivo etc.” non è evidente il significato; è il cliente che scrive (rendering locale) oppure il fatto che i dati sono inviati e controllati etc.; nel caso “prenotare” non è chiaro cosa s’intende per Cercare Disponibilità; nella creazione del biglietto potrebbe essere omesso come passo “confermare l’acquisto”; 2.Se non fosse stato indicato nel creare biglietto la pre-condizione “se il viaggio prevede una prenotazione questa è stata fatta” si poteva pensare nel caso “crearebiglietto” alcuni scenari che prevedono la prenotazione; 3.i flussi eccezionali non sono trattati sempre nello stesso modo (ma alcune eccezioni potrebbero omettersi – ad esempio, “se il cliente non inserisce partenza o arrivo corretti per 3 volte” perché considerata non importante) 4.E’ vero che le informazioni sono tutte disponibili per contattare il cliente nel caso “PagareCC”? 5.Difficile avere una visione d’insieme se non combinando pre e post condizioni. 2.A cosa corrisponde uno scenario o un insieme di scenari? Ha un modello matematico associato? Non è certamente un algoritmo in senso stretto! 3.Ma il caso d’uso “ricercare” è simile (o uguale) alla funzione “ricercare” introdotta nel DFD?

Soluzioni possibili 1.(1) Definire metodologie con linee guida molto precise con particolare uso di pre e post condizioni 2.(1.4) E’ possibile combinare i casi d’uso con i DFD anche se ciò non è generalmente usato (si perde la strutturazione di pre e post-condizioni, il DFD tende a diventare incomprensibile): –DFD di contesto e poi Casi d’uso –Casi d’uso e poi DFD per ogni singolo passo negli scenari (anche se si tende a non fare: il DFD probabilmente soffrirebbe dei problemi precedentemente identificati) 3.(1.5, 2) E’ possibile passare dai casi d’uso ad altre notazioni in modo da incrementare la precisione di ciò che è espresso dai casi d’uso stessi 4.(3) E’ di fondamentale importanza considerare il fatto che un caso d’uso deve creare qualcosa d’interesse per l’attore principale e che quindi non sono né troppo complesse né troppo semplici come tendono ad essere le funzioni

Ad un passo di un caso d’uso possono essere associati funzioni e flussi di dati Inserire dati… (Il software) crea il biglietto (Il software) crea ed invia un… (Il software) ricerca