Ingegneria del Software (Ing.Informatica Nuovo Ord.) Canale M-Z / A.A Marco Cadoli

Transcript

1 Ingegneria del Software (Ing.Informatica Nuovo Ord.) Canale M-Z / A.A Marco Cadoli Università di Roma La Sapienza Dipartimento di Informatica e Sistemistica TERZA PARTE Analisi dei requisiti e definizione delle specifiche Sezione I: Concetti fondamentali Versione definitiva Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

2 TERZA PARTE Analisi e specifica dei requisiti I. Concetti fondamentali dell analisi e specifica dei requisiti II. Complementi di UML Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

3 I. Concetti fondamentali I.1. Il concetto di specifica I.2. Tipologie di linguaggi di specifica I.3. Ingegneria dei requisiti Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

4 I.1. Il concetto di specifica Vari tipi di specifiche Documenti di SRS Approcci principali Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

5 Vari tipi di specifiche Dei requisiti (fra lo studio di fattibilità e la progettazione): Documenti che definiscono cosa deve fare il sistema Accordo fra cliente e sviluppatore Di progetto (durante la progettazione): Documenti che definiscono i requisiti del progetto Accordo fra i progettisti e gli implementatori Di un modulo SW (durante la realizzazione): Documento che definisce cosa deve fare un modulo SW Accordo fra gli implementatori del modulo e i programmatori che lo useranno Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

6 Scopi: Specifica dei requisiti Definizione delle funzionalità, vincoli, prestazioni, interfacce, e di qualsiasi altra caratteristica richiesta dall utente Redazione di un documento di Specifica dei Requisiti SW (SRS Software Requirements Specification) che sia completo, preciso, consistente, non ambiguo, comprensibile sia al committente sia allo sviluppatore (Tipicamente) Piano di test, struttura manuale utente Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

7 Importanza di un documento di SRS Costituisce il punto di convergenza dei punti di vista del cliente, dell utente e dello sviluppatore Fornisce il punto di riferimento per la convalida del prodotto finale È un prerequisito per la qualità del SW (errori nel SRS errori nel sistema) Tipicamente, riduce i costi di sviluppo, in quanto facilita la scoperta di difetti Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

8 Approcci all analisi e alla specifica dei Informale: requisiti Uso del linguaggio naturale Interviste col cliente e l utente finale Uso di questionari Non esiste modello del sistema Basato su modelli concettuali: Rappresentazioni del dominio e del sistema inserite nel documento di SRS Possono essere più o meno formali Basato sulla prototipazione Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

9 Alcuni approcci basati su modelli concettuali Analisi strutturata: Data Flow Diagrams (DFD), dizionario dei dati Decomposizione delle funzioni Linguaggi ad hoc per i dati (ad es. ER) Analisi orientata agli oggetti: Decomposizione in concetti del dominio applicativo Linguaggi di modellazione (ad es. UML) Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

10 I.2. Tipologie di linguaggi di specifica Specifiche operazionali e descrittive DFD Automi a stati finiti Reti di Petri Specifiche formali, semiformali e informali Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

11 Tipologie di linguaggi di specifica I linguaggi di specifica possono essere classificati rispetto a due coordinate indipendenti 1. Modello (stile) di specifica descrittivo operazionale 2. Semantica del linguaggio specifiche informali specifiche semiformali specifiche formali Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

12 Stili di specifica: operazionale La specifica operazionale descrive il comportamento desiderato per il sistema Esempio (ordinamento di un vettore): Sia A un vettore di n elementi. Il risultato dell ordinamento di A è un vettore B di n elementi in cui: il primo elemento è il minimo di A (se più elementi di A hanno lo stesso valore, ognuno di essi è accettabile), il secondo elemento è il minimo nel vettore di n-1 elementi ottenuto da A eliminando il suo minimo il terzo elemento e i successivi si definiscono allo stesso modo, fino a quando vengono eliminati tutti gli elementi di A Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

