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

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

Determinazione e specifica dei requisiti

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

Una tipica matrice per la determinazione dei requisiti (o per la fattibilità) Nome assegnato id tipo priorità rischio descrizione fonte rif tempo costo

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

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)

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 Un misto dei tre casi precedenti

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).

Determinazione dei Requisiti (Desiderata del Software) (VI) 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

I fruitori dei requisiti (stakeholder) La determinazione dei requisiti deve comunque essere soggetta a validazione Determinazione dei requisiti C l i e n t m a g r s S y d - u o c h f w v p R q Specifica dei requisiti La specifica dei requisiti deve comunque essere un ponte verso la realizzazione del software (progettazione e costruzione)

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

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!

Una tassonomia dei requisiti non funzionali

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

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)

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

Esempio I Cosa è più comprensibile per il Committente? 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….. Cosa è necessario per rispondere adeguatamente alla richiesta del Committente? 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 Ricercare utente Dest+Arr | Dest+Arr+Hp|Ha | … Treni If Dest and Arr are available then Seleziona Treni tali che… Rif. Esempio Treno

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 If Ev_ascensorepiano(x) and Direction=Down and ProssimaRichiesta(y) and x<y then Rallentare Motore; … Fermare& Partire Sensori Ev_ascensorepiano(x) If Ev_ascensorepiano(x) and ProssimaRichiesta(y) and x=y then Rallentare Motore; … Rif. Esempio Ascensore

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

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

Notazioni alternative per la specifica dei requisiti

(Analisi Strutturata)

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

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)

Una tassonomia dei requisiti non funzionali

Relazione tra Ingegneria dei Sistemi ed Ingegneria dei Requisiti

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

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

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

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

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

Esempio: Biglietti Treno Rivedere l’emissione dei biglietti in modo da ridurre le code agli sportelli Estrarre Sviluppare 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? Il 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)… Diagramma DFD finale (ottenuto per decomposizioni successive)

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!

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’ Estrarre 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 (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.)

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

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

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.

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)

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

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

La parte che descrive il sistema Si può completare la descrizione testuale con i linguaggi fino a qui visti (in particolare, casi d’uso, DFD di contesto, ER) 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)

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

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)

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

Esempio (Sistema Industriale) Sistema: Produzione Software Controllo 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.)

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

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

Esempio: Produzione Controllo della produzione Estrarre Sistema 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 (Rappresentazione formale delle ipotesi) Comportamento dei vari componenti. Varie ipotesi come nel caso dell’ascensore. Scenari in cui il software può avere interesse; Estrarre (Rappresentazione formale dei vari scenari e delle ipotesi) Diagramma DFD esteso

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

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.

Esempio: Trattamento Lagnanze Ridurre gli errori e le dimenticanze; ridurre i tempi di trattamento della singola lagnanza; migliorare la qualità del trattamento Estrarre Il 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 (Rappresentazione 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; Diagramma DFD

Uso delle notazioni nella Ingegneria dei Requisiti

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)

Riepilogo: Notazioni Usate Fino ad ora sono stati trattati i seguenti linguaggi: Linguaggio (notazione) Uso Diagramma dei casi d’uso Scenari DFD Funzioni DFD di contesto Funzione DFD ed ER Funzioni e Dati DFD Estesi (con Statechart) Comportamento Diagramma d’attività Processo di sistema

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

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)

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

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)

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

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)

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

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

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

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

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