INGEGNERIA DELSOFTWARE

Stefania Gnesi

INTRODUZIONE

Che cos’è l’Ingegneria del Software

Il termine Ingegneria del Software (Software Engineering) nasce alla finedegli anni ’60 in seguito al profondo cambiamento nel modo di usare icalcolatori elettronici che generò il problema della così detta “sofwarecrisis”. Questa fu causata dall’ introduzione dei computers della terzagenerazione. Queste macchine erano svariati ordini di grandezza più potentidi quelli della generazione precedente e quindi applicazioni particolarmentecomplesse che prima parevano irrealizzabili divennero possibili.L’implementazione di queste applicazioni richiese la realizzazione di sistemisoftware di dimensioni notevoli.Nei primi anni della loro diffusione, i computer venivano invece progettati eutilizzati esclusivamente per risolvere problemi molto specifici. Il computer,in questo primo periodo, era usualmente un supporto per il calcolo ed ilsoftware veniva scritto da un programmatore che era, allo stesso tempo,utente finale dell’applicazione stessa, cioè era lo stesso soggetto a scrivereed utilizzare un programma. Quando, intorno al 1960, i sistemi informaticidiventano più grandi e complessi, le due figure del programmatore edell’utente si separano, nascono così i team di persone che si occupano disviluppare software di grandi dimensioni; non è più pensabile, infatti, cheuna sola persona affronti tutti i dettagli di un problema complesso. In seguitoalla richiesta di applicazioni sempre più critiche e sofisticate, soprattutto inambiente industriale, nasce il concetto di Ingegneria del Software (intorno al1968) definita come disciplina che regola lo sviluppo di prodotti software dibuona qualità, definendo le attività necessarie a gestire, organizzare e indefinitiva portare a buon fine la realizzazione , manutenzione edevoluzione di un sistema software di grandi dimensioni (processo disviluppo sofware).

• Differenza tra prodotto e processo.

Il Prodotto è il risultato di una determinata attività di sviluppo, è tutto ciòche viene consegnato all’utente finale, quindi l’insieme delle opere fornite

dall’attività stessa (applicativo software, documentazione, etc…).Il Processo comprende tutte le attività che portano allo sviluppo di un certoprodotto; tra queste ci sono le scelte che caratterizzano il prodotto finale(scelta del supporto hardware, di metodologia di programmazione come illinguaggio da usare e il sistema operativo di supporto, etc…).

Il processo di sviluppo del software

L’Ingegneria del Software è quindi un approccio sistematico allo sviluppo,rilascio, manutenzione e ritiro di un prodotto software.Quando il software era molto semplice l’attività di produzione era svolta ingenere da un unico soggetto, che era allo stesso tempo programmatore eutente. Attualmente non è più così e diversi soggetti sono coinvolti nelprocesso di produzione del software. Il programmatore è usualmente unsoggetto distinto dall’utente, nasce anche la figura del committente che nonè sempre coincidente con l’utente. Il prodotto software è quindi il risultatodel lavoro di più persone, che spesso operano in momenti diversi. Èimportante quindi stabilire delle attività regolamentate in modo tale dasupportare ogni fase dello sviluppo, le interrelazioni tra i vari soggetticoinvolti in esso, la comunicazione delle informazioni necessarie per losvolgimento di fasi successive.Il processo di sviluppo del software è quindi costituito da quelle attività edai risultati ad esse connessi che sono necessarie alla produzione delprodotto software.Queste attività sono principalmente svolte dagli ingegneri del software conl’uso anche di strumenti CASE (Computer-Aided Software Engineering) disupporto allo sviluppo.Le principali attività che sono fondamentali e comuni in tutti i processi disviluppo del software sono:- Specifica del software. Vengono definite le funzionalità del software e i

vincoli sotto cui questo deve essere usato.- Sviluppo del software. Realizzazione dei programmi necessari per

l’implementazione delle funzionalità individuate nella specifica.- Validazione del software. Il software prodotto deve essere validato per

assicurarsi che esso realizzi esattamente ciò che il committente vuole.- Evoluzione del software. Il software deve evolversi per adattarsi ai

cambiamenti ritenuti necessari dal committente.

Il committente del prodotto quantifica e qualifica i suoi desideri circa ilpacchetto software da realizzare. Da queste richieste nascono lecaratteristiche (le funzionalità che deve sostenere, le possibilità daprevedere, …) e i requisiti (su quale hardware deve funzionare, in qualisituazioni particolari deve essere usato, …) che il prodotto deve avere.Solitamente si ha un dialogo preliminare tra il committente e un analista ospecificatore, in cui viene redatto un documento che presenta, in modo più omeno specifico, i requisiti e le caratteristiche desiderate. Questa è la fasedella specifica dei requisiti del software: i requisiti vengono solitamentecodificati con un linguaggio di specifica, che può avere vari gradi dirigorosità e formalità:- Linguaggi di specifica informali: in genere il linguaggio naturale, usato

per descrivere le caratteristiche del prodotto mediante una serie di frasi;- Linguaggi di specifica semiformali e formali: descrizioni fornite

mediante un formalismo di qualche tipo (grafico, equazioni matematiche,linguaggi logici, etc…). I linguaggi di questo tipo suppongono l’esistenzadi una teoria di supporto utile per testare il soddisfacimento dideterminati vincoli da parte della specifica.

Quando la prima fase è terminata inizia la fase di realizzazione, cheriguarda le modalità con cui il sistema software raggiungerà le caratteristichee i requisiti richiesti. In questa fase si sceglie il supporto hardware piùadatto, si sceglie il tipo di programmazione, si scompone il problema in piùsottoprogetti da affidare a persone diverse. Inoltre si forniscel’implementazione degli algoritmi secondo le specifiche di progetto.

La validazione è necessaria per garantire che il prodotto rilasciato siaconforme alle specifiche e ottenga i risultati previsti. Si cerca quindi di“esercitare” il prodotto fornendo dei dati critici o mirati a ottenere una dataelaborazione. Si controlla quindi che il prodotto funzioni correttamente.È bene chiarire subito che la “Correttezza” è una qualità non sempredimostrabile per il software. Normalmente non è possibile testare unprogramma per provare la sua correttezza con ogni possibile dato diingresso. Come conseguenza si ha che la correttezza del software è unaproprietà in generale indecidibile. Si parla normalmente di correttezzarelativa ai risultati osservati con gli input forniti.La fase di validazione prevede due stadi: la verifica e la successiva vera epropria validazione.

La verifica viene effettuata prima del rilascio del prodotto da chi hasviluppato il prodotto stesso.La validazione viene generalmente svolta dal committente. Questi esamina ilprodotto finito per giudicare se funziona come ci si aspettava e in qualemisura ha soddisfatto le aspettative. Quindi il committente giudica se ilprogramma è efficiente, se ha una buona interfaccia utente, se è facile dausare, etc… La validazione viene conferita solo se la verifica della qualità del prodottodà esito positivo.

CAPITOLO 1

Caratteristiche del Buon prodottosoftware

Abbiamo visto che l’Ingegneria del Software nasce per garantire lo sviluppodi un “buon” prodotto software; si tratta ora di definire meglio cosa conquesto si intende e come ottenerlo.I parametri con cui si può valutare in termini oggettivi un prodotto softwaresono anche chiamati “fattori di qualità”. Questi possono essere suddivisi indue categorie a seconda di come il prodotto viene osservato:

Qualità esterne = sono quelle percepibili da un osservatore che esamina ilprodotto dall’esterno (Black Box). In questo caso si esamina solo l’aspettodell’interazione con l’ipotetico utente. Non si conoscono e non interessa lastruttura interna del sistema, si esaminano solo gli input e i relativi output,considerando anche le caratteristiche dell’interfaccia utente.

Qualità interne = sono quelle che possono essere osservate esaminando lastruttura interna del prodotto (White Box). Scatola Bianca nel senso ditrasparente, cioè è possibile vedere la struttura interna del sistema e comequesto sia stato realizzato.

Vediamo ora quali sono i principali fattori di qualità che caratterizzano unbuon prodotto software.

• AffidabilitàÈ una misura della fiducia che si può riporre in un sistema. Quindi si misurala capacità del sistema a procedere nel suo lavoro senza guasti omalfunzionamenti quando usato in specifiche condizioni. Strettamente legata