13 Stili di specifica: descrittiva La specifica operazionale descrive le proprietà desiderate in maniera puramente dichiarativa Esempio (ordinamento di un vettore): Sia A un vettore di n elementi. Il risultato dell ordinamento di A è un vettore B di n elementi tale che: È una permutazione di A È ordinato (nel caso in cui il concetto di permutazione e di ordinamento non fossero sufficientemente chiari, andrebbero specificati con lo stesso stile) Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

14 Considerazioni sugli stili di specifica Con riferimento all esempio precedente, ognuno degli stili (operazionale/descrittivo) suggerisce una maniera differente di implementare l ordinamento Non è comunque obbligatorio implementare l ordinamento in alcuna delle maniere (anche se lo stile operazionale ne suggerisce fortemente una) Le specifiche descrittive sono tipicamente più astratte di quelle operazionali Le specifiche descrittive possono condurre ad implementazioni meno efficienti di quelle operazionali Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

15 Esempio di modello operazionale: DFD I DFD (Data Flow Diagrams) sono notazioni molto usate per specificare le funzioni di un sistema informativo Hanno quattro elementi di base: Funzioni Gestione clienti Flussi di dati Depositi di informazioni Info CLIENTI Acquisizione e produzione di dati Operatore Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

16 Esempio di diagramma DFD Calcolo di: (a + b) * (c + a*d) b + IN d a * * OUT c + Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

17 Altro esempio di diagramma DFD Info ARTICOLI gestione Fatture Operatore gestione Clienti Info FATTURE Info CLIENTI visualizzazione e stampa fatture Operatore Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

18 Commenti sui diagrammi DFD Un diagramma DFD può essere raffinato, ad esempio specificando meglio la funzione Gestione fatture La semantica dei simboli usati è specificata solamente dagli identificatori scelti In alcuni casi (ad es., + ) ciò è sufficiente, mentre in altri è necessaria una definizione più precisa (che non fa parte del DFD) Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

19 Commenti sui diagrammi DFD (2) A B C D E F Non vengono definiti aspetti relativi al controllo, ad esempio: D ha bisogno di A, B e C per essere eseguita, o può esserlo quando è presente almeno uno dei tre? D produce output sia per E sia per F, o solo per uno dei due? Nel primo caso, D produce lo stesso output per E ed F? Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

20 Commenti sui diagrammi DFD (3) I diagrammi DFD sono un esempio di specifica semiformale: La sintassi è definita in maniera precisa La semantica non è definita in maniera precisa Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

21 Esercizio 1 Una biblioteca pubblica eroga due servizi: prestito di libri (comunicando titolo e autore) e ricerca di titoli (comunicando argomento) 1. Tracciare il diagramma DFD del sistema informativo della biblioteca 2. Tenendo conto che per prestare un libro occorre prima cercarlo negli scaffali, raffinare il diagramma ottenuto Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

22 Un altro modello operazionale: Automi a stati finiti In un ASF si definiscono gli stati ammissibili del sistema, gli ingressi ammissibili e le possibili transizioni: S è l insieme (finito e non vuoto) degli stati I è l insieme degli ingressi d è la funzione di transizione che calcola il nuovo stato S X I S Esempio: lampadina da tavolo (2 stati, 1 input) Premi interruttore On Off Premi interruttore Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

23 Automi a stati finiti con output Vengono definiti anche possibili segnali di output Grafo orientato : <S,I,U,d,t, s 0 > S è l insieme (finito e non vuoto) degli stati I è l insieme degli ingressi U è l insieme delle uscite d è la funzione di transizione che calcola il nuovo stato S X I S t è la funzione che calcola l uscita S X I U s 0 è lo stato iniziale Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

