La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Ingegnerie dei Requisiti e dei Sistemi Giuseppe Berio DI-Unito 2006.

Presentazioni simili


Presentazione sul tema: "Ingegnerie dei Requisiti e dei Sistemi Giuseppe Berio DI-Unito 2006."— Transcript della presentazione:

1 Ingegnerie dei Requisiti e dei Sistemi Giuseppe Berio DI-Unito 2006

2 Ingegnerie dei Requisiti e dei Sistemi: Punti chiave Determinazione e specifica dei requisiti Relazione tra Ingegneria dei Sistemi ed Ingegneria dei Requisiti Uso delle notazioni nella Ingegneria dei Requisiti

3 Determinazione e specifica dei requisiti

4 Sistema(i), requisiti del software: una visione d’insieme Diminuire le code Cercare, Prenotare, Pagare etc. Ricerca Prenotazione Con quale sistema? Con quale software? Requisiti del software sistema = software + ambiente del software Rif. Esempio Treno

5 Una tipica matrice per la determinazione dei requisiti (o per la fattibilità) Nome assegnato idtipoprioritàrischiodescrizionefonteriftempocosto

6 Conflitti Nella moderna ingegneria del software è necessario puntare sui conflitti e sulla loro gestione La fattibilità e la determinazione dei requisiti sono attività in cui tipicamente si tratta di gestire i conflitti che possono essere di natura organizzativa (punti di vista diversi, anche del committente, tempi e costi apparentemente non compatibili con i requisiti) e di natura tecnica (esistono requisiti in contraddizione) La negoziazione è un modo di gestire i conflitti

7 Determinazione dei Requisiti (I) Obiettivo: arrivare ad una collezione, sufficientemente dettagliata, completa e condivisa tra tutti i partecipanti (stakeholder) dei requisiti che il prodotto software dovrà possedere, una volta prodotto La determinazione dei requisiti inizia da una richiesta del committente che, in generale, evidentemente, non indica necessariamente i requisiti del software da sviluppare; in particolare, non indica la distinzione tra ciò che è il software e ciò che è l’ambiente circostante al software; i requisiti si devono perciò dedurre, estrarre, identificare, elaborare, negoziare, convalidare e forse anche analizzare La collezione raccoglie e, talvolta, permette di visualizzare, in varie forme, i requisiti di cui è composta, e le relazioni tra tali requisiti Spesso tale collezione coincide con un documento dei requisiti (introdotto in seguito)

8 Determinazione dei Requisiti (II) Greenfield Engineering (GE) –Sviluppo del sistema dal nulla; I requisiti sono estratti dagli utenti e dal committente –Richiesta del committente Re-engineering (RE) –Riprogettare e reimplementare un sistema esistente con una nuova tecnologia –Richiesta del committente focalizzata sulla nuova tecnologia e che permette di identificare il sistema esistente Interface Engineering (IE) –Interagire con un sistema esistente a partire da un diverso (e nuovo) ambiente software –Richiesta del committente focalizzata sulla nuova tecnologia e che permette di identificare il sistema esistente Un misto dei tre casi precedenti

9 Determinazione dei Requisiti (Fonti dei requisiti) (III) Nelle tre precedenti situazioni (GE, RE, IE) la determinazione parte da quantità diverse d’informazione, che possiamo chiamare fonti dei requisiti e precisamente: –Nulla oppure da esperienze pregresse (non del committente) –Analisi dei sistemi esistenti attraverso la documentazione e la diretta osservazione Ma spesso si tratta di una situazione in cui è necessario –rappresentare i sistemi esistenti (reverse-engineering) e –analizzare i sistemi esistenti rappresentati onde identificare le aree ove tali sistemi non sono soddisfacenti e, quindi, –dove e come dovrebbero essere modificati (requisiti).

