Ingegneria del Software 3. Analisi dei requisiti Dipartimento di Informatica Università di Pisa A.A. 2014/15 l’attività di analisi • Studiare e definire il problema da risolvere • • Per identificare il prodotto da commissionare [azioni in larga parte concrete. di cui noi vedremo ben poco!!] • Per capire cosa deve essere realizzato • Per definire completamente gli accordi committente/fornitore Implicazioni economiche e sulla qualità del prodotto • La soddisfazione del committente è relativa ai requisiti • I requisiti possono essere sia espliciti sia impliciti [ad esempio, nel progetto…] quanto “costa” correggere FASE COSTO Analisi Requisiti 1 Progettazione 5 Codifica 10 Test di unità 20 Test di accettazione Operazione 50 100 [Bohem] analisi tradizionale • Studio di fattibilità • Analisi dei requisiti • • • Basata sull’uso del linguaggio naturale Specifica • Basata sull’uso di linguaggi formali o semi-formali • Funzioni, profilo operazionale Dominio, glossario, requisiti • Progettazione topdown e realizzazione analisi moderna • • Studio di fattibilità • Analisi OO • Basata su formalismi grafici • Dominio, glossario, requisiti • Collegata alla progettazione: identificazione delle classi • Progettazione OO • Utilizzo di componenti prefabbricati • Realizzazione di componenti riusabili Programmazione OO • Realizzazione parzialmente automatizzata definizione di requisito • At its most basic, a software requirement is a property that must be exhibited by something in order to solve some problem in the real world. • A product r. is a need or constraint on the software to be developed • A process r. is essentially a constraint on the development of the software • Funzionale vs. non-funzionale • Emergente vs. quantificabile • System vs. software [swebok] categorie di requisiti • Requisiti funzionali • Caratteristiche di qualità • Tradizionalmente i requisiti a cui è dato maggior valore • Una visione più ampia e moderna • Il prodotto è visto come un insieme di funzionalità • Efficienza, affidabilità, usabilità, … • Quando necessario devono essere espressi formalmente • Modelli della qualità del software • Norme per identificare le caratteristiche di qualità processare requisiti • Acquisizione • Analisi • • Specifica • • classificazione, negoziazione… intesa come documentazione: IEEE 830-1998 Validazione [azioni in larga parte concrete, di cui noi vedremo ben poco!!] [e anche in questo caso, nel progetto…] acquisizione • Interviste • • Strutturate o non strutturate • Studio di documenti • Produzione prototipi • Incontri con Questionari scritti • • • Scelte multiple, … Osservazione di futuri utenti al lavoro • committenti, utenti, responsabili marketing Casi d’uso proprietà documento d’analisi • Completo • Ben organizzato • Privo di inconsistenze • Privo di ambiguità • Privo di imprecisioni terminologiche • Privo di dettagli tecnici • Ridondanza solo tra sezioni diverse classi e negoziazione • Must have (obbligatori) • Could have (opzionali) • • • irrinunciabili per il cliente Should have (desiderabili) • Non necessari, ma utili [proposta MoSCoW] • Relativamente utili, da realizzare se c’è tempo Want to have (postponibili) • Contrattabili per successive versioni validazione (convalida) Eseguita su un documento già organizzato • Walkthrough • • • lettura sequenziale dei documenti Ispezione • lettura “strutturata” dei documenti • Esempio: tecnica del lemmario Ricerca di rimozioni, distorsioni, generalizzazioni [Noam Chomsky 1975] requisiti dai “casi d’uso” • Un attore è un’entità esterna al sistema, che interagisce con esso in un determinato ruolo • utente, altro sistema, … • Un caso d’uso è una funzionalità o servizio offerto dal sistema a uno o più attori • Uno scenario è una sequenza di interazioni (scambi di messaggi) tra sistema e attori • La collezione dei casi d’uso cattura il comportamento di un sistema, visto dall’esterno [caso d’uso come collezione di scenari] un esempio di caso d’uso • I clienti possono essere privati o società • Clienti e commerciali partecipano alla redazione dei contratti Redazione contratti Commerciale Gestione • progetti Clienti e capi-progetto partecipano alle revisioni Revisioni • Commerciali e capi-progetto gestiscono i progetti Cliente privato Società cliente Capoprogetto un altro esempio Biblioteca Prenota libro Utente della biblioteca Prendi a prestito la copia di un libro Restituisci la copia di un libro sintassi dei casi d’uso Sistema Caso d’uso • Attore: omino con nome (UpperCamelCase) (è una classe) • Associazione: senza nome • Caso d’uso: ovale con nome (UpperCamelCase) (verbo) • Sistema: rettangolo con o senza nome, contiene i casi d’uso • L’associazione attori—casi d’uso è molti a molti. • Casi d’uso senza attori solo se inclusi (included) semantica dei casi d’uso Sistema Caso d’uso • • Un attore è un utente o sistema, in un particolare ruolo Un caso d’uso è un compito (task) che gli attori eseguono con l’ausilio del sistema • L’associazione attori-casi rappresenta un’interazione (sequenza di messaggi) • Un caso d’uso è iniziato SOLO da un attore (principale) • eventualmente da un timeout descrizione narrativa • • Documento che descrive • gli scenari rilevanti di un caso d’uso • dal punto di vista degli attori Caratteristiche • Inizio, fine, passi intermedi • Condizioni eccezionali • Precondizioni, postcondizioni Modello dinamico del sistema!! scenari come istanza • • Ogni caso d’uso • ha una o più sequenze (alternative) di transizioni (normali o di base) • ha sequenze di transazioni eccezionali per gestire situazioni erronee Uno scenario è una istanza di un caso d’uso: una sequenza di azioni (una storia) che produce un risultato osservabile da uno o più attori elementi di una descrizione • Nome • Id • • Breve descrizione Attori primari • avviano il caso d’uso • Attori secondari • Pre-condizioni • Sequenze di eventi principali • Post-condizioni • Sequenza alternative di eventi • errori, ramificazioni e interruzioni nella sequenza principale • non garantiscono post-condiz. esempio di descrizione • Nome • • • • • • utente della biblioteca Attori secondari • • un utente desidera estendere il prestito su una copia di un libro Attori primari nessuno Pre-condizioni • estensione del prestito Breve descrizione • • Sequenza di eventi principali • controllare non ci siano prenotazioni • controllare stato dell’utente Post-condizioni • • l’utente ha già il libro assegnato prestito esteso, stato utente aggiornato Sequenza alternative di eventi • il libro è già stato prenotato da altri una sequenza di eventi 1. Fare a 2. Se (espressione booleana) 2.1. Fare b 3. Altrimenti 3.1. Fare c [OPZIONALE] 4. Per (espressione di iterazione) 4.1. Fare d 5. While (espressione booleana) 5.1. Fare e 5.2. Fare f generalizzazione: attori e casi d’uso Paga Cliente [usare sostituzione con cautela (no Liskov sui casi d’uso)] Paga in contanti Cliente privato [padre eventualmente astratto] generalizzazione: sequenza d’eventi 1. Fare a 2. Se (espressione booleana) 1. (1.) Fare a eredita 2. (2.) Se (espressione booleana) 2.1. Fare h nuovo 2.1. Fare b 2.2. (2.1.) Fare b 3. Altrimenti rinomina 3. Altrimenti 3.1. Fare c 3.1. (o3.1.) Fare k ridefinisce inclusione di casi d’uso <<include>> Caso d’uso 1 • La relazione include punta al caso d’uso che si include • • Caso d’uso 2 Il caso d’uso 1 incorpora l’interazione descritta dal caso d’uso 2 come parte dell’interazione che esso (1) descrive Simile ad una chiamata di funzione • La narrazione del caso 1 dovrebbe invocare l’esecuzione del caso 2 esempio d’inclusione Prendi a prestito la copia di un libro <<in clud e>> Prenota il libro Estendi il prestito • > > e d lu c n i << Sia per prendere in prestito la copia di un libro che per estenderne il prestito occorre prenotare il libro (e la prenotazione può avvenire con altre modalità) inclusione di eventi 1. Fare a 2. Fare b 3. Include (nome caso incluso) 4. Fare d • Il caso d’uso incluso è specificato come al solito • Può essere istanziabile (completo) (avviato da un attore) • O non istanziabile (eseguito solo quando incluso)
© Copyright 2024 Paperzz