24 Esempio di ASF con output Un apparecchio telefonico posto in un ufficio può effettuare: chiamate interne (numeri di almeno una cifra, la cui prima cifra non è 0), o chiamate esterne (numeri di almeno due cifre, la cui prima cifra è 0 e la seconda non è 0) Quando: si solleva il telefono, si ottiene un tono di centralino interno; si digita 0 come prima cifra, si ottiene un tono di centralino esterno; si raggiunge un numero telefonico esistente si ottiene un segnale libero o occupato, a seconda dei casi In ogni momento è possibile riagganciare Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

25 Esempio di ASF con output (2) Nove stati: 1. Telefono riagganciato (stato iniziale) 2. Attesa prima cifra 3. Attesa prima cifra esterna 4. Attesa successiva cifra interna 5. Attesa successiva cifra esterna 6. Attesa collegamento 7. Conversazione impossibile 8. Telefono ricevente che squilla 9. Dialogo Sedici input: 1. sollevamento ricevitore 2. riaggancio 3. raggiunto numero esistente 4. telefono occupato 5. telefono libero 6. sollevamento ricevitore chiamato le dieci cifre 0..9 Quattro output: 1. tono centralino interno 2. tono centralino esterno 3. segnale occupato 4. segnale libero Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

26 Telefono riagganciato 1..9/- riaggancio/- sollevamento ricevitore/ tono centralino interno 0/tono centralino esterno Attesa prima cifra riaggancio/- riaggancio/- Attesa prima cifra esterna Attesa successiva cifra interna riaggancio/- riaggancio/- Attesa prossima cifra esterna 1..9/- raggiunto numero esistente/ 0..9/- 0..9/- Conversazione impossibile Attesa collegamento telefono occupato/ segnale occupato telefono libero/ segnale libero Telefono ricevente che squilla raggiunto numero esistente/- riaggancio/- sollevamento ricevitore chiamato/- riaggancio/- riaggancio/- Dialogo Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

27 Esercizio 2 Riprogettare l ASF prendendo in considerazione che: un numero telefonico esterno deve essere composto di almeno tre cifre, e che un numero telefonico interno deve essere composto esattamente di due cifre Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

28 Commenti sugli ASF Gli automi a stati finiti sono un esempio di specifica formale (sintassi e semantica definite in maniera precisa) Sono particolarmente adatti per la descrizione del flusso di controllo (che manca nei DFD) Gli ASF sono spesso usati per la specifica di insiemi di stringhe (concetto di stato iniziale e finale) Hanno come limite la finitezza della memoria Non sono pratici se il numero di stati è troppo grande Sono adatti per la descrizione di sistemi sincroni e non concorrenti (ad ogni istante di tempo lo stato globale del sistema deve essere definito, e può occorrere una sola transizione) Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

29 Esercizio 3 Progettare un ASF che riconosce una stringa avente tutte le seguenti caratteristiche: Contiene un numero pari di 0 Contiene un numero dispari di 1 Inizia con 1 Termina con 0 Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

30 Reti di Petri: Specifica operazionale di sistemi asincroni Reti di Petri formalismo per la specifica di sistemi con attività concorrenti e/o parallele. Sono un esempio di specifica formale e operazionale Rappresentazione grafica, intuitiva. Posti: attività Transizioni: inizio/termine di attività Marcatura: stato delle attività Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

31 Esempio: studente che risolve esercizi posto Risolvere esercizio transizione Scrivere soluzione Libro a posto Confrontare soluzione. Leggere esercizio Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

32 posto con gettone Risolvere esercizio Stato: marcatura di posti transizione non abilitata transizione scattata Risolvere esercizio Scrivere soluzione Libro a posto Scrivere soluzione Libro a posto Confrontare soluzione. Leggere esercizio Confrontare soluzione. Leggere esercizio transizione abilitata transizione abilitata Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

33 Non determinismo nelle reti di Petri In ogni istante, può scattare una qualunque delle transizioni abilitate Nella rete non viene rappresentato: quale transizione scatti quando scatti Evoluzione di una rete di Petri: sequenza delle transizioni che scattano Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

