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)

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 (Casi d’Uso) aiuta a rappresentare in modo sistematico tutte le varie situazioni in cui il software dovrebbe essere coinvolto (in termini di Scenari) (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)

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

Tracciabilità (§7.2.7) Ridurre CodeFar usare il software ai clienti Acquistare CC WEB (CU1) +++- 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 I casi d’uso possono quindi essere usati per raggruppare, consistentemente, anche se i requisiti sono anche in tal caso descritti come 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 (AcquistareCartaCreditoWEB)

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 2.Aiuta a decomporre uno scenario complesso in scenari più semplici che, tuttavia, possono essere riusati per descrivere altre 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.Anche la composizione di casi d’uso (bottom-up) è interessante 4.Permette di rimandare le scelte ed è, quindi, meno soggetto ad errori rispetto a DFD 5.Le pre e post-condizioni aiutano nella validazione per le descrizioni degli scenari 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 su come descrivere i singoli passi negli scenari (ad esempio, i passi possono essere unilaterali o collaborativi) 4.Non permette di capire in modo preciso se tutte le informazioni sono disponibili (evidente in un DFD) 5.In mancanza d’esperienza, la notazione potrebbe essere usata per rappresentare delle funzioni (nel senso DFD)

Come rispondere ai seguenti problemi? 1.A cosa corrisponde uno scenario? Ha un modello matematico associato? Non è certamente un algoritmo in senso stretto! Ad esempio, la creazione del biglietto potrebbe essere omesso come passo nel caso “confermainteresse”; i flussi eccezionali non sono trattati sempre nello stesso modo (ma alcune eccezioni potrebbero omettersi – ad esempio, “software smette di funzionare”) 2.Ad esempio, un caso d’uso come insieme di scenari può essere descritto anche solo con pre e post-condizioni ma, comunque, non è chiaro quanto debbano essere tali condizioni. 3.Ad esempio nel caso d’uso “ricercare e presentare” il passo “inserire partenza, arrivo etc.” non è evidente il significato; è il cliente che scrive (rendering locale) oppure il fatto che i dati sono inviati etc. 4.E’ vero che le informazioni sono tutte disponibili per contattare il cliente se questo non riceve conferma della creazione del biglietto? 5.Ma il caso d’uso “ricercare e presentare” è simile (o uguale) alla funzione “ricercare” introdotta nel DFD?

Soluzioni possibili 1. (4) E’ possibile combinare i casi d’uso con i DFD anche se ciò non è generalmente usato: –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) 2. (5) E’ di fondamentale importanza considerare il fatto che un caso d’uso deve creare qualcosa d’interesse per il suo attore principale 3. (1,2,3) Definire metodologie con linee guida molto precise per passare dai requisiti alla specifica dei requisiti e, quindi, per la progettazione del software, combinando casi d’uso con altre notazioni

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