10 Durante la determinazione dei requisiti possono essere usati modelli (diagrammi) in qualche linguaggio di modellazione (DFD, Casi d’Uso etc.) Tali modelli (diagrammi) che potremmo qualificare come intermedi, non sono i requisiti ma servono per la determinazione di tali requisiti Spesso, tuttavia, sono indicati con il termine requisiti poiché la nozione di requisito è relativa (anche se questa relatività non è correttamente percepita e usata) Per distinguere tali modelli (diagrammi) intermedi, possiamo introdurre il termine di desiderata del software Determinazione dei Requisiti (Desiderata del Software) (VI)

11 I fruitori dei requisiti (stakeholder) La specifica dei requisiti deve comunque essere un ponte verso la realizzazione del software (progettazione e costruzione) Specifica dei requisiti Determinazione dei requisiti La determinazione dei requisiti deve comunque essere soggetta a validazione

12 I requisiti hanno sempre un doppio ruolo requisito Committente Affermazione o specifica sufficientemente precisa, anche sufficientemente comprensibile al committente Specifica sufficientemente precisa (cioè non ambigua), comprensibile a e (direttamente) usabile da progettisti e sviluppatori e, talvolta, anche al committente Progettisti, Sviluppatori, Committente equivalenti (verifica) ma presentati in modo diverso Possibile (e necessario) distinguere tra le affermazioni e la loro specifica

13 Cosa sono i requisiti Un requisito del software (sistema) è un’affermazione sul software (sistema) che riguarda proprietà, comportamenti, vincoli (di varia natura) Tali affermazioni possono riguardare come si deve comportare (requisiti funzionali), ed altre affermazioni sul software ovvero del prodotto software (requisiti non funzionali) Ma per essere requisiti, tali affermazioni dovrebbero possedere almeno alcune caratteristiche!

14 Una tassonomia dei requisiti non funzionali

15 Caratteristiche di un requisito Condiviso Non ambiguo Completo Non in conflitto Grado di priorità Grado di stabilità Grado di rischio Verificabile Manutenibile Tracciabile Traceability (IEEE) : the degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor- successor or master-subordinate relationship to one another Traceability (ISO 8402) : is the ability to trace the history, application or location of an entity by means of recorded identifications

16

17 Tre problemi da affrontare per descrivere i requisiti E’ difficile scrivere affermazioni precise in linguaggio naturale! Il ruolo di chi deve sviluppare il software è quello di aiutare il committente ad indicare affermazioni precise. E’ spesso necessario limitare, a priori, tutta la libertà che offre una descrizione testuale! E’difficile stabilire tale limite! Il ruolo di chi deve sviluppare il software è anche quello di stabilire tale limite, nel rispetto della richiesta del committente. E’ impossibile svolgere su affermazioni in linguaggio naturali analisi dettagliate sul software di cui si stanno determinando i requisiti (come nei casi ascensore e treno)

18 ambiguo ridondanteinconsistente incomprensibile incompleto espandere sintetizzare ridurre spiegare formalizzare espandere risolvere Esistono affermazioni “perfette” per i requisiti?

19

20

21

22 Esempio I Un utente deve poter inserire la sua partenza e la sua destinazione, le ore ed i giorni di partenza e di arrivo E’ possibile effettuare una ricerca sui possibili treni esistenti secondo i seguenti criteri….. Ricercare utente Treni Cosa è più comprensibile per il Committente? If Dest and Arr are available then Seleziona Treni tali che… Cosa è necessario per rispondere adeguatamente alla richiesta del Committente? Rif. Esempio Treno Dest+Arr | Dest+Arr+Hp|Ha | … Il requisito espresso in linguaggio naturale pur astrattamente ambiguo potrebbe essere accettabile sse il committente e l’ingegnere dei requisiti sono d’accordo che questo rappresenta tutte le possibili situazioni ovvero una qualunque situazione

23 Esempio II Se un sensore non funziona, il sistema dovrebbe fermare l’ascensore in funzione ai piani precedenti o successivi L’ascensore deve fermarsi se il sensore del piano selezionato rileva il passaggio dell’ascensore Fermare& Partire Sensori Ev_ascensorepiano(x) If Ev_ascensorepiano (x) and Direction=Down and ProssimaRichiesta(y) and x