34 Studente A: ha risolto Due studenti, un libro Studente B: ha scritto la soluzione A potrebbe scrivere la soluzione B potrebbe confrontare la soluzione Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

35 Concorrenza e mutua esclusione 2 transizioni abilitate: Non si impediscono a vicenda concorrenti (es., le due dell esempio precedente) Possono continuare in mutua esclusione in conflitto (es., le due risultanti dallo stato in cui scatta quella di sinistra) Politica di scheduling: regola per l assegnazione di risorse a transizioni in conflitto (esterna, non rappresentata nella rete di Petri) Politica unfair un processo è in starvation (non ha mai la risorsa necessaria) Deadlock (stallo) nessuna transizione è abilitata Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

36 Esercizio 4 Con riferimento all ultima rete di Petri: Si può verificare uno stallo? Se ciò non è possibile, modificarla in maniera tale che ammetta stalli, e specificare in quali casi si possono verificare. Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

37 Esempio di modello descrittivo: Modello Entità Relazione Cliente 1,N 1,1 Articolo Fattura 1,N 1,N desc aliquota costo n.pezzi #fattura data emissione data pagamento Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

38 Semantica dei linguaggi Specifiche informali Tipicamente, linguaggio naturale (è accessibile al committente) Specifiche semiformali Immediatamente comprensibili, ma ambigue Notazioni grafiche accompagnate da linguaggio naturale Sono i modelli più usati allo stato dell arte Specifiche formali Eliminazione ambiguità Possibile verifica automatica di proprietà Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

39 Riassunto esempi linguaggi di specifica Semantica/ Stile Operazionale Descritttivo Semiformale DFD Diagramma classi UML Formale ASF, Reti di Petri ER Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

40 I.3. Ingegneria dei requisiti Ciclo di vita dei requisiti Caratteristiche di un buon documento di SRS Standard IEEE e struttura di un documento di SRS Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

41 Ciclo di vita dei requisiti 1. Analisi del problema Comprensione del problema, delle condizioni di risoluzione e dei vincoli a partire da una definizione generale delle necessità dei potenziali utenti. Scopo: comprendere cosa deve fare il sistema software che si vuole costruire. 2. Specifica dei requisiti Trasformazione dei requisiti in un documento di specifiche tecniche e funzionali caratterizzanti il sistema 3. Convalida delle specifiche Revisione delle specifiche, effettuata anche con l utente/committente. Nota: tipicamente, non è un ciclo di vita a cascata, ma iterativo Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

42 Caratteristiche di un buon documento di SRS 1. Non ambiguità Ogni requisito ha una sola interpretazione Esempio di frammento di specifica (di un word processor): La selezione è il processo di scelta di aree del documento su cui si desidera agire, ad esempio la selezione di un testo per renderlo nello stile italico. Ambiguità: per area del documento si intende: sequenza contigua di caratteri, oppure unione di sequenze contigue di caratteri? Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

43 Caratteristiche di un buon documento di SRS (2) 2. Consistenza Nessun requisito è in contraddizione con gli altri Esempio di frammento di specifica (di un word processor): A. Il testo deve avere linee di uguale lunghezza, decisa dall utente B. L andata a capo può avvenire solamente alla fine di una parola Inconsistenza: cosa deve avvenire se una parola è più lunga della lunghezza specificata? A la parola va spezzata B la parola non va spezzata Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

44 Caratteristiche di un buon documento 3. Completezza di SRS (3) Interna: ogni concetto introdotto deve essere definito. Esempio: se non ci sono richieste, l ascensore entra in uno stato di attesa richiesta La specifica deve definire il concetto di stato di attesa richiesta ( glossario) Rispetto ai requisiti: tutti i requisiti devono essere documentati. Esempio: Se vogliamo che l ascensore senza richieste vada al piano terra ed apra le porte, dobbiamo affermarlo esplicitamente Nota: la completezza è spesso ottenibile solo incrementalmente: Sono necessari troppi dettagli Alcuni requisiti emergono nel corso del lavoro Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