all’affidabilità è la capacità del sistema di fornire un servizio in termini didisponibilità (availability) e di sicurezza (safety). Notiamo che questadefinizione si applica sia ai sistemi fisici che a quelli software; mentre iprimi possono stimare la loro affidabilità con parametri fisici (si pensi, adesempio, al tempo medio di durata di una lampadina), per i sistemi softwarequesta misura è molto più difficile.L’affidabilità è una delle caratteristiche più importanti di un prodottosoftware: un prodotto affidabile non dovrebbe causare danni fisici odeconomici in caso di guasto del sistema stesso. L’affidabilità non riguardagli effetti dei guasti ma solo la probabilità che si verifichino. L’affidabilità èun requisito essenziale nei sistemi critici, in cui un malfunzionamento delsistema può arrecare grave danno a persone o cose. Normalmente se sirichiede per un prodotto un’alta affidabilità, maggiore sarà il suo costo disviluppo.

Esempio: Il sistema di controllo di un passaggio a livello è affidabile sequesto è chiuso ogni volta che un treno è in arrivo (safety).

Stabilire se un sistema software è affidabile non è una cosa semplice, sitratta quindi di sviluppare dei criteri in base ai quali giudicare ilfunzionamento del sistema. In genere non si potranno esaminare tutti ipossibili comportamenti di un sistema, ma è importante identificare quelliche sono ritenuti vitali per il funzionamento affidabile del sistema,Nell’esempio di prima, se il passaggio a livello qualche volta rimane chiusoquando nessun treno sta per passare, il sistema ha evidentemente unmalfunzionamento; ma questo comportamento non è a rischio e questopotrebbe essere escluso nello studio dell’affidabilità del sistema passaggio alivello.

L’affidabilità dipende:- dalla correttezza delle fasi iniziali di sviluppo del prodotto software. Se

queste fasi sono svolte nel migliore dei modi sarà più probabile avere unprodotto affidabile;

- passaggio tra specifica e implementazione. Questo deve essere fatto inmodo da preservare la correttezza;

- ogni componente che partecipa alla realizzazione del sistema deve essereaffidabile.

• Correttezza

Il prodotto software è corretto se per ogni suo comportamento è possibileprovare che rispetta tutti i requisiti definiti per esso. Se i requisiti non sonocompleti il sistema può essere corretto ma andare incontro amalfunzionamenti. Un software corretto è anche affidabile (cioè l’insiemedei software corretti è un sottoinsieme dell’insieme dei software affidabili).Provare che un prodotto software è corretto non sempre è banale. Se si hauna formulazione matematica dell’algoritmo che si è implementato, si puòmettere in una corrispondenza uno a uno l’implementazione con laformulazione dell’algoritmo dimostrando così che il software è corretto.Negli altri casi non è sempre possibile giungere ad una prova di correttezza,in particolare questo accade nel caso di sistemi concorrrenti.

- RobustezzaIl software è robusto quando si comporta in maniera accettabile anche incorrispondenza di situazioni non specificate nei requisiti: procede nel suolavoro in maniera accettabile anche in presenza di Hw-failures, failures delsistema operativo, input non previsti, failures del software di interfaccia.Si definisce quindi Robusto un prodotto che, anche se usato in condizioni di“stress”, si comporta in modo corretto. La robustezza è una caratteristicache, per essere soddisfatta, implica accortezze particolari durante lacostruzione del prodotto. Questo significa inevitabilmente un costo direalizzazione maggiore.

Esempio di ingegneria classica: un ponte che non crolla duranteun’inondazione è un sistema robusto, perché ha funzionato correttamente incondizioni critiche.Esempio di ingengeria del software: quando si ha un crash hardware su unmicrocalcolatore, un software robusto garantisce che tutto quello che si èfatto fino a quel punto è salvo, e che al riavvio della macchina si potràripartire dal punto in cui ci si era interrotti.

• Sicurezza (Security)Il software è sicuro quando protegge l'accesso ad informazioni private eprotette, impedendo accessi non autorizzati, sia di natura involontaria,che di natura dolosa. E' una categoria particolare di software robusto.

• Innocuità (Safety)Con innocuità del software si denota il fatto che tali sistemi non entranoMAI in uno stato in cui il livello di pericolo dei possibili funzionamenti

può essere intollerabile. (Sistemi critici e pericolosi per la vita dell'uomo).E' una categoria particolare di software affidabile e robusto.

• ManutenibilitàQuesta caratteristica implica il poter intervenire successivamente al rilasciodi un prodotto software e apportare modifiche o correzioni. Un software èdetto manutenibile quando questi interventi possono essere fatti facilmente.Nonostante gli sforzi dei programmatori, infatti, non è pensabile che unprodotto software di grandi dimensioni sia messo in commercio senza difetti(bugs). Spesso i primi utenti di un prodotto software compiono, loromalgrado, un’attività di verifica sul prodotto stesso.Esistono vari tipi di manutenibilità o manutenzione del software:- manutenzione correttiva,- manutenzione perfettiva,- manutenzione evolutiva,- manutenzione adattativa.

La manutenzione di tipo correttivo è un’azione tesa a rimuovere eventualierrori non rilevati prima del rilascio. Ad es.: i cosiddetti programmi patchche risolvono uno o più bug di un programma.La manutenzione di tipo perfettivo è appunto un perfezionamentodell’algoritmo. Ad es., gli algoritmi usati nello sviluppo di un prodottosoftware impiegano troppe risorse e risultano poco efficienti. Vienemodificata una parte dell’algoritmo per migliorare le prestazioni del sistema.La manutenzione di tipo evolutivo è fatta per aggiungere potenzialità efunzionalità ad un prodotto software esistente. Questa è talvolta compiutaaggiungendo nuovi moduli al prodotto.La manutenzione di tipo adattativo è necessaria quando evolve l’ambientein cui il software opera. La manutenzione adattativa può essere considerataun caso particolare della manutenzione evolutiva.Esempio: al raggiungimento dell’anno duemila molti software sono statisottoposti a una manutenzione adattativa per non incorrere inmalfunzionamenti derivanti dalla rappresentazione della data.

La manutenzione del software è molto più facile se questo è stato realizzatoseguendo delle fasi rigorose di sviluppo: per esempio, una buonastrutturazione iniziale del problema aiuta ad ottenere un prodottomaggiormente manutenibile.Nonostante le possibili accortezze adottate nello sviluppo software, l’attivitàdella manutenzione richiede molto tempo, solitamente ben oltre il 60% del

tempo globale impiegato per lo sviluppo del prodotto.

• RiparabilitàUn software è detto riparabile se la correzione dei suoi difetti può esserefatta in un tempo limitato.

• EvolvibilitàUn prodotto software è detto evolvibile se è possibile di apportargli dellemodifiche nel tempo per cambiarne le funzionalità o aggiungerne di nuove.

• RiusabilitàUn prodotto si dice riusabile quando con lievi riadattamenti può essereimpiegato nella produzione di una nuova applicazione. Facendo uso dicomponenti standard riusabili ed affidabili, non solo i nuovi sviluppiavvengono a costi più bassi, ma anche la relativa affidabilità è più elevata.

Esempio1: le librerie scientifiche sono un software riusabile perché sonosempre inserite in altre applicazioni che le utilizzano per raggiungere i lororisultati.Esempio2: la shell di Unix viene riutilizzata da X-Window.

• PortabilitàUn prodotto si dice portabile se può essere utilizzato su piattaforme diverse,ad esempio con sistemi operativi diversi.

• ComprensibilitàIndica la chiarezza con cui l’applicazione informa l’utente riguardol’elaborazione in corso. In pratica, chi utilizza l’applicazione deve riuscire acapire sempre cosa sta facendo. Questa caratteristica è legata al livello dicomplessità dell’elaborazione da effettuare. Inoltre, è importante per laverificabilità del sistema.La comprensibilità è favorita dalla modularità di progettazione. Un prodottoè modulare se è diviso in parti che hanno sostanziale autonomia individualee una ridotta interazione con le altre parti.

• UsabilitàUn prodotto software è usabile se un utente non esperto riesce a capire comeutilizzarlo. È una caratteristica più “esterna” della comprensibilità perché èlegata all’interfaccia utente, a chi deve usare il sistema e a quanteconoscenze egli ha del sistema stesso, ed esprime il grado di

interfacciabilità con l'utente. (es: mouse, icone, help-on-line, ecc...)

• EfficienzaUn prodotto software è efficiente quando usa le risorse in manieraeconomica. La performance è legata alla complessità degli algoritmiutilizzati: maggiore complessità ‡ efficienza minore.

• InteroperabilitàUn prodotto software è interoperabile quando può facilmente integrarsi conaltri .Esempio1.: un word processor che utilizza font scalabili grafici deve gestireanche testi ASCII…Esempio2: Unix è un sistema con alta interoperabilità.

• ProduttivitàLa produttività valuta le prestazioni inerenti al processo di produzione delsoftware. E' una qualità molto difficile da misurare perché n∞ di linee dicodice (unica caratteristica di cui si dà una unità di misura) su unità ditempo.

Di tutte queste caratteristiche, alcune sono qualità interne al prodotto, cioèsono in relazione con lo sviluppatore e solo questi può usufruirle (ad es.: lariusabilità). Altre sono qualità esterne, cioè sono in relazione stretta conl’utilizzatore (es.: usabilità). Alcune caratteristiche, infine, sono di entrambei tipi.

Dalle caratteristiche appena viste si possono ottenere delle linee guida e deivincoli per lo sviluppo di un prodotto software. Saranno rispettati soltanoalcuni di questi vincoli, poiché in generale non è possibile oeconomicamente vantaggioso soddisfare tutte le caratteristiche esposte.

CAPITOLO 2

Il processo di sviluppo del software

Come abbiamo già detto il processo di produzione del software è datodall’insieme delle attività che corrispondono alla costruzione, distribuzioneed evoluzione di un certo prodotto. Prima di iniziare il processo si devonooperare delle scelte (quali strumenti utilizzare, quale linguaggio diprogrammazione, etc…) e si devono individuare i requisiti necessari alprodotto. Per identificare i requisiti è importante riferirsi alle funzioni che ilprodotto dovrà svolgere e alle caratteristiche che dovrà avere. È da questeultime che discendono le linee guida del processo produttivo.

I soggetti implicati nel processo di sviluppo

Nel processo produttivo si dovrà tenere conto del diverso ruolo delProduttore e del Committente. Si identificano le seguenti situazioni e perognuna un diverso approccio al processo di sviluppo:

1) Il Produttore e Committente sono lo stesso soggetto.2) Il Produttore e il Committente appartengono alla stessa azienda.3) Il Produttore crea il software per un particolare Committente.4) Il Produttore crea il software per immetterlo sul mercato.