24 Il documento dei requisiti Il documento dei requisiti contiene generalmente diagrammi e, collegate, affermazioni in linguaggio naturale

25 Specifica dei requisiti La specifica dei requisiti è una precisa descrizione (modello) informale, semiformale ovvero formale, di tutti requisiti, che permette di passare sistematicamente alla progettazione del software Spesso, come specifica, s’intende una descrizione informale (cioè in linguaggio naturale); ciò rende confusa la eventuale distinzione tra i requisiti ed una loro specifica La specifica può essere più o meno formale ma dovrebbe essere sempre sufficientemente precisa, completa e corretta; come vedremo, la scelta per una specifica formale è essenzialmente legata alla necessità di provare una relazione fondamentale, tra i requisiti del software, il comportamento dell’ambiente circostante il software e, ciò che è richiesto dal committente La specifica dei requisiti potrebbe essere distinta dal documento dei requisiti prodotto dalla determinazione dei requisiti ma il documento dei requisiti potrebbe contenere parte della specifica dei requisiti; in altre parole, alcune notazioni per la specifica, soprattutto quelle informali e semiformali, possono essere usate per indicare i requisiti poiché –spesso visuali e, come dice Pressman, utili nella comunicazione con il committente, in modo tale che –si abbia maggior sicurezza, prima della modellazione analitica, della comprensione comune (tra chi sviluppa e committente) dei requisiti e dell’assenza di conflitti Infatti, spesso di parla di un documento di specifica dei requisiti per indicare il documento dei requisiti e vice-versa

26 Notazioni alternative per la specifica dei requisiti

27 (Analisi Strutturata)

28 Modello Object-Oriented di Analisi (Esempio) Classi (attributi ed operazioni) Diagrammi di Sequenza Casi d’Uso Statecharts

29 Quali requisiti vengono specificati I requisiti sono di varia natura; i requisiti che vengono specificati sono: –I requisiti funzionali –Parte dei requisiti non funzionali, se necessario I requisiti funzionali indicano tipicamente le funzionalità, i comportamenti, le proprietà ovvero le informazioni desiderati I requisiti non funzionali indicano talvolta delle proprietà desiderate che devono essere soddisfatte dal prodotto software; l’interesse per i requisiti non funzionali deve essere considerato nella specifica dei requisiti funzionali (ad esempio, nel caso ascensore, se il tempo di risposta per certe richieste prioritarie deve essere inferiore a 0,01ms può obbligare a requisiti funzionali diversi)

30 Una tassonomia dei requisiti non funzionali

31 Relazione tra Ingegneria dei Sistemi ed Ingegneria dei Requisiti

32 Ingegneria del Sistema e Ingegneria dei Requisiti Richiesta del Committente In generale, riguarda un sistema di cui il software da sviluppare è parte; Documento dei Requisiti del Software Specifica dei Requisiti del Software Ipotesi sull’Ambiente circostante al Software riguarda estrarre confluire estrarre Determinare i requisiti

33 Fattibilità, Determinazione e Specifica dei Requisiti Estrarre i desiderata sul software e le ipotesi sull’ambiente Modello del processo Costi e tempi Estrarre i desiderata sul software e le ipotesi sull’ambiente fino ad ottenere i requisiti Costi e tempi Gestire i conflitti Specificare i requisiti e, se necessario, le ipotesi sull’ambiente Costi e tempi Validazione Frontiere mobili tempo

34 Sistema(i), requisiti del software: una visione d’insieme Diminuire le code Cercare, Prenotare, Pagare etc. Ricerca Prenotazione Con quale sistema? Con quale software? Requisiti del software Requisiti del sistema ove sistema = software + ambiente del software Rif. Esempio Treno

35 Sistema e Requisiti del Software: relazione fondamentale (Requisiti del Software AND Ipotesi sull’ambiente circostante il Software) SODDISFA Requisiti del Sistema dove: Sistema=Software+Ambiente circostante al software Provare formalmente?(=Verificare)