45 Caratteristiche di un buon documento di SRS (4) 4. Correttezza Il documento rappresenta fedelmente le informazioni da modellare 5. Verificabilità È possibile stabilire se il prodotto sw rispetta i requisiti Richiede la non ambiguità dei requisiti. Esempi di requisiti non verificabili: tipicamente deve avvenire che, l interfaccia grafica deve essere di buona qualità. Esempio di requisito verificabile: Il programma deve produrre l output entro 20 nel 60% dei casi; deve produrre l output entro 30 nel 100% dei casi Nel caso di specifiche formali, alcune proprietà sono verificabili in modo rigoroso, per esempio la consistenza Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

46 Caratteristiche di un buon documento di SRS (5) 6. Classificazione per importanza Ad esempio: essenziale, condizionale/non pregiudica l accettazione opzionale Aiuta i clienti a capire cosa è per loro veramente importante Aiuta gli sviluppatori a compiere corrette decisioni progettuali Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

47 Caratteristiche di un buon documento di SRS (6) 7. Modificabilità La struttura e lo stile dell SRS sono tali da consentire facili modifiche, preservando consistenza e completezza. Note: Deve avere un organizzazione coerente, con indice, indice analitico, riferimenti incrociati Un documento di SRS ridondante non si modifica facilmente Ogni requisito dovrebbe essere espresso separatamente Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

48 Caratteristiche di un buon documento 8. Tracciabilità di SRS (7) Chiarezza dell origine di ciascun requisito. Possibilità di referenza nello sviluppo futuro Matrici di tracciabilità per la gestione dei requisiti (ad es., funzionalità/requisiti) Forward traceability: ogni requisito è collegabile a qualche elemento del progetto e del codice Backward traceability: dal progetto e dal codice è possibile risalire al requisito corrispondente Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

49 Struttura di un documento di SRS Lo standard IEEE fornisce esempi della struttura di un documento SRS: Table of contents 1.Introduction 1.1. Purpose 1.2. Scope 1.3. Definitions, Acronyms, and Abbreviations 1.4. References 1.5. Overview 2.General Description 2.1. Product Perspective 2.2. Product Functions 2.3. User Characteristics 2.4. General Constraints 2.5. Assumptions and Dependencies Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

50 Struttura di un documento di SRS (2) 3.Specific Requirements 3.1. External Interface Requirements User Interfaces Hardware Interfaces Software Interfaces Communications Interfaces 3.2. Functional Requirements / Objects 3.3. Performances Requirements 3.4. Logical database requirements 3.5. Design Constraints Standard Compliance Hardware Limitation 3.6. Attributes Reliability 3.7. Other Requirements 4. Appendixes Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

51 Struttura di un documento di SRS (3) 3.2. Class/Object Class/Object Attributes Attribute Functions (methods) Functional requirement Messages (received or sent) Class/Object 2 Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

52 Soluzione esercizi parte 3, sezione 1 Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

53 Soluzione esercizio 1 Scaffali Titolo e autore del libro; nome cittadino Richiesta libro dal cittadino Lista autori Lista titoli Autore Titolo Titolo Libro Prendi un libro Ricerca tramite argomenti Libro Lista titoli che si riferiscono all argomento Titolo del libro; nome cittadino Consegna libro Lista libri in prestito Lista argomenti Argomento Richiesta argomento dal cittadino Mostra titoli Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov

54 Soluzione esercizio 1 (2) Scaffali Libro Prendi un libro Libro Consegna libro Lista autori Lista titoli Autore Titolo Trova posizione di un libro Scaffale e posizione Titolo del libro; nome cittadino Lista libri in prestito Titolo e autore del libro; nome cittadino Richiesta libro dal cittadino Ing. del SW: Terza parte Sez I Marco Cadoli, Università La Sapienza, nov