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

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

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– Richiesta del committente focalizzata sulla nuova tecnologia e che

permette di identificare il sistema esistente• 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).

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

I fruitori dei requisiti (stakeholder)

Client managersSystem end-usersClient engineersContractor managersSystem architects

System end-usersClient engineersSystem architectsSoftware developers

Requirementsdefinition

Requirementsspecification

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

I requisiti hanno sempre un doppio ruolo

requisitoCommittente

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

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

Performancerequirements

Spacerequirements

Usabilityrequirements

Efficiencyrequirements

Reliabilityrequirements

Portabilityrequirements

Interoperabilityrequirements

Ethicalrequirements

Legislativerequirements

Implementationrequirements

Standardsrequirements

Deliveryrequirements

Safetyrequirements

Privacyrequirements

Productrequirements

Organizationalrequirements

Externalrequirements

Non-functionalrequirements

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)

ambiguo

ridondante inconsistente

incomprensibile

incompleto

espandere

sintetizzare

ridurre

spiegare

formalizzare

espandere

risolvere

Esistono affermazioni “perfette” per i requisiti?

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

RicercareutenteTreni

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

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

SensoriEv_ascensorepiano(x)

If Ev_ascensorepiano(x) and Direction=Down and ProssimaRichiesta(y) and x<y then Rallentare Motore;

…

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

Notation DescriptionStructurednaturallanguage

This approach depends on defining standard forms ortemplates to express the requirements specification.

Designdescriptionlanguages

This approach uses a language like a programming languagebut with more abstract features to specify the requirementsby defining an operational model of the system.

Graphicalnotations

A graphical language, supplemented by text annotations isused to define the functional requirements for the system.An early example of such a graphical language was SADT(Ross, 1977; Schoman and Ross, 1977). More recently, use-case descriptions (Jacobsen, Christerson et al., 1993) havebeen used. I discuss these in the following chapter.

Mathematicalspecifications

These are notations based on mathematical concepts suchas finite-state machines or sets. These unambiguousspecifications reduce the arguments between customer andcontractor about system functionality. However, mostcustomers don’t understand formal specifications and arereluctant to accept it as a system contract. I discuss formalspecification in Chapter 9.

(Analisi Strutturata)

Modello Object-Oriented di Analisi (Esempio)

Classi (attributi ed operazioni)

Diagrammi di Sequenza

Casi d’Uso

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

Performancerequirements

Spacerequirements

Usabilityrequirements

Efficiencyrequirements

Reliabilityrequirements

Portabilityrequirements

Interoperabilityrequirements

Ethicalrequirements

Legislativerequirements

Implementationrequirements

Standardsrequirements

Deliveryrequirements

Safetyrequirements

Privacyrequirements

Productrequirements

Organizationalrequirements

Externalrequirements

Non-functionalrequirements

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;

Documento dei Requisiti del Software

Specifica dei Requisitidel Software

Ipotesi sull’Ambiente circostante al Software

riguarda

estrarre estrarre

confluire

estrarre

Determinare i requisiti

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

ValidazioneValidazione

Frontiere mobili

tempo

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

Sistema e Requisiti del Software:relazione fondamentale

(Requisiti del Software AND Ipotesi sull’ambiente circostante il Software)SODDISFARequisiti 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

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à

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?

Estrarre 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)…

Estrarre 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: AscensoreControllo 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

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

ValidazioneValidazioneVerifica

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 produrreDesiderata 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

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

Conclusione• I due casi non sono simili!

Software ascensore

Software biglietti treno

Sistema 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

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)

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

Esempio (Sistema Industriale)

• Pressman propone come esempio di sistema industriale un sistema d’instradamento di scatole su nastro trasportatore

get conveyor speed

send shunt

control data

get shunt status read bar code

start conveyor line

determine bin location

valid bar code

set for reject bin

conveyor in motion

read bar code

get conveyor status

produce report entry

conveyor stopped

invalid bar code

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 LagnanzeRidurre 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;

Estrarre 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

Partire

Sensore Piano 11..*

Pianonumero

Create( )

1

Pulsante

StatoTempo di reazioneDirezioneData controllo

illuminare( )spegnere()

Porta

Create ()

SensoreTipoStatoTempo di reazioneData controllo

Update statoDiagnosiConfigura( )

1

1

classe: una tipologia di oggetti, con

propri attributi ed operazioni

nomeclasse

attributi

operazioni

Fermare

Cabina

Richiesta

Leggendo i passi

1

1

0..1

0..1

0..1

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