1) Produttore e Committente sono lo stesso soggettoIn questo caso il Produttore sa cosa vuole otttenere e quali sono le proprierisorse, quindi si regola secondo le proprie esigenze.

2) Il Produttore e il Committente appartengono alla stessa aziendaQuesto è il caso, ad esempio, del Centro Elaborazione Dati di una aziendache scrive il software per la contabilità. Sviluppando software per usointerno, normalmente è assente l’aspetto competitivo che si troverà invecenei casi 3) e 4), si ha comunque la necessità di interazione tra chi scrive ilsoftware e gli utilizzatori per conciliare le esigenze al di là degli aspettieconomici.

3) Il Produttore crea il software per un particolare CommittenteIl Committente ha un’idea più o meno precisa della funzionalità che dovràavere il prodotto. Solitamente questi si reca dal Produttore per discuterel’aspetto economico (quanto costa?), quello temporale (quanto ci vuole?),quello tecnico. Nasce tra i due soggetti una dialettica per risolvere i variproblemi. Può succedere che il prodotto non soddisfi le aspettative delCommittente, sarà quindi necessario che il Produttore apporti degliaggiustamenti con relativo aggravio dei costi da parte del `Produttore o delCommittente magari attraverso querele legali. È importante quindi iniziare ilprocesso di sviluppo quando tutti gli aspetti sono stati chiariti e fissati.

4) Il Produttore crea il software per immetterlo sul mercatoQui non c’è più il soggetto specifico Committente. Il Produttore ha lapossibilità di realizzare un software interessante per il mercato e inizia unprocesso di sviluppo. Sarà il Produttore stesso a decidere quali sono gliobiettivi da conseguire. In questo caso sono da considerare moltepliciaspetti per rendere il prodotto competitivo: corretta valutazione dei tempi disviluppo, percezione di quale sarà la risposta del mercato all’immissione diun simile prodotto, valutazione del rapporto costi di sviluppo/valore delprodotto (non si devono avere costi di sviluppo troppo alti). In questo caso iproblemi da fronteggiare sono di natura diversa: socio economici, tecnici,realizzativi, etc…

Un problema particolarmente importante nei casi 1) e 2) è la scelta traprodurre un prodotto completamente nuovo (MAKE) oppure comprarne unogià esistente (BUY) ed estenderlo. A seconda della scelta cambia l’approccionella realizzazione del prodotto."

Metodologie del processo di sviluppo

" Il processo di produzione deve essere codificato per regolamentarlo.Vengono quindi definiti dei modelli di sviluppo del software da usare comelinee guida del processo. Si tratta di regole, “istruzioni” che devono essereseguite quando si inizia la definizione di un nuovo prodotto. Non ci sonoregole fisse da seguire ma solo consigli (metodologie consolidate) e ingenerale non esiste una metodolgia standard applicabile con successo inogni caso.I processi di sviluppo del software sono complessi e coinvolgono molteattività diverse. Anche per il processo come per il prodotto si possonodefinire degli attributi che lo caratterizzano:

• ComprensibilitàIl processo definito può essere compreso e facilmente usabile?• AccettabilitàIl processo definito è accettato dagli ingegneri del software?• AffidabilitàIl processo è definito in modo tale da evitare la generazione di errori diprocesso o il loro recovery prima di indurre errori nel prodotto?• SupportabilitàIl processo è supportato da strumenti CASE?"""""""""""""""""""""""""""""""• RobustezzaIl processo può continuare anche in caso di problemi inaspettati?• ManutenibilitàIl processo può evolvere per riflettere cambiamenti o miglioramentiorganizzativi?• RapiditàQuanto rapidamente si riesce a consegnare il prodotto seguendo il processodefinito?

Negli anni sono stati definiti diversi modelli di processo ciascuno dei quali siadatta meglio ad alcune delle caratteristiche viste sopra o ai diversi soggettiche sono coinvolti nella produzione.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Modello Code & Fix

Questa metodologia è adatta al caso in cui il produttore ed il committentesono la stessa persona. Nella fase iniziale viene scritto il codice, poi siesegue una verifica del prodotto e si apportano le necessarie modifiche.

Questo modello non implica nessuna strutturazione delle attività, lo stessosoggetto, produttore e committente allo stesso tempo, esegue tutti i passidella catena. Questo procedimento non è applicabile ai casi 2), 3) e 4) vistisopra. Un’accortezza da usare è quella di scrivere il codice in modo “pulito”e strutturato altrimenti sarà difficile apportare eventuali modifiche (vedimetodo strutturato di programmazione).

• Modello del Ciclo di vita a cascata (waterfall model)

Man a mano che le applicazioni sono diventate più complesse ed i ruoli diproduttore e committente si sono separati è stato necessario definire altrimodelli. Il modello del Ciclo di vita a cascata ha avuto molto successo neglianni ’70 ed è utilizzato ancora oggi in molti contesti industriali. Lo scopo diquesto approccio è quello di valutare tutte le attività necessarie allo sviluppodel software: interazione tra gruppi diversi, valutazione dei rischi economici,tempo necessario a completare il prodotto, etc… Tutte queste attivitàcomplementari alla scrittura del software sono molto importanti per la buona

Stesura delcodice

Verifica

Modifica delcodice

riuscita del prodotto finale, quindi questo modello vede la produzione comeuna serie di passi, l’output di ogni passo è un semilavorato da passare allafase successiva. Con la definizione del ciclo di vita a cascata si introducequindi un modello strutturato, si regolamentano dei passi da compierenello sviluppo di un prodotto software, l’ordine di tali passi e si stabilisconole regole di transizione da un passo al successivo. Le regole di transizionedevono rispondere ad una serie di quesiti: cosa faremo al passo dopo? Perquanto tempo continueremo una certa attività?

Studio di fattibilità

Analisi e specifica dei requisiti

Progettazione

Programmazionee test di unità

Integrazione etest di sistema

Manutenzione

Ú

Ú

Ú

Ú

Ú

Documento di fattibilità

Documento di specifica dei requisiti ( DSR )

Documento di specifica di progetto ( DSP )

• Studio di fattibilitàSi deve innanzitutto dare la definizione del problema avendo chiaro ogniaspetto del problema stesso. Questo normalmente accadrà dopo un numerosufficiente di interazioni tra committente e produttore del software. Devonoessere valutati specificatamente:- i costi e i tempi di produzione- le risorse umane necessarie- le risorse hardware necessarie- le alternative con cui il prodotto può essere sviluppato, relativamente ai

costi, ai tempi, alle caratteristiche che voglio ottenere (ad esempiodecidere se Make or Buy);

- devono essere identificati in modo chiaro e preciso i requisiti delcommittente: è questa la base dell’ipotesi contrattuale su cui si baserà losviluppo del prodotto.

È bene non fare ipotesi troppo semplici e sbrigative, più lo studio difattibilità è completo, più facile sarà rispettare l’ipotesi contrattuale (tempi,funzionalità, etc…). Nonostante l’importanza di questa fase, se essa vienefatta in modo poco approfondito questo comporterà notevoli rischi poichéuna scelta non appropriata fatta all’inizio del processo di produzione potràportare inevitabilmente a problemi nella fase di sviluppo o di rilascio delprodotto software.

Stabilito un accordo con il committente, si fornisce il documento sullo studiodi fattibilità che contiene le scelte fatte e le decisioni prese.

• Analisi e specifica dei requisitiA partire dalle ipotesi preliminari (il tempo e le risorse a disposizione, etc…)si definiscono in modo preciso le caratteristiche del sistema e i suoi requisitifunzionali, cioè quello che il sistema deve offrire all’utente finale in terminidi funzionalità.Il documento prodotto in questa fase deve avere delle caratteristiche benprecise affinché la fase successiva possa essere affrontata correttamente. IlDocumento per la Specifica dei Requisiti (DSR) deve essere:- preciso- completo- consistente

Un requisito è una scrittura più o meno formale e rigorosa di unacaratteristica del sistema, fatta dallo specialista. Nascono per questo motivodei linguaggi per la specifica dei requisiti, più o meno formali.Altri output di questa fase sono un manuale preliminare dell’utente (cheverrà poi raffinato alla fine dello sviluppo) e un preliminare del piano ditest (riguardante la verifica del rispetto dei requisiti), cioè una descrizionedelle modalità seguite per controllare che il prodotto realizzato sia inaccordo con i requisiti sia funzionali che non (caratteristiche).

• ProgettazioneIn questa fase si definisce l’architettura software su cui si baserà larealizzazione. È possibile considerare una scomposizione del problema insottoproblemi attraverso la definizione di una struttura modulare e dellerelazioni tra i moduli.Questa fase può avere due livelli:1) progettazione di massima (più grossolana)2) progettazione di dettaglio (più fine)

Tutte le specifiche di questa fase vengono date con un linguaggio dispecifica di progetto che può essere il linguaggio naturale oppure unlinguaggio semiformale o formale.L’output di questa fase è un Documento di Specifica del Progetto (DSP) incui si definiscono i moduli e l’architettura software.

• Implementazione dei moduli e loro testÈ la fase realizzativa. Ogni modulo, come unità indipendente, vieneimplementato e controllato per assicurarne la correttezza.

• Integrazione e verifica del sistema globaleI moduli realizzati nella fase precedente vengono integrati secondo le regolefissate nella progettazione.Anche se ogni singolo modulo è stato singolarmente testato, non è detto chel’insieme di questi funzioni correttamente. È necessaria una nuova fase divalidazione sul sistema globale.

• ManutenzioneQuando il prodotto è stato realizzato, spesso è necessario apportare dellemodifiche, sia perché il prodotto non risulta rispettare completamente lespecifiche fissate, sia perché si ritiene necessario perfezionare alcunefunzionalità e caratteristiche. Per rilevare questi casi si effettua ladistribuzione del prodotto ad un numero ristretto di persone (beta-testers)che lo utilizzano con lo scopo di rilevare il maggior numero dimalfunzionamenti o difetti. Si possono fare piccole modifiche oppure, sesiamo molto lontani dai requisiti, si può scegliere di fare lareingegnerizzazione del sistema, in pratica ripartire da capo.Finita con successo la fase di manutenzione di può eseguire il rilascio delsistema.

Il modello del ciclo di vita a cascata è stato ed è molto utilizzato in contestoindustriale per la sua chiarezza e linearità: i passi sono ben distinti esusseguenti, il metodo preciso e rigoroso. Proprio questi sono i punti di forzama anche le limitazioni di un modello troppo rigido: i requisiti vengono“congelati” nelle prime fasi del progetto, quando ancora non sono statiaffrontati i problemi di realizzazione pratica del prodotto, quindi è faciletrovarsi alla fine con un prodotto non soddisfacente o che presenta deimalfunzionamenti inaspettati.

Il modello del ciclo di vita a cascata non è sempre soddisfacente, talvoltainfatti è necessario aspettare la fine del processo di realizzazione per rilevaredegli errori o delle devianze dai requisiti. Sarebbe più opportuno, quindi,effettuare degli accorgimenti durante il processo realizzativo e immettere deifeedback di verifica.

• Modello con Feedback

Questo modello si basa sul presupposto che ogni fase può essereperfezionata o raffinata a seconda dei risultati dell’analisi effettuata nellafase precedente.

Feedback Ë raffinamento successivo di fasi adiacenti fino ad ottenere lastabilità del sistema.

Si ovvia così alla rigidità del modello del Ciclo di vita a cascata. Alcuni deidifetti rilevati rimangono anche in questo modello, poiché lo sviluppo delprodotto software è basato su un ragionamento monolitico, cioè il processo èqualcosa che inizia con le definizioni e si conclude con un prodotto finito,non sono previsti prodotti intermedi da usare per verificare la correttezza delprogetto di sviluppo. Si scoprirà solo alla fine dello sviluppo se l’oggettoprodotto è perfettamente coerente ai desideri del committente. Il prodottofinale si basa su un’analisi fatta molto tempo prima del rilascio, spesso sitratta di molti mesi, e non tiene conto di fattori esterni che possono avermodificato le condizioni al contorno dell’applicazione e le necessità. Ilprodotto finale potrebbe non soddisfare i requisiti aggiuntivi nati nelfrattempo, ad es.: se viene sviluppato un programma per il calcolo dell’IVA,nel tempo di sviluppo dell’applicazione potrebbe essere stata realizzata unanormativa fiscale del tutto diversa da quella presa in considerazioneinizialmente, in questo caso si potrebbe avere un prodotto obsoleto.

Un altro difetto di questo sistema viene indicato da questo esempio: unprogetto si svolge a partire da un istante t0 a un istante tn, all’istante t0

l’analisi del problema può essere non corretta, ad esempio si può rilevare unerrore solo sopo il rilascio del prodotto, istante tn, per una scorrettainterpretazione di alcuni requisiti. Servono allora dei modelli più dinamici,in cui c’è una maggiore interazione tra chi sviluppa il prodotto e chi locommissiona.

• Modello Evolutivo

Questo modello prevede di impostare un modello iniziale con i requisiti e lecondizioni individuate al momento dell’inizio del processo di sviluppo.Questo modello vedrà, durante tale processo, una evoluzione nel senso che ilmodello verrà aggiornato e modificato, l’insieme iniziale di requisiti saràampliato, ristretto o modificato, le condizioni al contorno riviste persoddisfare meglio le esigenze del committente. Si parla anche di sviluppoincrementale del modello. I cambiamenti avvengono man mano che siesplorano più a fondo i requisiti o quando ne nascono di nuovi.Quindi, all’inizio del processo produttivo si imposta un insieme I dicaratteristiche, dopo un certo tempo si avranno nuove caratteristiche, alcunedelle precedenti saranno raffinate o escluse.Si distinguono due approcci a questo modello:1) il Prototipo usa e getta,2 ) il modello evolutivo o incrementale vero e proprio, detto anche

progettazione esplorativa.

Vi sono delle classi di sistemi che necessitano di una messa a punto globale,ad es.: i sistemi interattivi. Per queste classi si usa il seguente modello:

• Modello evolutivo: approccio del prototipo usa e getta

Mostriamo questo approccio con un esempio. Si inizia con la realizzazionedi un prototipo P1 a partire da una descrizione non completa e limitata adalcune caratteristiche, seguendo un modello di sviluppo qualsiasi; l’oggettoottenuto viene presentato all’utente che ne verifica le funzionalità. Chi hacommissionato il lavoro giudica se il nucleo delle funzionalità individuate inquesto primo prototipo è sufficiente a coprire le sue esigenze. In questomodo si mettono in luce le caratteristiche essenziali che il sistema deveavere, e si valuta soltanto il nucleo di base su cui si deve concordare findall’inizio affinché l’applicazione sviluppata risponda alle esigenze delcommittente.In seguito si realizza un nuovo prototipo P2 allargando l’insieme dellecaratteristiche individuate inizialmente, procedendo in questo modo fino allagenerazione del prodotto finale P.Notiamo che P1 non viene raffinato per ottenere P2 ma viene usato solo peravere una visione iniziale del problema, per la generazione di P2 si riparte dazero (ad es.: con il modello a cascata). Il processo globale viene iterato nvolte fino ad ottenere il prodotto finale P. Il lavoro sostenuto per realizzare ivari prototipi viene, in un certo senso, scartato, perché deve servire solo a

capire se siamo sulla strada giusta. Per questo motivo questo approccio ha uncosto molto elevato e può essere utilizzato solo per sitemi non troppocomplessi o per sviluppare in tempi brevi kernels di applicazioni.

• Modello evolutivo o incrementale vero e proprio

In questo caso si realizza un prototipo P1, si consegna questo al committenteche lo esamina e individua i cambiamenti necessari al suo raffinamento.Questi vengono utilizzati per ottenere P2, che quindi è un’evoluzione di P1:

P1 ‡ raffinato ‡ diventa P2

Questo modello è utile quando si ha la necessità immediata di un prodottoanche se con funzionalità ridotte rispetto al prodotto finale.Da notare che lo schema visualizzato in figura vale anche per l’approccio“usa e getta”, con la differenza che le frecce all’indietro indicano soltantopassaggio di informazioni e non rielaborazioni del prodotto intermedio.

Limiti del modello evolutivoIl modello waterfall ha gli indubbi vantaggi della linearità e della visibilità:in ogni fase del processo produttivo si ha una documentazione completa sulprodotto. Il modello evolutivo, invece, ha una minor visibilità e manca distrutturazione poiché il prodotto viene rimaneggiato continuamente nellevarie fasi. Anche se si ha una strutturazione iniziale, ben presto le continuemodifiche faranno perdere la chiarezza e la documentazione iniziale sidiscosterà sempre più dal prodotto che si va a creare.Infine, per il modello evolutivo, sono richieste capacità particolari da parte

Descrizionedel Sistema

Specifiche

Implementazione

Valutazione

Famiglia di versioniP2..Pn-1

Versione Iniziale ‡ P1

Versione Finale ‡Pn

dello sviluppatore: chi modifica i prototipi deve conoscere a fondo ilproblema, le idee iniziali, le scelte fatte, etc… Non è più possibile dividere ilproblema in sottoproblemi da affidare a gruppi diversi, solo chi conoscel’intero progetto può lavorare sulle varie versioni. Per questo motivo nelleper sistemi complessi si preferisce spesso il modello waterfall per la suarigida strutturazione.

• Modello Trasformazionale

Questo modello si basa su trasformazioni successive delle specifiche, ingenere mediante specifiche formali. In questo modo si ottiene un insieme dispecifiche sempre più raffinate che possono poi essere usatenell’implementazione. Quest’ultima viene data in linguaggio astratto edeseguita su un processore astratto.

I passaggi da una specifica all’altra vengono fatti seguendo le regole dellinguaggio formale scelto, quindi mantenendo la correttezza; infatti datoun linguaggio formale caratterizzato da una sintassi e da una semanticarigorosa, si deve garantire che le trasformazioni delle specifiche sarannoottenute dall’applicazione di un insieme di operazioni e regole ai termini dellinguaggio. In questo modo è sufficiente dimostrare che la specifica inizialeè corretta e automaticamente lo sono anche tutte le specifiche successive,raffinamenti delle precedenti.

Limiti del modello TrasformazionaleI sistemi che si riescono a sviluppare partendo dalla loro definizione formalee arrivando alla loro implementazione attraverso una serie di passi di

SpecificheInformali

SpecificheFormali 1

SpecificheFormali 2

Implemen-tazioneformale

verificaL Ë SintassiË SemanticaË Regole e Assiomi

trasformazione non sono molti, si può dire che in pratica questo modelloserve a trattare sistemi molto piccoli. Nel caso di sistemi più complessi, soloponendosi ad un livello di astrazione molto alto si può applicare il metodotrasformazionale dando la definizione formale del sistema. Altrimenti si puòaffrontare una sottoparte del sistema globale per la quale è indispensabile lacorrettezza e su questo applicare il modello.

• Modello a Spirale

Questo metodo è un po’ il riassunto di tutti i modelli visti fin’ora ed è statodefinito da Bohem nel 1988. È in realtà un Metamodello (racchiude al suointerno tanti modelli) la cui caratteristica fondamentale è quella di tenerconto, prima di tutto, della problematica dei rischi. Fin’ora il problema delrischio non era mai stato posto come chiave del modello di sviluppo, inquesto modello si cerca di evitare e prevenire i rischi che possono insorgerenello sviluppo del prodotto. I rischi possono essere causati da: cambiamentiambientali (come la variazione delle legislazioni vigenti), una persona delteam che si licenzia, un crash hardware, etc…Lo sviluppo di un prodotto software viene diviso in quattro fasi principali,disegniamo una spirale su un piano cartesiano e associamo ad ogni fase a unquadrante: ad ogni giro della spirale corrisponde un raffinamento delproblema originale.

Metodo incrementale: compie più di un giro.

Metodo a cascata: applicazione di un solo giro, I e II ‡ stesura requisiti, III‡ implementazione, IV ‡ manutenzione.

Riassumendo: un processo di sviluppo software è una serie di attività, detteanche ciclo di vita, che vanno dall’analisi alla progettazione,all’implementazione e alla manutenzione di un prodotto software. Vi sonopoi delle attività trasversali, complementari a quelle menzionate, didocumentazione del prodotto, di verifica, validazione, gestione del processodi sviluppo, etc…Un dato processo insieme alle attività trasversali fornisce un modello diprocesso di sviluppo.

Il modello di processo è un modello astratto, il più possibile indipendentedalla tecnologia necessaria per la realizzazione del prodotto. Quanto più un

II. Valutazione dellealternative erisoluzione dei rischi

I. Determinazione diobiettivi, vincoli,alternative

III. Sviluppo e verificadel prossimo livellodel prodotto

V. Pianificazionedella fasesuccessiva

Il modello a cascatasi ferma qui

processo di sviluppo è ben fatto, cioè fornisce regole precise e consistenti,tanto maggiore sarà la qualità del prodotto: Buon Processo Ë BuonProdotto.Alla base di questo ragionamento c’è un concetto di qualità. Per poterindividuare e determinare la qualità di un prodotto si sono date delle regole,il loro fine è garantire all’utente un determinato livello di qualità. Un validoesempio è fornito dagli standard ISO (International Standard Organization)per cui un prodotto “ISO approved” rispetta le garanzie di qualità fornitedall’ente. Esiste la figura dell’ispettore che verifica la qualità del prodottocon una check list, una lista di domande, talvolta volutamente contraddittorietra loro, cui il produttore deve rispondere. Citiamo lo standard ISO 9000 chedescrive le procedure da seguire per documentare in modo idoneo tutto ciòche avviene durante il processo di produzione.La certificazione di appartenenza a uno standard è particolarmenteimportante per i software “critici”, oppure nel caso di certificazione fiscale;per questo esistono specifici enti di certificazione che analizzano i prodotti alfine di testare la loro soddisfacibilità rispetto agli standard ISO. Ad es.: ogniclasse di registratori di cassa deve essere approvata prima di essere immessasul mercato.

CAPITOLO 3

Ingegneria dei requisiti

Con Ingegneria dei requisiti si indica il lavoro necessario alla stesura di undocumento di specifica dei requisiti il più possibile completo e preciso.Ricordiamo le principali fasi del processo di sviluppo:• Specifica del software.• Sviluppo del software.• Validazione del software• Evoluzione del software

La prima fase di Specifica del software può essere decomposta in:

1) Studio di Fattibilità2) Analisi dei requisiti3) Specifica dei requisiti

Nelle fasi 1) e 2) si fa uso del linguaggio naturale essendo queste fasidialettiche in cui il committente ed il produttore convengono sul prodotto.La fase 3) deve invece fornire una descrizione tecnica dei requisiti e sfruttaquindi un linguaggio formale o semiformale. In questo passaggio si parlaappunto di ingegneria dei requisiti. Alla fine della fase 3) viene prodotto, apartire dalle discussioni informali, un documento strutturato concernente lesole caratteristiche funzionali. Il risultato di questa fase è destinato aglisviluppatori, agli architetti software e anche al commitente.In queste fasi iniziali, essendo caratterizzate dall’impiego del linguaggionaturale, è fondamentale la chiarezza sul significato dei termini usati nelledescrizioni informali del progetto software. L’architetto software deveevitare fraintendimenti con il cliente e per questo deve determinare unglossario di progetto contenente i termini tecnici utilizzati e quelli relativi aldominio di applicazione del prodotto. Questo glossario deve garantire lacomprensione linguistica tra cliente end-user e architetto software stesso,

quindi deve essere il più completo possibile, deve soddisfare la proprietà dichiusura (ogni termine tecnico usato nelle definizioni del glossario deve asua volta appartenere al glossario) e deve essere sintetico (solo i terminicaratterizzanti l’applicazione devono appartenere al glossario, si devonoevitare i sinonimi e le ridondanze). Per la stesura del glossario si fa un esamedella documentazione iniziale e si stende una prima bozza, questa vieneverificata dal committente mediante una serie di interviste, si compiono poidei raffinamenti fino ad arrivare ad un glossario soddisfacente.

Il glossario sarà usato per definire la lista dei requisiti, composta ancora dafrasi in linguaggio naturale. Questa è spesso considerata il contratto tra ilcommittente e lo sviluppatore. Al fine di identificare i requisiti è moltoimportante compiere uno studio sul dominio dell’applicazione (alcunitermini, infatti, hanno un significato diverso a seconda del dominio in cui siopera).

Lista dei requisiti Ë ContrattoË Descrizione di quello che sarà il sistema

Stesura di una lista di requisiti:

Studio deldominio di

applicazione

Analisi deirequisiti

Lista deirequisiti

Glossario

precede usa

produceprecede

produce

produce

Documento di specifica deirequisiti (con lista dei requisiti,

glossario, etc…)

Alla fine di questo processo si ottiene il documento di specifica deirequisiti (DSR): costituito da un insieme di requisiti raggruppati in sezioni(è un documento strutturato), ciascuna riguardante alcune caratteristiche delsistema. È buona regola far sì che ogni requisito sia una unità autonoma,cioè riguardi un solo aspetto o una sola caratteristica del sistema; oppuredeve caratterizzare un singolo vincolo che il sistema deve rispettare.Questo documento servirà innanzitutto per definire il contratto, poi per laprogettazione del sistema, infine per l’implementazione, la verifica e lavalidazione; è quindi la base di tutte le attività del processo di sviluppo. Èessenziale quindi che il DSR sia il più possibile:- non ambiguo- consistente- completo

Non tutti i requisiti hanno la stessa importanza, possono essere quindiraggruppate delle classi di priorità secondo le seguenti classificazioni:- requisiti obbligatori- requisiti desiderabili- requisiti opzionali

Requisito obbligatorio: riguarda un aspetto fondamentale del prodotto chedeve essere necessariamente considerato nello sviluppo del sistema, se sirinuncia a un requisito obbligatorio si diminuisce le potenzialità del sistema.

Requisito desiderabile: serve a migliorare l’efficienza del sistema, ingenerale questi requisiti implicano un maggior costo di sviluppo ma rendonomigliore il sistema (più usabile, più efficiente, etc…).

Requisito opzionale: riguardano caratteristiche che migliorerebberol’applicazione ma in aspetti ritenuti di secondaria importanza, per questo sisoddisfano solo se c’è il tempo per farlo ed il costo di sviluppo aggiuntivo ècontenuto.

• Caratteristiche di un buon DSR

1) Ogni requisito del DSR deve specificare solo il comportamento esternodel sistema.Questo significa che non devono essere specificati dettagli relativiall’implementazione del sistema.

2) Il,.DSR deve specificare i vincoli sull’implementazione legati al rispettodi alcune caratteristiche ritenute essenziali.Esempio: quando si definisce un sistema si deve valutare il livello diefficienza che si vuole raggiungere. Inoltre: il sistema deve essere user-friendly?Tutte queste caratteristiche impongono dei vincoli all’implementazione,nel caso di un’applicazione user-friendly si dovrà per esempio optare perun’interfaccia grafica, più intuitiva rispetto all’interfaccia testuale.

3) Il DSR deve essere facile da modificare.Quando si redige il DSR iniziale per sviluppare un sistema, non si haancora un idea precisa al cento per cento: quando si rileva la necessità dimodificare qualcosa (per esempio per aggiungere funzionalità al sistema),deve essere facile modificare il DSR con un costo minimo. Una simileproprietà per il DSR si riflette anche nella modificabilità delle fasi disviluppo successive.

4) Il DSR deve servire come strumento per la manutenzione.Si distingue una manutenzione correttiva, da eseguire nel caso siriscontrino degli errori, e una manutenzione evolutiva chiaramente legataalla modificabilità del DSR. Da notare che un DSR ben fatto facilitàl’individuazione di eventuali errori.

5) Il DSR deve memorizzare il contenuto del ciclo di vita.In teoria il DSR dovrebbe esser scritto tenendo conto dei passi cheverranno fatti per ottenere il prodotto finale, riportando le tecniche dispecifica formale, di manutenzione, etc… Si definiscono così le regole daconsiderare nel ciclo di vita.

6) Il DSR deve caratterizzare le risposte agli eventi non desiderabili.Occorre prevedere in fase di progettazione le possibili situazioni nondesiderate, di errore o di stress del sistema. In questi casi il sistema nondeve, per quanto è possibile, avere comportamenti casuali o nonpredicibili, quindi si devono specificare nel DSR quali sono le rispostedel sistema in questi casi.

Un altro fattore importante al fine di ottenere un buon DSR è la suaorganizzazione

possibilmente data da una serie di capitoli, sezioni dedicati alla descrizionedei

requisiti funzionali e non-funzionali più una serie di appendici contenenti il

glossario, un elenco delle sigle utilizzate all’interni del documento piu’ altreinformazioni ritenute utili alla comprensione del DSR.

Citiamo qui l’esistenza di due standards per la definizione del documento deirequisiti: US DoD DI-MCCR80025A (Reqs. Document) e IEEE standard830-1994 (Reqs. Specification)

• Validazione del DSR

Dopo la stesura del DSR, prima che questo diventi operativo e vengautilizzato, deve essere validato. Occorre, cioè, verificare la sua idoneitàcome documento di base per lo sviluppo del sistema, ed eliminare glieventuali difetti. Sono da risolvere:- inconsistenze- ambiguità- incompletezze- imprecisioni

InconsistenzeSi hanno quando un requisito è in contraddizione con un altro.

AmbiguitàSi ha quando un requisito si presta a interpretazioni diverse, cioè sicaratterizza una proprietà del sistema in modo che siano possibili più di unarealizzazione. In questo modo, a seconda della persona che legge il DSR, sipossono dare interpretazioni diverse e diverse realizzazioni del sistema.Questo costituisce un grave difetto del DSR.

IncompletezzeSi ha quando nel DSR mancano le informazioni sufficienti a caratterizzarecerte parti o vincoli del sistema.

ImprecisioniÈ un errore di terminologia, indica l’uso di termini in contraddizione con il

glossario.

La validazione è la rilevazione dei problemi sopra elencati. Occorre fareun’analisi strutturata alla ricerca dei problemi, prima un requisito alla volta,poi l’insieme globale dei requisiti (per la completezza, cioè per verificareche tutte le esigenze del committente siano trattate nel documento). Perfacilitare la verifica della completezza è importante che il documento sia benorganizzato. I controlli possono essere svolti da una sola persona che, ad es.,mette a confronto i termini tecnici usati con il glossario, oppure si può faresaminare il documento da più persone, ad es. qui la terminologia vienecontrollata assicurandoci che tutti gli esaminatori diano lo stesso significatoai termini usati.Un esame del DSR mediante la sua lettura può portare al rilevamento di unabuona parte degli errori in esso contenuti. Si valuta che fino al 60% di questipuò essere rimosso mediante questa tecnica di analisi.Questa fase è detta anche ispezione, se ben fatta consente di ottenere un“buon” documento con la conseguenza di facilitare enormemente le fasisuccessive di sviluppo. L’ispezione può essere fatta in molti modi. Latecnica detta “ridondanza” utilizza più definizioni ridondanti per lo stessorequisito, in modo che ci sia una verifica tra le definizioni stesse. Nel caso diispezioni parallele si fanno operare tanti ispettori in parallelo per poiconfrontarne i risultati, più sono gli ispettori, maggiore è la probabilità discoprire gli errori.

Si possono effettuare altri controlli sul DSR, definire altre caratteristichemeno importanti, che non riguardano la correttezza o le funzionalità deldocumento ma ne migliorano la qualità e la usabilità:

- Verificabilità: I requisiti così come sono espressi sono realmenteverificabili?

- Comprensibilità: I requisiti sono stati correttamente compresi dalcommittente e dagli end-users?

- Tracciabilità: L’origine del requisito è definita in modo chiaro?- Adattabilità: Il requisito è facilmente modificabile?

Il rispetto di queste caratteristiche migliorano la validazione del DSR. Undocumento è più verificabile se è ben strutturato. È comprensibile se scrittocon un linguaggio corretto, con termini propri e frasi semplici.A seguito dell’ispezione il DSR può essere modificato, è opportuno che siapportino le modifiche fino a raggiungere un punto di stabilità prima della

realizzazione del sistema.

Requisiti Volatili: desiderabili ma opzionali, non modificanosostanzialmente l’applicazione.Requisiti Stabili: sono i requisiti obbligatori, se faccio delle modifiche nondevo intervenire su questi che sono aspetti irrinunciabili per il sistema.

Il DSR è un documento scritto in linguaggio naturale, quindi non sempreesaminabile in modo rigoroso ed esaustivo.Questo è dovuto al fatto che non esiste una semantica associata al linguaggionaturale, anzi questo si dice essere inerentemente ambiguo (semantica=dareun significato univoco al linguaggio).Per risolvere questo problema si preferisce, prima di passareall’implementazione di un sistema, esprimere i requisiti funzionali di questopresentati nel DSR mediante delle descrizioni più rigorose. Questedescrizioni possono essere più o meno formali. Si avrà quindi il sistemadescritto mediante specifiche semiformali o formali.

Esempio 3.1Consideriamo alcuni requisiti che descrivono una parte del sistema dicontrollo di un sistema critico:“Il messaggio deve essere triplicato”“Le tre copie devono essere inviate su tre canali diversi”“Il ricevente accetta il messaggio secondo una politica di voting 2 su 3”

Questi requisiti possono apparire chiari a una prima lettura, in realtà ci sonodelle ambiguità che possono portare a scelte diverse al momentodell’implementazione.1) Il ricevente aspetta i tre messaggi, li confronta e prende i due uguali,2) oppure il ricevente aspetta il primo messaggio, poi il secondo; se sono

uguali li accetta completando l’operazione. Solo se questi sono diversi ilricevente prenderà in considerazione il terzo messaggio confrontandolocon i primi due.

A seconda delle interpretazioni prese possono esserci implementazionidiverse del sistema, con attese più o meno lunghe.

Un altro tipico problema delle descrizioni informali è quellodell’inconsistenza.

Esempio 3.2

Consideriamo i seguenti requisiti di un elaboratore di testi (word processor):“Il testo sarà suddiviso in linee di uguale lunghezza ”“Se l’utente non dà un comando esplicito, il return si fa solo alla fine di unaparola”Questi requisiti sono inconsistenti perché se una parola va oltre la lunghezzadi una linea un requisito prescrive di avere linee di uguale lunghezza l’altrodi non spezzare la parola: c’è un’evidente contraddizione che va risoltaprima di passare all’implementazione.

CAPITOLO 4

Specifica software: linguaggi dispecifica semiformali

I linguaggi di specifica semiformale sono usualmente notazioni grafiche, acui è associata una sintassi precisa e una semantica non rigorosa.

Esistono fondamentalmente due classi di linguaggi di specifica (formale osemiformale):• specifiche di tipo OPERAZIONALEqueste specifiche descrivono il sistema attraverso un modello che simula ilcomportamento desiderato del sistema stesso;• specifica di tipo DESCRITTIVOdescrivono le caratteristiche del sistema in modo dichiarativo.

EsempioDescrizione operazionale di un cerchio.Cerchio = linea geometrica tale che tutti i punti su di essa sono equidistantida un punto detto centro.

È una descrizione comportamentale (descrive il comportamento della linea)probabilmente più intuitiva e più vicina all’implementazione del sistema

cerchio.

Descrizione descrittiva del cerchio:ax2 + bx2 + c2 = 0 : equazione la cui risoluzione è il cerchio.

È una descrizione più astratta, probabilmente meno intuitiva di quellaoperazionale.

Verifica della correttezza delle specifiche: si giunge ad una verifica dellacorrettezza solo per specifiche fornite in modo formale:

Esistono tanti linguaggi di specifica diversi, questo perché non è possibileriuscire a rappresentare con un solo linguaggio tutte le classi di sistemipossibili. Quindi non esiste un linguaggio assoluto e definitivo, da poterusare con ogni sistema, né per la specifica né per l’implementazione delsistema.

Le specifiche operazionali possono essere di due tipi: SEMIFORMALE eFORMALE. Le specifiche operazionali semiformali sono formalismi grafici,quali i DFD, usati spesso per descrivere sistemi informativi (data base,etc…). Questi sistemi sono rappresentati come collezione di dati manipolatida funzioni.

4.1 DFD (Data Flow Diagrams)

MODELLOFORMALE

SPECIFICAFORMALE

Tecniche di analisi (legate alparticolare linguaggio)

Verifica

DFD (Diagrammi di Flusso di Dati) è una notazione di tipo grafico erappresentano un semiformalismo di specifica operazionale per applicazioniorientate alle funzioni.Si rappresentano dapprima i flussi di dati al livello più alto del sistemainformativo, La specifica del sistema viene poi prodotta per successiviraffinamenti e specializzazioni a partire da questo diagramma iniziale. Aogni passo di raffinamento, viene fatto corrispondere a una funzione, sceltaper l'espansione, un intero DFD, che specifica in maggior dettaglio il suosignificato in termini di altre, più semplici funzioni. Tecnologia TOP-DOWN.Nel raffinamento di una funzione in un intero DFD, deve essere rispettato ilvincolo di continuità del flusso informativo.che prescrive che neldiagramma corrispondente ad una funzione siano presenti gli stessi flussinetti di informazione in entrata e in uscita dalla funzione che si stadettagliando.

“Bolla”: rappresenta una funzione o un processoche opera su di un flusso di dati.

: rappresenta un flusso di dati

: deposito di dati

: agenti esterni (addetti alla produzione,uso, trasferimento dati in e out),

interazioni

input output

uomo-macchinaInput Output

Esempio 4.1.1Definire il DFD per il calcolo della seguente espressione aritmetica:(a + b) * (c + a * d).

Nello specificare il DFD relativo si è data una priorità agli operatori secondole normali regole dell’aritmetica: ignorare tali regole porta a unarappresentazione diversa.

Esempio 4.1.2

Presentiamo il DFD di un sottosistema sistema che si occupa della gestionedel prestito di libri in una biblioteca, fornendone il titolo e, se la ricerca ha

+ * +

*

d+a

b c

successo, la sua posizione fino al prestito dello stesso.

Posso definire successivamente uno schema per la GET e la SEARCH. Inquesto modo si parte da una descrizione ad alto livello e si descrivono lesotto parti in dettaglio.

Questo formalismo non ha associata una precisa semantica e quindi sipossono rilevare i seguenti problemi nel suo uso:

- Il significato dei DFD non è preciso ed è lasciato in parte all'intuizionedell'utente.

- Non si tiene conto delle fasi iniziale e finale e della gestione delleeccezioni del sistema.

- Non si tiene conto del flusso di controllo e della sincronizzazione tra iprocessi (i processi possono aver velocità differenti ).

Come conseguenza di quanto sopra si ha che è impossibile scriverespecifiche eseguibili (o verificabili) e definire strumenti di prototipazionebasati su questo formalismo.

Esempio 4.1.3Questo DFD descrive un sistema che riceve tre dati e ne fornisce due inoutput:

Richiesta dellibro

Titolo,Autore GET

NOME

TITOLI

SEARCH

ARMADIO

Titolo,Autore

Autore

Titolo

Posizione

Libro

Non essendo i DFD un formalismo conassociata una semantica, si possonodare varie interpretazioni a questo DFD:

- l’operazione avviene solo dopo che ho ricevuto A B e C- l’operazione avviene appena ne arriva uno- il risultato viene dato sia su D che su E- il risultato viene dato ad uno dei due- ad uno associa un valore ed all’altro un altro valore.

Esempio 4.1.4

Sono possibili due interpretazioni:- Per generare B si deve attendere l’arrivo di A (correlazione)- B viene prodotto indipendentemente da A

In definitiva la sincronizzazione tra input ed output non è specificata conquesto formalismo.

• Estensioni del DFD

Per ovviare alla possibile ambiguità di interpretazione vista in questiproblemi si è arricchito il formalismo per gestire gli aspetti di controllo.A partire dai DFD si definisce un formalismo di tipo più complesso. Con glischemi di trasformazione si cerca di rappresentare le informazionimancanti nel DFD rappresentando con flussi separati i dati e le informazionidi controllo.Si hanno ora due tipi di bolle:

A

B

C E

D

BA

Trasformazione di dati

Trasformazione di controllo

E più tipi di frecce:

Flusso di dato discreto

Flusso di controllo relativo ad un segnale

Flusso di dati continuo

Attivazione

Disattivazione

Data repository permanente

Buffer di memorizzazione temporanea

È stato definito anche un altro formalismo poiché alcuni problemi diambiguità non vengono risolti dagli schemi di trasferimento.

Formal Data Flow Diagrams (FDFD)

In questa estensione viene associata una semantica rigorosa al DFD che ciconsente di stabilire con sicurezza il significato dei grafici. Ci sono sempre iconcetti di bolla come trasformatore di dati, il rettangolo come contenitoredi dati e la freccia come transizione.

Trasformatore Contenitore Trasformatore

La freccia si differenzia in :

Operazione distruttiva (trasferisco il datoperdendolo da dove l’ho trasmesso)

Operazione conservativa (la scatola in ingressomantiene il dato letto)

Nel caso di operazione conservativa il dato viene mantenuto fino a che nonavviene uno sblocco dell’uscita.

Si hanno poi dei contenitori che fungono da buffer. La scrittura non avvienefino a che il buffer non è stato svuotato, cioè finché il dato precedentementecontenuto non viene “consumato” (operazione bloccante o scatolabloccante)

Vediamo le regole che condizionano il trasformatore di dati. Il trasformatorenon è sempre attivo, il suo stato dipende dalle informazioni del contenitore.Un trasformatore di dati è attivato quando:1) i contenitori in ingresso sono pieni (perché il trasformatore opera sui dati

che devono essere presenti ai suoi ingressi);2) tutte le scatole bloccanti in uscita sono vuote.

A seconda dell’operazione (distruttiva o conservativa) si considera ilcontenuto delle scatole che precedono o succedono il trasformatore di dati.Se un trasformatore prende dati da una scatola mediante un’operazioneconservativa, il contenuto della scatola rimane invariato, così altritrasformatori di dati possono usare lo stesso dato.Se il trasformatore di dati legge mediante un’operazione distruttiva, ilcontenitore in input viene svuotato, in questo modo il dato può essere usatoda un solo trasformatore. C’è un controllo su chi può usare un dato (uno omolti): operazione conservativa ‡ molti, operazione distruttiva ‡ uno solo.

A B

Scatole in uscita. Il valore calcolato dal trasformatore di dati viene passato alcontenitore:- se il trasformatore produce un dato tutte le scatole in uscita conterranno

quel dato se sono vuote,- se il trasformatore non produce l’output il contenuto delle scatole di

uscita rimane invariato.

La scatola è un buffer a una posizione, quindi non può contenere sia il datotrasformato da A che quello trasformato da B.Si introduce una nozione di non determinismo, questa situazionecorrisponde ad una scelta non deterministica dell’uso del dato prodotto da Ao da B. Il dato memorizzato in uscita proviene da A o da B ma a priori nonsappiamo quale sia dei due.

Esempio 4.1.5

• Modifica dei casi ambigui

Formalizzazione di un caso di ambiguità:

Caso 1X

A

B

C

D

A

B

C

D

X

Y

Z

X

A

B

C

Caso 2

Adesso si sono specificati perfettamente i due casi distinti:1) Ci sono 3 trasformatori di dati che interagiscono mediante un’operazione

conservativa con un contenitore che passa dati a D con una operazionedistruttiva. X può contenere solo un dato, quello prodotto da A o da B oda C (la scatola è bloccante). Alla fine di tutta la trasformazione in D èpresente il dato prodotto da A , B o C e la scatola X è vuota.

2) Ci sono tre scatole bloccanti perché le operazioni di input alla scatolasono conservative. X contiene il dato prodotto da A (se all’inizio eravuoto), idem per Y e Z. D ha tre contenitori in ingresso: può essereattivato solo quando X, Y e Z sono pieni. Il risultato in D è il risultatodella composizione del lavoro di A, B e C perché ha bisogno di tutti irisultati per essere attivata. Con questi due schemi diversi si è risoltal’ambiguità di interpretazione dell’esempio precedente.

Esempio 4.1.5Riprendiamo questo esempio

Sia hanno due casi:

Caso 1)

Caso 2)

Se l’operazione di trasformazione è di tipo distruttivo:Caso 1): chi consuma il dato lo cancella dal buffer X. Solo uno tra i blocchiE e F può essere attivato (probabilmente quello che è più veloce aconsumare il dato perché ha tutte le informazioni per farlo), l’altro rimanefermo a meno che il dato non venga prodotto di nuovo. Questa è lasimulazione di una situazione non deterministica perché a priori non èpossibile stabilire chi userà il dato.

X

A

B

CF

E

X

F

E

X

F

E

Caso 2): il dato non viene rimosso dal buffer. Quindi sia E che F sono ingrado di consumarlo, tutti e due elaborano il dato e questo rimane ancoradisponibile nel contenitore. Ciò può portare a situazioni di stallo: se dalbuffer escono solo frecce conservative, allora il contenitore non vienesvuotato, cioè è una memoria permanente (tutti i trasformatori di ingressoche cercano di mandare dati a quel contenitore non ci riescono: aspettanoche si svuoti ma questo non accade mai).

4.2 Entity Relationship

Questo formalismo grafico è un’alternativa al DFD più orientata ai dati ealle funzioni che non al controllo come il precedente. È un semiformalismo,è visto maggiormente nell’aspetto descrittivo che operazionale, al contrariodel DFD che è basato sulle trasformazioni sui dati. Con l’entity relationshipsi modella il concetto di relazione tra i dati e struttura dei dati:Descrizione concettuale della struttura del dato (aspetto sintattico, visionestatica del sistema) + relazione tra i dati (aspetto semantico)

DFD Ë sistema informativo (es.: sistema di ricerca in una biblioteca)

E.R. Ë usato nella progettazione delle basi di dati

Il modello E.R. si basa sugli schemi relazionali e reticolari delle basi di dati.Questo formalismo è molto usato nella pratica, quindi esistono moltistrumenti di supporto all’uso di questo formalismo (lo usano in modoautomatico e ne fanno verifiche e controlli).

Elementi base:- Entità- Attributi- Relazioni

Entità: oggetto che vogliamo trattare, rappresentato graficamente da un

quadrato.

Relazioni: relazioni tra le varie entità rappresentate graficamente con unrombo

Attributi: arricchimenti e caratterizzazioni che si assegnano alle entità peraumentare le informazioni su di esse, graficamente si indicano con un ovale

Esempio 4.21

Base di dati con entità STUDENTI e CLASSI, la relazione diAPPARTENENZA e vari attributi per l’entità STUDENTI (#MATRICOLA,NOME, SESSO).

ENTITA’ = collezione di individualità che hanno le stesse caratteristiche (=uniformi). Tutti gli elementi di una entità condividono gli stessi attributi.

Relazione tra entità STUDENTI e CLASSI = corrispondenza (biunivoca, inquesto caso) tra gli elementi di STUDENTI e quelli di CLASSE, la relazioneè un insieme di coppie:

(a, b) ‡ lo studente a appartiene alla classe b

L’insieme di tutte le coppie (a, b) è la relazione di appartenenza.

R Õ (STUDENTI x CLASSI)

Attributi dell’entità studenti = caratterizzazione degli elementi dell’entitàSTUDENTI.

Es.: #MATRICOLA, NOME, SESSO.

STUDENTI

SESSO

NOME

#MATRIC.

APPARTENENZA

CLASSI

STUDENTE CLASSE

Si potrebbero dare degli attributi anche per l’entità CLASSI:

Le relazioni possono essere di vario tipo:

Relazione di appartenenza binaria = costruisce un insieme di coppie a partireda due entità.Il numero delle possibili sottoclassi è 22 = numero dei possibili sottoinsiemi,2cardinalità della relazione.

In generale:

R: E1 x E2 x … x En = relazione ennaria

Gli elementi di R sono n-uple: (e1, e2, …, en)

Anche le relazioni possono avere degli attributi. Gli attributi sono utili perevitare ambiguità e costruire relazioni più precise.

Le relazioni tra entità non sempre sono simmetriche: la relazione diappartenenza è simmetrica: parto dagli studenti e li divido in classi, oequivalentemente parto dalle classi e ricostruisco gli studenti.

Esempio di relazione non simmetrica:

R : PERSONE 1 ‡ PERSONE 2 || || ||“Padre di” collezione collezione

di padri di figli

CLASSI

MATERIA

ANNO DICORSO

Partendo dai padri costruisco una relazione che non è 1 a 1, poiché un padrepuò avere più figli. Partendo dai figli non posso costruire la relazione che è“essere padre di”, infatti applicando la relazione scambiando l’insieme dipartenza con quello finale non ottengo nessuna coppia. Invece “essere figliodi” è 1 a 1.

• Relazioni

1) 1 a 12) 1 a molti3) molti a 14) molti a molti

Per ben definire una relazione occorre essere più precisi, si utilizza ilformalismo delle frecce come indicato sotto (A è l’entità iniziale):

1) funzioni 1 a 1 :

PERSONE1

PERSONE2

PADRE

2) funzioni 1 a molti

3) funzioni molti a 1

4) funzioni molti a molti

“Padre di” ‡ 1 a molti“appartiene alla classe” ‡ 1 a 1 (nell’esempio degli studenti di liceo)“appartiene alla classe” ‡ 1 a molti (se sono studenti universitari)

Esempio

Questa relazione è molti a 1.

A B

A B

A B

A B

IMPIEGATI APPARTIENE DIPARTIMENTO

È una relazione 1 a 1 (un dirigente è responsabile di un certo progetto).

Relazione molti a molti (un cliente ha più rappresentanti e un rappresentanteha più clienti).

Gli ER sono stati inglobati nei diagrammi delle classi di UML dove èpossibile definire relazioni fra istanze di classi di oggetti.

DIRIGENTE PROGETTO

RESPONSABILITA’

CLIENTI RAPPRESENTANTE

FORNITORE