36 Organizzazione della Ingegneria del Sistema e dei Requisiti Desiderata del sistema Estrarre Requisiti del sistemaSoddisfare Estrarre Ipotesi ambiente del software Desiderata del software Estrarre Requisiti del software Ingegneria di sistema Ingegneria dei requisiti : indica generalmente una tracciabilità e ricorda la sistematicità

37 Esempio: Biglietti Treno Rivedere l’emissione dei biglietti in modo da ridurre le code agli sportelli EstrarreSviluppare un software che permetta la prenotazione e l’emissione diretta dei biglietti da parte dei passeggeri. I passeggeri useranno il software almeno nel 30% dei casi! Soddisfare? EstrarreIl cliente usa il software solo se ne percepisce l’interesse; il cliente usa il software solo se lo considera sufficientemente semplice e sicuro; il cliente usa il software solo se non lo considera troppo complesso; (il cliente usa il software solo se è in possesso di un mezzo di pagamento on- line) Scenari in cui il software può avere interesse; Casi d’Uso; (oppure DFD di contesto e suoi raffinamenti)… EstrarreDiagramma DFD finale (ottenuto per decomposizioni successive)

38 Esempio: Biglietti del Treno Si può avere una giustificazione informale che, con certe ipotesi e con certi requisiti del software, i clienti useranno il software Ma, non si può provare la relazione fondamentale!

39 Esempio: Ascensore Controllo dell’ascensore con riduzione di incidenti in generale e con possibilità della loro gestione e tempo medio di servizio di una richiesta inferiore a 3’ EstrarreSistema che permette l’interazione dei vari componenti (cioè sensori, ascensore, motore etc.). Tener presente che i componenti possono guastarsi e che si può considerare una distribuzione di chiamate per i vari piani (gli aspetti di manutenzione devono essere inclusi?) Soddisfare? Estrarre (Rappresentazione formale delle ipotesi) Velocità del motore, tempo medio di reazione dei vari componenti, guasti medi per componente, etc., e il loro comportamento Scenari in cui il software può avere interesse; Casi d’Uso; Statecharts (oppure, classi e diagrammi di sequenza) Estrarre (Rappresentazione formale dei vari scenari, completare gli statecharts etc.) Diagramma DFD esteso (con automi, state transition diagrams etc.)

40 Esempio: Ascensore Specificando formalmente le ipotesi sull’ambiente del software (ad esempio con l’uso di macchine a stato associate ai terminatori in un DFD Esteso), è possibile verificare la relazione fondamentale Il software dell’ascensore è un esempio di software reattivo cioè un sistema che, in qualche modo, reagisce sistematicamente ad eventi

41 Fattibilità, Determinazione e Specifica dei Requisiti Estrarre i desiderata sul software e le ipotesi sull’ambiente Modello del processo Costi e tempi Estrarre i desiderata sul software e le ipotesi sull’ambiente fino ad ottenere i requisiti Costi e tempi Gestire i conflitti Specificare i requisiti e, se necessario, le ipotesi sull’ambiente Costi e tempi Validazione Verifica

42 Ascensore: un caso d’Ingegneria di Prodotto L’ingegneria di prodotto (una tipologia di ingegneria dei sistemi) si pone come obiettivo finale la costruzione di un prodotto nel perseguimento di determinati obiettivi Il punto chiave è la definizione e la valutazione delle alternative per sviluppare il prodotto Ad esempio, nel caso dell’ascensore è importante dare una risposta ai seguenti quesiti: quanti sensori è necessario avere, quale manutenzione dei componenti dovrebbe essere messa in opera etc.

43 Dove si situa lo studio delle alternative per il Sistema Controllo dell’ascensore con riduzione di incidenti in generale e con possibilità della loro gestione e tempo medio di servizio delle richieste inferiore a 3’ Estrarre (Alternativa 1) Sistema che permette l’interazione dei vari componenti (cioè sensori, ascensore, motore etc.). Tener presente che i componenti possono guastarsi e che si può considerare una distribuzione di chiamate per i vari piani (gli aspetti di manutenzione devono essere inclusi?) Soddisfare? Estrarre (Alternativa 1.1) Velocità del motore, tempo medio di reazione dei vari componenti, guasti medi per componente, etc., rappresentazione formale del loro comportamento Scenari in cui il software può avere interesse; NON INTERESSA FINO A QUANDO NON SI E GIUNTI AD UNA DELLE ALTERNATIVE POSSIBILI (Una volta scelta l’alternativa, si procede alle Alternative per i requisiti del software)

44 I vari documenti da produrre Desiderata del sistema Estrarre Requisiti del sistema Soddisfare Estrarre Ipotesi ambiente del software Desiderata del software Estrarre Requisiti del software Ingegneria di sistema Ingegneria dei requisiti System definition document and System requirements document: Provare o avere sufficienti garanzie su i desiderata sul sistema Definire l’impatto del software sul sistema Software requirements specification: Provare o avere sufficienti garanzie sui desiderata sul software ovvero sui requisiti del sistema Specificare i requisiti del software

45 Contenuto dei documenti I documenti che possono essere prodotti sono in realtà molteplici: almeno tre potrebbero essere prodotti: –System definition document (SYSD) –System requirements document (SYSR) –Software requirements specification (SRS) Tuttavia, nei casi semplici, il contenuto di tali documenti è integrato in un unico documento (cioè nel Software Requirements Specification document, SRSd): –SRSd: SYSD+SYSR+SRS I linguaggi (le notazioni) usati per il contenuto di tali documenti dipendono essenzialmente dalla necessità di provare, anche matematicamente (o formalmente): –i desiderata sul sistema –la relazione fondamentale Tale necessità deriva dalla tipologia di software da costruire e dall’analisi di cosa accadrebbe se “i desiderata del sistema” non fossero veri ovvero la relazione fondamentale non fosse soddisfatta

46 La parte che descrive il sistema Si possono completare i requisiti definiti in modo testuale con i linguaggi fino a qui visti (in particolare, casi d’uso, DFD, ER, DFD estesi) Si può completare la descrizione testuale con i linguaggi fino a qui visti (in particolare, casi d’uso, DFD di contesto, ER)

47 Conclusione I due casi non sono simili! Software ascensore Software biglietti treno Sistema Ridurre le code agli sportelli! Ridurre il rischio di incidenti! Avere un tempo medio di ritorno al medesimo piano di un ascensore inferiore a 3 min Dipende se i passeggeri ne faranno uso! Dipende da vari fattori che si possono studiare poiché limitatamente soggetti al fattore del comportamento umano

48 Ingegneria del Sistema (Pressman) Comprendere il sistema (cioè i suoi requisiti) per comprendere cosa deve fare il software Per comprendere un sistema è possibile focalizzarsi su –un processo (Produzione e Lagnanze) –elementi di un prodotto (Ascensore)

49 I Sistemi Industriali I sistemi industriali sono caratterizzati, come nel caso dell’ascensore, da diversi elementi interagenti, altamente autonomi, soggetti ad errori etc. I sistemi industriali sono tuttavia caratterizzati dall’aspetto di processo sufficientemente stabile, meno presente in sistemi altamente autonomi Il software tendenzialmente controlla tale processo (fino ad un certo punto) ovvero ne supporta le fasi

50 Esempio (Sistema Industriale) Software Controllo Sistema: Produzione Ridurre il rischio di scarti! Avere un tempo medio di lavorazione per pezzo grezzo inferiore a 1’. Dipende da vari fattori che si possono studiare poiché limitatamente soggetti al fattore del comportamento umano se con riferimento ad un ambiente automatizzato di produzione (tuttavia alcuni fattori sono rilevanti come le panne medie delle macchine; gli errori di lavorazione; etc.)

51 Esempio (Sistema Industriale) Pressman propone come esempio di sistema industriale un sistema d’instradamento di scatole su nastro trasportatore Diagramma attività (UML)

52 Esempio: Produzione E’possibile rappresentare come il sistema di produzione attraverso il processo di produzione, tenendo con delle panne delle macchine e di altri dispositivi

53 Esempio: Produzione Controllo della produzione EstrarreSistema che permette l’interazione dei vari componenti. Tener presente che i componenti possono guastarsi e che si può considerare la distribuzione degli ordini per i vari pezzi, gli ordini con priorità (è esclusa la manutenzione delle macchine) Soddisfare? Estrarre (Rappresen tazione formale delle ipotesi) Comportamento dei vari componenti. Varie ipotesi come nel caso dell’ascensore. Scenari in cui il software può avere interesse; Estrarre (Rappresen tazione formale dei vari scenari e delle ipotesi) Diagramma DFD esteso

54 I Sistemi Socio-Tecnici Tuttavia non è detto che taluni obiettivi non possano essere trattati anche nei sistemi in cui l’aspetto umano è rilevante Tali sistemi sono tutti quelli in cui l’aspetto di processo è rilevante e il software dovrebbe essere un supporto a tale processo Ad esempio un sistema per il “trattamento delle lagnanze” di un generico servizio post- vendita

55 Esempio: Trattamento lagnanze E’ possibile rappresentare formalmente l’intero trattamento delle lagnanze, in modo che queste siano seguite direttamente (ad esempio, posso chiedermi quante persone servono per trattare le lagnanze) Il software può dare un supporto ad alcune attività, tra cui la classificazione delle lagnanze etc. e contribuisce, in qualche modo, ai tempi globali del processo ed al suo svolgimento.

56 Esempio: Trattamento Lagnanze Ridurre gli errori e le dimenticanze; ridurre i tempi di trattamento della singola lagnanza; migliorare la qualità del trattamento EstrarreIl sistema di trattamento delle lagnanze è costituito dal seguente processo; ma è tuttavia possibile vedere ove migliorare (ad esempio, la compilazione dei dati del cliente avviene alla vendita ovvero è il cliente stesso che li compila) Soddisfare? Estrarre (Rappresen tazione formale di “alcune” ipotesi) In azienda esiste una sufficiente competenza per trattare le lagnanze; la classificazione dei problemi possibile è particolarmente precisa etc. Scenari in cui il software può avere interesse; EstrarreDiagramma DFD

57 Uso delle notazioni nella Ingegneria dei Requisiti

58 Uso delle Notazioni nella Ingegneria dei Requisiti Metodi che aiutano a trasformare una descrizione testuale anche imprecisa in un diagramma (per estrarre, dedurre, etc. i requisiti) Metodi che aiutano a trasformare una notazione in un’altra (ed associati, metodi che aiutano a verificare la eventuale “equivalenza”): –Per passaggio, –Per incremento. Metodi di analisi che aiutano a valutare la completezza e la correttezza di ciò che è stato rappresentato tramite un diagramma (per estrarre, dedurre, etc. i requisiti) Metodi per provare formalmente la relazione fondamentale (verificare)

59 Riepilogo: Notazioni Usate Fino ad ora sono stati trattati i seguenti linguaggi: Linguaggio (notazione)Uso Diagramma dei casi d’usoScenari DFDFunzioni DFD di contestoFunzione DFD ed ERFunzioni e Dati DFD Estesi (con Statechart)Comportamento Diagramma d’attivitàProcesso di sistema

60 Riepilogo: Metodi Usati --- Analisi Strutturata (Estesa) Passaggi sistematici (ordinati) durante le attività di Ingegneria dei Requisiti nell’Analisi Strutturata (estesa): –Caso d’uso --- Casi d’uso –Casi d’uso --- DFD –DFD --- DFD –Casi d’uso --- Statechart –Statechart --- DFD estesi Un passaggio è tipicamente caratterizzato dal fatto che la rappresentazione da cui si parte è SOSTITUITA dalla nuova rappresentazione

61 Sistematizzazione dei passaggi (Metodi-Pratiche) Quelli usati: –Un Caso d’uso (passo) --- una funzione (Biglietti treno) –Un Caso d’uso --- uno stato (Ascensore) –Un Caso d’uso --- una transizione di stato (Ascensore) –Una condizione --- un evento (Ascensore)

62 Sistematizzazione dei passaggi (Metodi-Pratiche) Quelli che si potrebbero usare: –Caso d’uso --- uno Statechart –Caso d’uso --- un Diagramma d’Attività –…

63 Ciò che resta! Dopo aver (talvolta durante), raccolto, identificato,, individuato, scoperto, dedotto, elaborato, estratto etc. i requisiti del software è necessario: –Un’eventuale negoziazione ulteriore dei requisiti del software (non sempre tutto ciò che è richiesto è realizzabile ma anche persone diverse possono indicare requisiti contradditori § 7.2.4, 7.7) –La validazione (chiamata convalida in Pressman-Italiano) dei requisiti del software (non si è mai certi dei requisiti ma solo più e meno garantiti §7.2.6, 7.8) I compiti di raccolta, identificazione, individuazione scoperta, deduzione, elaborazione, estrazione etc. dei requisiti del software devono essere correttamente gestiti (§ 7.2.7)

64 Modello Object-Oriented di Analisi Si distingue dall’analisi strutturata poiché direttamente focalizzato su oggetti e relative interazioni (è detto anche modello (schema) concettuale come nelle basi di dati) Se dagli scenari (cioè dai casi d’uso) era possibile evidenziare le funzioni (osservando passo per passo), l’analisi ad oggetti propone l’analisi delle interazioni tra oggetti L’analisi ad oggetti introduce quindi un diagramma delle classi (di oggetti) come elemento fondamentale che indica come gli oggetti sono fatti Il vantaggio è evidentemente quello di poter ottenere una specifica dei requisiti in cui non sono le funzioni (e neppure le macchine a stato) a giocare un ruolo importante ma gli oggetti principali che interagendo tra loro permettono di realizzare gli scenari

65 Modello Object-Oriented di Analisi Diagramma dei casi d’uso (completati con precondizioni, postcondizioni, scenari principale ed eccezionali) Diagramma della classi (analitiche, termine di Pressman) Diagrammi delle interazioni: sequenza e collaborazione Diagrammi delle transizioni di stato (per singola classe)

66 Scenari e Diagramma delle Classi Partire Sensore Piano 1 1..* Piano numero Create( ) 1 Pulsante Stato Tempo di reazione Direzione Data controllo illuminare( ) spegnere() Porta Create () Sensore Tipo Stato Tempo di reazione Data controllo Update stato Diagnosi Configura( ) 1 1 classe: una tipologia di oggetti, con propri attributi ed operazioni nomeclasse attributi operazioni Fermare Cabina Richiesta Leggendo i passi

67 Strategie per il Diagramma delle Classi (analitiche) Per ogni caso d’uso, si definisce un diagramma delle classi, seguito da un’integrazione Per il dominio, si definisce un diagramma delle classi, seguito da incrementi (e rifattorizzazione o anche ristrutturazione) Una descrizione più o meno precisa di tutto ciò che, in qualche modo, si considera interessante per il software

68 Sistematizzazione dei passaggi (ordinati) (Metodi-Pratiche) Che usiamo: –Casi d’uso (passo) --- classi –Casi d’uso --- sequenza –Sequenza --- classi e operazioni –Precondizioni --- messaggi Che si possono usare: –Sequenza --- Statechart –Statechart --- classi, Statechart

69 Sistematizzazione degli incrementi (ordinati) (Metodi-Pratiche) Che usiamo: –Classe --- associazioni –Classe --- attributi –Classe --- operazioni Che si possono usare –Classe --- Statechart Un incremento è tipicamente caratterizzato dal fatto che la rappresentazione da cui si parte è COMPLETATA dalla nuova rappresentazione

70 Sistematizzazione degli incrementi (ordinati) (Metodi-Pratiche) Diagramma delle Classi Diagramma Casi d’UsoDiagrammi Sequenza incrementare


Scaricare ppt "Ingegnerie dei Requisiti e dei Sistemi Giuseppe Berio DI-Unito 2006."

Presentazioni simili


Annunci Google