Ingegneria del software: applicazione di un approccio sistematico, disciplinato e quantificabile allo sviluppo, funzionamento e manutenzione del software.

Per software s’intendono i programmi, le procedure, l’eventuale documentazione associata e i dati relativi all’operatività di un sistema di elaborazione.

Si deduce che l’ingegneria del software è la disciplina tecnologica e gestionale che riguarda la produzione e la manutenzione dei prodotti software sviluppati in tempi e costi preventivati. Per la gestione del ciclo di vita di un software si occupa di:

Metodi Modelli Tecniche Strumenti Analisi dei requisiti Manutenzione rilascio

Nasce dall’esigenza di dover gestire con qualità software complesso e di grande dimensione, in relazione alla maturazione dell’attività di programmazione che ha portato all’evoluzione dell’informatica da semplici programmi per il calcolo matematico a sistemi operativi complessi.

L’approccio ingegneristico è stato necessario dato l’alto numero di persone coinvolte(problemi di comunicazione), l’alta durata dei progetti(documentazione dettagliata necessaria) e la gestione dei cambiamenti dei requisiti. Senza tralasciare il fatto che il software ha dei costi e quindi l’IS ha un’importante valenza economica.

Lo sviluppo software è evoluto da un processo produttivo semplice (code-and-fix) ad uno complesso che parte dallo studio del ciclo di vita del prodotto, le cui fasi (organizzate diversamente da modello a modello) sono:

Definizione (cosa):determina i requisiti,informazioni,funzioni,comportamento e prestazioni attese, interfacce, vincoli progettuali e criteri di validazione.

Sviluppo (come):definisce il progetto, l’architettura software, la struttura dei dati e delle interfacce, i dettagli procedurali; consiste in pratica nella traduzione in codice del progetto (compresi collaudi)

Manutenzione (modifiche): prevede correzioni, adattamenti, miglioramenti, prevenzione Punto fondamentale sono i fattori di qualità, classificabili in (si influenzano a vicenda):

Qualità esterne->black-box: viste dall’utente Qualità interne->white-box:viste dallo sviluppatore (implementano quelle esterne) Qualità del processo Qualità del prodotto Correttezza: il software soddisfa la specifica dei requisiti funzionali. È calcolata mediante

proprietà matematiche che assumono la non ambiguità delle specifiche. I metodi per valutarla sono il testing,la verifica formale, l’ispezione, l’utilizzo di algoritmi e librerie standard, l’utilizzo di processi e metodologie di provata efficacia

Affidabilità: qualitativamente è la misura della continuità del servizio offerto; quantitativamente è la probabilità che il software operi come atteso. Non è una qualità assoluta(0/1) e non tollera scostamenti dal servizio atteso.

Robustezza:se il software si comporta in maniera accettabile anche in situazioni non specificate nei requisiti (output/input errati, malfunzionamenti hardware). La linea di demarcazione tra robustezza e correttezza è la specifica

Prestazioni:qualità esterna basata sui requisiti dell’utente e sull’utilizzo efficiente delle risorse (tempo di esecuzione, memoria occupata). Misurabile con la teoria della complessità computazionale.

Efficienza:qualità interna che si riferisce al “peso” del software sulle risorse; influenza e spesso determina le prestazioni ed è difficilmente misurabile

i. per valutazioni specifiche di efficienza e/o prestazioni vi sono tre approcci differenti che possono essere usati in congiunzione: measurement-based (misurazione sistemi reali), analytical o model-based(costruzione di un modello analitico, simulation (costruzione di un modello simulativo)

Usabilità: un sistema è usabile se i suoi utenti pensano che sia facile da usare; è una qualità soggettiva influenzata molto dalle interfacce utente (user frendliness)

Verificabilità: deve risultare facile poter verificare la correttezza di un sistema Manutenibilità: semplicità ed economicità con cui le attività di manutenzione vengono

eseguite; richiede capacità di anticipare i cambiamenti in fase di progettazione, basti pensare che oltre il 60% dei costi sono per la manutenzione che può essere:

1) Correttiva: elimina errori residui (20% dei costi)2) Adattativa: modifiche per l’applicazione così da adattarla a cambiamenti

d’ambiente(20% dei costi)3) Perfettiva: eliminare, aggiungere o modificare caratteristiche o funzionalità(50% )

Riusabilità: denota la possibilità di impiegare componenti esistenti per fornire una o più funzionalità integrandoli nel proprio progetto. Uno degli obiettivi dell’object-oriented è l’anta riusabilità

Portabilità: capacità di esecuzione in ambienti diversi Comprensibilità: al fine di garantire la correttezza del software, e di poter facilmente

apportare modifiche o poterlo riusare è necessaria un’ottima comprensibilità del codice Visibilità: se tutti i passi e lo stato del processo sono facilmente accessibili dall’esterno e

disponibili (richiede chiara documentazione) Interoperabilità: capacità di coesistere e cooperare con altri sistemi. È correlato a concetto

di open-system, cioè una collezione di applicazioni scritte in modo indipendenti tra loro basata su standard, ma che funziona come un sistema integrato.

Produttività: qualità del processo di produzione che ne indica prestazioni ed efficienza Tempestività: capacità di rendere disponibile un prodotto al momento giusto; richiede

ovviamente un’attenta pianificazione del processo e una tecnica di consegna incrementale del prodotto.

I principi dell’IS descrivono proprietà desiderabili del processo di sviluppo e del prodotto in termini generali ed astratti; essi necessitano di metodi e tecniche la cui individuazione è l’obiettivo di una metodologia. Tutte queste operazioni sarebbero inapplicabili senza l’adeguata strumentazione.

Rigore: è il mezzo concettuale necessario a strutturare le attività di sviluppo fornendo precisione e accuratezza

Formalità: è il livello più alto del rigore (guidato da leggi matematiche), ma non sempre conveniente. Favorisce l’automatizzazione e si applica in tutte e quattro le fasi (specifica dei requisiti, progettazione, codifica, verifica).

Rigore e formalità hanno benefici sulla affidabilità, verificabilità, manutenibilità, riusabilità, comprensibilità, portabilità, interoperabilità

La separazione degli interessi consente di affrontare un macro-problema focalizzandosi su diversi aspetti separatamente, facendo attenzione a non perdere la possibilità di operare ottimizzazioni globali. È un aspetto fondamentale per dominare la complessità. Si procede con:

Separazione temporale: definisce la sequenza di attività per la produzione di software Separazione sulle qualità: (esempio)progettare per assicurarsi prima la correttezza e poi

focalizzarsi sul’efficienza Separazione su viste diverse: (esempio)concentrarsi separatamente sul flusso dati e sul

flusso di controllo Separazione su parti del sistema: affrontare diverse parti del sistema separatamente Separazione sul dominio: scindere gli aspetti del dominio del problema da quelli del

dominio della soluzione e dell’implementazione. Separazione dei ruoli e delle responsabilità, in un azienda.

L’astrazione è il processo che porta ad identificare le proprietà rilevanti di un’entità, ignorando i dettagli inessenziali. È un caso particolare di separazione degli interessi, e fornisce una o più viste di una entità reale.

La modularità è l’organizzazione in parti(moduli) di un sistema,in modo che esso risulti più semplice da comprendere e manipolare. Un modulo è un fornitore di risorse o di servizi; realizza un’astrazione mediante due parti fondamentali:

Interfaccia: specifica il cosa fa il modulo e come si utilizza Corpo: descrive il come l’astrazione è realizzata

Punti fondamentali della modularità sono: Incapsulamento e information hiding: nascondere e proteggere i dati dell’entità è

l’obiettivo primario; l’accesso a tali dati avviene mediante operazioni definite nell’interfaccia

I tipi di astrazione realizzati da un modulo possono essere: Sul controllo: estrarre una data funzionalità dai dettagli della sua implementazione

(sottoprogrammi, metodi, funzioni) Sui Dati: estrarre entità(oggetti), costituenti il sistema e descritti in termini di una struttura

dati e le possibili operazioni su di essa (programmazione a oggetti o modulare) I possibili moduli o categorie generati dal processo di astrazione sono:

Procedura :astrazione sul controllo fornendo una implementazione di una operazione Libreria: gruppo di astrazioni procedurali correlate Oggetti astratti: astrazione sui dati mediante l’uso di struttura dati + operazioni che

generano uno stato (visibile solo alle funzioni interne) Tipi di dati astratti: insieme delle operazioni possibili sui dati ed esportazione di un tipo Pool comune di dati: modulo di livello basso per raggruppare dati affini Moduli generici: è un template di modulo, poiché c’è una parametrizzazione rispetto ad

un tipo. È necessaria una istanziazione con parametri reali prima dell’uso La modularità ovviamente offre benefici enormi nella separazione degli interessi, trattando

separatamente ogni modulo. I due approcci possibili sono bottom-up (composizione complessa partendo da moduli semplici) e top-down (divide et impera, scomposizione in parti semplici)

E’ fondamentale progettare moduli ad alta coesione, tutti gli elementi sono strettamente connessi, e basso accoppiamento, cioè bassa interdipendenza tra i moduli così che la separazione sia agevole.

Le possibili relazioni tra i moduli sono: Mi uses Mj:significa che Mj possiede una risorsa necessaria ed è quindi necessaria la sua

presenza per il corretto funzionamento; rappresentabile con un grafo Mi IsComponentOf Mj: se Mj è realizzato aggregando diversi moduli tra cui Mi. relazioni

simili sono Comprises, IsComposedOf, Implements Il successo di un progetto risiede inoltre nella capacità di anticipazione del cambiamento,

pianificando cioè l’evoluzione del software. La maggiore propensione al cambiamento del progetto può essere tradotta in una corretta modularizzazione.

Un modello del ciclo di vita del software è una caratterizzazione descrittiva di come un sistema software viene o dovrebbe essere sviluppato. Si pone come obiettivi il determinare l’ordine degli stati coinvolti nello sviluppo e nell’evoluzione del software e di stabilire criteri di transizione per progredire da uno stadio al successivo.

Il primo approccio ai progetti software avveniva mediante il code and fix, che consisteva nello scrivere codice in primis, per passare poi alla correzione dello stesso per migliorarlo. È chiaro che:

È inadeguato a software di grandi dimensioni poiché si ha una complessità enorme La gestione del personale e della documentazione è molto difficile È possibile interpretare male i requisiti dell’utente e impossibile prevedere tempi e costi Difficoltà oggettiva nell’aggiustare/modificare/ristrutturare il codice

Risulta quindi necessario utilizzare modelli che garantiscono la qualità dei prodotti finali, la previsione dei tempi e dei costi del progetto senza influire negativamente sulle prestazioni.

Le principali attività della produzione del software si possono racchiudere in: Studio di fattibilità: produce un documento con la definizione del problema, la valutazione

dei costi/benefici, il calcolo delle risorse finanziarie e umane, la previsione di soluzioni alternative, tempi di consegna e modalità di sviluppo.

Acquisizione, analisi e specifica dei requisiti: è la parte più critica e va a definire il cosa il sistema dovrà fare (non come), specificando le funzionalità e le qualità necessarie senza vincoli di progettazione o implementazione (richiede conoscenza del dominio)

L’ingegneria dei requisiti sviluppa metodi per ottenere,documentare,classificare e analizzare i requisiti.

Scopo dell’analista è infatti identificare gli utenti interessati (stakeholders) e integrare i vari punti di vista (anche contraddittori) in un’unica vista coerente del sistema.

Il risultato dello studio dell’analista è la produzione di un documento di specifica dei requisiti (DSR) comprensibile, preciso, completo, coerente, non ambiguo e modificabile. Esso conterrà una descrizione del dominio,requisiti funzionali, non funzionali, requisiti del processo di sviluppo-manutenzione, oltre ad un piano di test di sistema.

Modello a cascata (guarda disegno dietro): è un modello in cui ogni fase raccoglie un insieme di attività omogenee per metodi,

tecnologie, skill del personale. Gli output di una fase possono essere direttamente input di una fase successiva, oppure possono essere congelati (non più modificabili) se non innescano un processo formare e sistematico di modifica. L’intero processo è guidato dalla produzione di documentazione.

la fine di ogni fase è un punto rilevante del processo (milestone); gli output delle fasi sono chiamati deliverable, la cui definizione fondamentale per misurare il progresso di un progetto.

È un modello ideale, solo approssimabile nella pratica, caratterizzabile mediante tre proprietà: linearità, rigidità (può congelare i requisiti nelle prime fasi quando sono ancora poco dettagliati), monoliticità(un errore nei requisiti non è verificabile se non a lavoro ultimato).

I lati negativi sono la difficile stima dei costi, la bassa evolvibilità, la difficoltà nel produrre specifiche complete a causa della molta attività di manutenzione richiesta

Una variante del modello a cascata è il V&V e retroazione (feedback): Verifica: stabilisce la verità delle corrispondenze tra un prodotto software e la sua specifica Convalida: stabilisce l’appropriatezza di un prodotto software rispetto alla sua missione

operativa È un approssimazione del modello a cascata che tenta di superare la monoliticità.

Introduce dei feedback in ogni fase che rilevano errori eventuali prima del rilascio. È un modello indicato per sistemi poco soggetti a cambiamenti.

Modello a V: Indicato per sistemi poco soggetti a cambiamenti, con requisiti chiari e completi (sistemi

non interattivi)

E’ strutturato su due rette diagonali che convergono al centro verso la codifica. Ogni attività sulla retta di sinistra è collegata ad un’attività sulla retta di destra, che corrispondono alle attività di test. Se un’attività a destra trova un errore non si procede alla successiva attività a sinistra ma si riesegue quella che ha generato l’errore.

Esamina prima i requisiti utente di sistema, poi identifica le unità del sistema e assegna i requisiti alle unità. Successivamente l’analisi dei requisiti hardware/software esamina le risorse di ogni unità decomponendole in CSCI(computer software configuration items) e HCI(hardware configuration items)

Si passa poi alla progettazione software che alloca risorse ai moduli software imponendo requisiti temporali. Il risultato è il progetto dettagliato di ogni CSCI

In fine si passa all’implementazione, al test e integrazione software e al test e integrazione del sistema prima del suo utilizzo

Modelli evolutivi: È un modello approssimato dell’applicazione il cui obiettivo è quello di ricevere feedback

dal committente. Il primo prototipo è detto Throw Away (usa e getta). Lo sviluppo effettivo inizia dalla seconda versione, basato sul principio Do it Twice, che

consente di ridurre errori sui requisiti. Si parla di prototipo evolutivo se vi è un progressivo sviluppo dal primo passo al prodotto

finale. Nell’approccio a prototipi, la distanza tra specifica dei requisiti e rilascio non è adatta a

gestire cambiamenti. È comunque un passo verso modelli di sviluppo flessibili detti approcci evolutivi o incrementali.

Si dice evolutivo, “un modello le cui fasi consistono in versioni incrementali di un prodotto con una direzione evolutiva determinata dall’esperienza pratica”; ovvero è possibile rimandare lo sviluppo di alcune parti per produrre il prima possibile un insieme di funzionalità

Una versione incrementale è a tutti gli effetti un’unità software funzionale, auto contenuta, che esegue compiti utili al cliente. È corredata da specifica dei requisiti, piani di test e casi di test, manuale utente, materiale per il training.

Un processo evolutivo “parziale” è il processo per implementazioni incrementali. Ciò significa che vi saranno rilasci a cascata fino alla fine dell’implementazione. È evidente che permangono i problemi tipici del processo a cascata come l’eccessiva distanza tra l’analisi dei requisiti del sistema al primo rilascio, congelamento dei requisiti (che potrebbe causare una successiva invalidazione degli stessi).

Se l’approccio incrementale è esteso a tutte le fasi si parla di modello di sviluppo a rilascio incrementale. Si inizia a coprire gli obiettivi dl sistema e l’architettura, procedendo poi con l’analisi dei requisiti di un incremento. Ogni incremento è poi progettato, implementato, testato, integrato e rilasciato, tenendo sempre conto dei feedback.

Questo approccio pianificato aiuta lo sviluppatore nella gestione delle risorse necessarie Scompare la manutenzione dal ciclo di vita, poiché il sistema è in evoluzione continua Mentre nel modello a cascata il cambiamento si manifesta come un’attività post sviluppo

ed è costoso(poiché non si anticipano i cambiamenti), nel modello evolutivo i cambiamenti sono gestiti durante lo sviluppo ed è più semplice incorporarli in modo disciplinato

Nel modello evolutivo sono previsti rilasci tempestivi , fondamentali per essere competitivi sul mercato software.

Metodologie agili: Sono un sottoinsieme dei modelli evolutivi nate come alternativa ai metodi tradizionali. Si propongono come modelli leggeri di sviluppo, e possono essere definiti adattivi più che

predittivi, poiché non cercano di programmare lo sviluppo ma di progettare programmi pensati per cambiare nel tempo.

Sono People-Orienteded anziché Process-Orienteded, poiché si adattano alla natura dell’uomo.

Adatte a progetti la cui mission e i cui requisiti sono poco chiari, instabili e variabili. Garantiscono la possibilità di attuare strategie sempre diverse, sgravando l’enorme lavoro necessario al processo di sviluppo (tantissimi file di documentazione), con un approccio flessibile e leggero (modello evolutivo).

Sono tra le più pratiche per la modellazione efficace di sistemi software in finestre temporali molto limitate (poche settimane). Prediligono la comunicazione in tempo reale e verbale piuttosto che la documentazione mirando ad abbattere tempi e costi di sviluppo.

Non forniscono procedure dettagliate di programmazione ma suggerimenti efficaci di modellazione. Richiedono infatti la collaborazione del cliente

Sono inclusi valori e principi che incoraggiano l’agilità. Tra i principali valori c’è l’ottenere un’efficace comunicazione tra tutti gli attori del progetto che dev’essere sviluppato nel modo più semplice possibile. È importante avere coraggio nel prendere e perseguire decisioni e ammettere con umiltà di avere bisogno di altri collaboratori poiché è impossibile conoscere tutto.

Le practices più comuni a questo tipo di approccio sono la condivisione della conoscenza, la gestione adattativa, il feedback rapido, pairing, simple design & re factoring, e ovviamente molta attenzione sul testing.

Tra le metodologie più diffuse abbiamo: eXtreme Programming (XP): è la più popolare metodologia, e coinvolge direttamente

anche il committente; basata su iterazioni veloci che rilasciano piccoli incrementi concentrandosi sull’iterazione attuale senza pensare alle necessità future. Si attua un re factoring ad ogni iterazione di un semplice sistema base, migliorando il codice in modo costante e continuo. Vediamo quali sono le practices:

I. Planning game (obiettivi e tempi della next-release)II. Small releases (rilascio veloce di un piccolo sistema)

III. Metaphor (guida dello sviluppo attraverso una “storia” che lo descrive)IV. Simple design (concezione del sistema nel modo più semplice possibile)V. Re factoring (ristrutturare il sistema senza cambiarne il comportamento)

VI. Testing (effettuati costantemente durante lo sviluppo)VII. Pair programmino (scrittura in coppia del codice su una stessa macchina)

VIII. Collective ownership (chiunque può cambiare il codice quando vuole)IX. Continuous integration (integrazione continua, anche più volte al giorno)X. 40-hour week (ore lavorative minime settimanali)

XI. On-site custode (rappresentante del cliente sempre a disposizione)XII. Coding standards (supportano la comunicazione durante la scrittura di codice)

SCRUM: è un processo per migliorare la flessibilità e velocizzare lo sviluppo di nuovi prodotti. È iterativo, incrementale, e adatto allo sviluppo o gestione di ogni prodotto, poiché fornisce alla fine di ogni iterazione un set di funzionalità già rilasciabili. I cicli iterativi vengono detti sprint, ognuno dei quali comprende le tradizionali fasi di sviluppo software. Lo scrum si compone in tre fasi:

I. Pre-game phase (divisa in planning sub-phase e architecture sub-phase)II. Development (game) phase (il sistema è sviluppato attraverso una serie di sprint)

III. Post-game phase (contiene la chiusura della release) I ruoli principali sono:

IV. Scrum master (gestisce il progetto)V. Product owner (stakeholders)

VI. Team (gruppo cross-functional che esegue analisi, progettazione, implementazione…)

Modello trasformazionale: prevede lo sviluppo software come progressione di passi. Si passa da una descrizione formale ad una descrizione meno astratta. È basato su due concetti fondamentali, Prototipazione e Formalizzazione, che portano a codice eseguibile di più basso livello.

Si inizia con una specifica formale dei requisiti, convalida delle stesse e trasformazione della formalità in qualcosa di meno astratto e più dettagliato. Il risultato dev’essere una parte eseguibile da un processore astratto.

Le trasformazioni possono essere eseguite manualmente o da strumenti, giacchè il processo di trasformazione può usare componenti riusabili. Si avvale infatti della storia dello sviluppo salvata in precedenza, così da supportare ottimamente future richieste di cambiamenti.

Non è un paradigma praticabile ma è guardato con interesse per l’approccio formale

Modello a spirale: si pone come obiettivo quello di fornire un quadro di riferimento per la progettazione dei processi. È un meta-modello che consente di scegliere l’approccio migliore in funzione del livello di rischio, inteso come circostanza potenzialmente avversa che pregiudica lo sviluppo e la qualità del prodotto.

La gestione dei rischi risulta un passo fondamentale quindi per ‘’identificare, affrontare ed eliminare i rischi prima che insorgano problemi seri o causa di re-implementazioni costose”

Nel grafico a spirale il raggio rappresenta il costo accumulato, e ogni ciclo è una fase differente (studio fattibilità, progettazione…etc).

Prima fase: identificare obiettivi della porzione di prodotto in termini di qualità da ottenere (si chiaricono alternative e vincoli)

Seconda fase: valutazione delle alternative ed evidenziazione delle potenziali aree di rischio (simulazione)

Terza fase: sviluppo e verifica. Si può procedere con modelli evolutivi (requisiti incerti), a cascata(requisiti chiari), o trasformazionali (sicurezza al primo posto)

Quarta fase: revisione dei risultati e pianificazione della prossima iterazione della spirale

Vediamo dunque le differenze tra i vari modelli proposti:

Analisi dei rischi a confronto tra i vari modelli: Modello a cascata: alto rischio per sistemi nuovi con requisiti non chiari o con requisiti

che evolvono. Alto rischio di durata eccessiva dello sviluppobassa tempestività (qui si vede tutta la scarsa flessibilità del modello). Basso rischio per sistemi con specifiche o tecnologie assestate.

Modelli evolutivi: alto rischio per mancanza di visibilità, ma basso rischio per applicazioni nuove, requisiti ambientali variabili ed alta evolvibilità.

Modello trasformazionale: alto rischio per necessità di tecnologie avanzate ed alte competenze .

L’analisi dei requisiti è un passaggio fondamentale nella progettazione software. È un processo di comprensione del dominio del problema che stabilisce servizi, interfacce, prestazioni e funzionalità che il committente richiede al sistema, il tutto ovviamente rispettando i vincoli di utilizzo e sviluppo.

Un requisito è una frase che descrive qualcosa che il sistema farà e che tutti gli stakeholders ritengono necessario per la soluzione del problema.

Si possono distinguere requisiti funzionali (descrivono il cosa deve fare), e requisiti non funzionali (sono i vincoli sul sistema/ambiente e i vincoli sul processo di sviluppo)

Requisiti funzionali: Input accettabili dal sistema Output che il sistema produrrà Dati che il sistema dovrà immagazzinare e che possono essere usati da altri sistemi Elaborazioni che il sistema dovrà svolgere Problemi di tempificazione e di sincronizzazione delle elaborazioni

Requisiti non funzionali: Usability, efficientcy, reliability, maintainability e reusability (tempi di risposta,

throughput, uso delle risorse, affidabilità, disponibilità, recovery from failure, manutenibilità, riusabilità)

Vincoli sull’ambiente di funzionamento e sulle tecnologie del sistema (piattaforma, tecnologie di sviluppo)

Vincoli su project plan e metodi di sviluppo (processo e metodologie da adottare, procedure per il controllo di qualità e costi/date di consegna)

L’analisi produce un documento di specifica dei requisiti software completo,consistente, non ambiguo e comprensibile.

Il processo di specifica prevede tre fasi fondamentali:1. Analisi : comprensione di cosa il sistema deve fare2. Specifica dei requisiti: trasformazione dei requisiti in un documento tecnico che

caratterizza il sistema3. Validazione delle specifiche: le specifiche formalizzate vengono riviste con

l’utente/committente L’ingegneria dei requisiti è essenziale poiché sviluppa metodi per ottenere documentazioni valide

e senza errori. In genere un errore nei requisiti costa 100 volte in più di un errore di programmazione, e correggerli in fase operativa costa 60/200 volte in più che in fase di specifica. Le principali fasi si possono raggruppare in :

Elicitation: acquisizione dei requisiti tramite consultazione con gli stakeholders, documenti, conoscenza del dominio, studi di mercato. La raccolta collaborativa dei requisiti è tra le tecniche preferite per ottenere i dati; è basata su riunioni strutturate con gli stakeholders, con tanto di agenda, moderatore, regole, tutto allo scopo di identificare i problemi e accordarsi sugli approcci.

Analisi e negoziazione: valutazione dei requisiti rispetto a completezza, conflitti e compatibilità. Si compone in checklist per la verifica dei requisiti, requirements prioritization, interaction matrix per identificare i conflitti e risk analysis. La quality Function Deployement è una tecnica utile per determinare i valori delle funzioni, identificare i dati , esaminare il comportamento del sistema e determinare le priorità.

Documentazione (specifica): è il documento tecnico che descrive funzioni, prestazioni e vincoli del sistema. Può avere svariate forme, come:

Documento testuale Insieme di modelli Modello matematico formale Insieme di scenari utente (use cases) Un prototipo

Può essere presentata con un approccio informale, usando un linguaggio naturale con supporti grafici(tabelle, figure), con un approccio formale, automi a st. finiti o reti di Petri, oppure usando un approccio Semi-Formale, sfruttando ad esempio l’UML. È ovvio che esistano diversi modelli adatti a diverse situazioni/applicazioni:

Modelli Orientati all’elaborazione dati (data-flow) Modelli basati su composizione (semantica dei dati) Modelli basati su classificazione (modello ad oggetti) Modelli basati su risposte a stimoli (real time) Modelli orientati a processi (reti di Petri) Modelli basati sul comportamento (diagr. di stato)

La specifica dei requisiti è un documento che contiene la descrizione dettagliata dei servizi del sistema, il cui ruolo può anche essere visto come contratto tra committente e sviluppatore.

La specifica del software è invece la descrizione astratta del software, e che risulta quindi essere la base per il progetto e la realizzazione. È prettamente indirizzata agli sviluppatori.

Il documento di Specifica dei Requisiti Software (SRS) è un punto di convergenza di tre punti di vista: cliente, utente, sviluppatore. Errori in questo documento costano molto caro nel sistema finale… pertanto la qualità del prodotto finale è strettamente collegata alla qualità di tale documento.

La Validazione è una revisione che ha il fine di trovare errori, informazioni mancanti o inconsistenti, requisiti contrastanti o irrealizzabili. Si avvale di revisioni e ispezioni manuali, reading, uso di scenari, prototipazione, test dei requiiti e anche di una bozza di manualte utente. Tipicamente è possibile riscontrare questi tipi di errori nel SRS:

Omissione (assenza di un requisito) Inconsistenza In correttezza (fatti non corretti nell’SRS) Ambiguità (requisiti con significati multipli)

Requisiti incorretti portano a consegne ritardate, costi maggiori, insoddisfazione dell’utente, comportamenti errati e imprevisti, alti costi di manutenzione.

La progettazione dei dati è il passaggio immediatamente successivo al CHE COSA (analisi), passando dunque al COME. I modelli concettuali servono per ragionare sulla realtà di interesse indipendentemente dagli aspetti realizzativi.Le metodologie di progettazione sono:

Progettazione concettuale: rappresentare le specifiche informali in termini di descrizione (semi-)formale, e dalle elaborazioni cui sono soggetti.

Progettazione logica: traduzione dallo schema concettuale al modello di rappresentazione dei dati adottato dal sistema di gestione di base di dati disponibile.

Progettazione fisica: lo schema logico viene completato con le specifiche dei parametri fisici di memorizzazione dei dati (file, archivi…)

Modello concettuale E-R (vedi slides stampate) Automi a stati finiti: è un modello formale che descrive gli stati in cui il sistema può venirsi a

trovare durante la sua evoluzione, e le trasformazioni che fanno evolvere il sistema tra gli stati. È un modello operazionale. Possiamo identificare differenti tipi di AUTOMI: Mealy: risposte associate a transizioni che portano al nuovo stato,definito come <S,I,U,d,t,s0> Moore: la risposta non dipende dal modo in cui si raggiunge lo stato ma dallo stato stesso Deterministico: stato prossimo univocamente determinato da stato/ingresso corrente Non deterministico:più transizioni possibili verso stati differenti in base all’ingresso/stato

Reti di Petri: sono un formalismo di specifica particolarmente adeguato per la descrizione formale di attività concorrenti. Sono una sorta di estensione degli automi a stati finiti, con le dovute differenze:

Lo stato è distribuito, poiché risulta essere l’unione di più stati parziali e indipendenti. La transizione non riguarda lo stato globale del sistema ma varia solo una parte di esso.

È utilissimo per modellare sistemi asincroni in cui gli eventi non accadono secondo una sequenza definita. La simbologia è postocerchio, transizionelinea orizzontale (o quadrato),flussofreccia È non deterministico (si può scegliere una qualsiasi tra le transizioni possibili) e definito solo da un ordine parziale tra gli eventi, astraendo la nozione di tempo.Una rete N è una tripla: N=(P,T;F)

P è detto insieme dei posti, T è l’insieme delle transizioni, ed F è la relazione di flusso. P e T sono insiemi finiti

Deve valere: 1. P <-> T =0 (insieme dei posti e transizioni sono disgiunti)2. P ≈ T ? 0 (la rete non è vuota, esiste almeno un posto o una transizione)3. Fπ(P∞T) ≈(T∞P) (posti e transizioni sono tra loro in relazione)

I posti contengono le informazioni relative ai possibili stati parziali della rete, le transizioni indicano le modifiche elementari dello stato della rete (ogni evento produce il cambiamento in uno stato parziale). L’intera rete ha una struttura topologica che indica l’avanzamento parziale tra i vari nodi, ossia quali eventi possono avere luogo e in che ordine. Una rete Posti/Transizioni è una quintupla P/T = (P,T;F,W,M0):

P e T definiscono una rete W associa ad ogni elemento della rete di flusso (arco) un numero intero positivo (peso) M0 è la marcatura iniziale della rete,che associa ad ogni posto un numero intero positivo

(insieme degli stati iniziali e quindi dello stato globale iniziale)Il preset di un nodo n della rete(posto o transizione) è l’insieme dei nodi dai quali parte un arco che arriva a n; Il postset invece risulta essere l’insieme dei nodi ai quali arriva un arco che parte da n. Poiché non sono possibili relazioni di flusso F tra posti e posti(transizioni e transizioni) il pre/post di un posto è composto di sole transizioni, e viceversa pre/post di una transizione contiene solo posti.L’evoluzione della rete dipende dal fatto che si verifichi un evento nel modello P/T; si deve considerare:

Possibilità che l’evento si verifichi abilitazione di una transizione: Una transizione t è abilitata (può scattare) quando in M ogni posto p d’ingresso a t,

contiene un numero di token almeno uguale (>=) al peso dell’arco che collega pt Effetto che l’evento ha sullo stato del sistema regola di scatto

Può verificarsi solo se la transizione t è abilitata a scattare nella marcatura M Produce una nuova marcatura M’ tale che da ogni posto p in ingresso a t viene rimosso un

numero di token uguale al peso dell’arco che collega pt In ogni posto q in uscita a t viene depositato un numero di token uguale al peso dell’arco

che collega tq La marcatura dei posti che non siano né di ingresso né di uscita a t resta uguale

Il fatto che la scelta sia non-deterministica fa si che una volta che una transizione abilitata scatta, per decidere quali saranno le prossime transizioni abilitate si deve rivalutare la rete, cercando la nuova disposizione dei token e le nuove transizioni (eventualmente) abilitate, e quelle disabilitate. Vi possono essere due tipi di conflitti:

Strutturale: se due transizioni t e u hanno almeno un posto di ingresso in comune Effettivo: se due transizioni sono in conflitto strutturale, contemporaneamente abilitate su una

marcatura M e il numero di token che i loro posti d’ingresso contengono non è sufficiente a soddisfare tutti i pesi degli archi che li collegano alle due transizioni (cioè se non ci sono abbastanza token da soddisfare lo scatto di entrambi gli archi)

Le reti di Petri sono molto usate anche per la progettazione in concorrenza, e in particolare due casi: Strutturale: se due transizioni t1,t2 non condividono alcun posto d’ingresso, e cioè lo scatto di una

delle due transizioni non disabilita l’altra. (implica che possa verificarsi quella effettiva) Effettiva: se due transizioni t1,t2 in una marcatura M sono entrambe abilitate

Le Reti Condizioni/Eventi (C/E) sono reti con archi di peso unitario in cui tutti i posti hanno capacità unitaria. Le principali caratteristiche sono:

Si ha una transazione abilitata se e solo se tutti i posti d’ingresso contengono un token e tutti i posti d’uscita sono vuoti

Nessuna distinzione tra conflitto strutturale e conflitto effettivo (analisi statica più efficace rispetto alle reti P/T)

Qualsiasi rete P/T è trasformabile in una rete E/C equivalenteSebbene la modellazione mediante queste reti sia molto utile, ci sono alcune proprietà di interesse non rappresentabili o decidibili solo a prezzo di una complessità elevata. Ecco invece le proprietà delle Reti Di Petri:

Raggiungibilità (reachability): consente di determinare se da una certa marcatura iniziale si possono raggiungere stati indesiderati. M’ raggiungibile dalla marcatura M se e solo se esiste almeno una sequenza di scatti che produce M’ a partire da M

Limitatezza (boundedness): un posto di una rete P/T si dice k-limitato se in una qualunque marcatura raggiungibile della rete il numero di token non supera mai il valore intero K

Binarietà: si dice binaria (safe) se in ogni suo posto, quale che sia l’evoluzione della rete, non si può mai avere più di un token. La condizione sufficiente è la marcatura iniziale binaria, e che tutte le marcature raggiungibili siano binarie anch’esse.

Vitalità (liveness): dà una misura dell’esistenza di transizioni che non possono (più) avvenire (situazioni di blocco critico, deadlock). La liveness può avere gradi che vanno da zero (la transizione a grado 0 non può mai scattare in qualsiasi marcatura della retetransizione morta) ad un massimo di quattro (la transizione è viva poiché qualunque marcatura raggiungibile con una serie di scatti può abilitare t)Una rete P/T si dice viva se e solo se ogni sua transizione è viva (grado 4 liveness)

Le reti di Petri sono dotate anche di una rappresentazione matriciale o algebrica che può essere utile per eseguire analisi automatiche della rete e verificare il soddisfacimento di alcune proprietà di base. Permette la rappresentazione di una rete di Petri attraverso equazioni di stato, che si basano su concetti chiave:

Matrice d’ingresso Matrice d’uscita Matrice d’incidenza Vettore marcatura Sequenza di scatti Vettore delle occorrenze

Estensioni alle reti di Petri: Archi inibitori: utili per disabilitare una transizione Reti temporizzate(TPN) e stocastiche(SPN):rappresentano gli intervalli di tempo che

intercorrono tra gli eventi (deterministici in TPN e stocastici nelle SPN) Reti di alto livello: i token portano con se informazioni per cui non sono più

indistinguibili come nelle reti P/T ordinarie Nella progettazione di un sistema software è opportuno bassarsi sul principio della modularità. I

moduli infatti sono componenti(parti) del sistema che realizzano un’astrazione rendendo più semplice la manipolazione e la comprensione del tutto.

I maggiori meccanismi di astrazione sono: Astrazione sul controllo (sottoprogrammi, metodi, funzioni) Astrazione sui dati (oggetti, classi, moduli, librerie)

Per linguaggi di programmazione non tipizzati un oggetto può essere dichiarato anche senza specificarne il tipo. Gli oggetti infatti per questi tipi di linguaggi sono entità che incapsulano una struttura dati nelle operazioni possibili su di essa.

Discorso diverso invece si fa per linguaggi tipizzati dove per definire tipi di dati astratti bisogna specificarne il tipo (astratto). Le classi sono un’implementazione di un tipo di dato astratto, mentre un oggetto è un istanza di una classe.

Le classi sono viste diversamente a seconda della fase in cui ci troviamo: Fase di analisi: rappresenta una vista concettuale del problema che cattura i principali

concetti del dominio senza occuparsi di come essi verranno rappresentati nel software (si pone attenzione sul cosa e non ancora sul come)

Fase di progetto: è il riferimento principale dal quale si capiscono quali saranno le interfacce del sistema senza pensare ancora all’implementazione reale

Fase di implementazione: classi e relazioni indicano la reale struttura del software implementando un tipo di dato astratto

L’UML è un linguaggio universale utilizzabile per specificare, progettare, rappresentare o documentare qualunque tipo di sistema (software, hardware, organizzativo). NON è un linguaggio di programmazione ma uno standard OMG.È basato su un meta-modello (come E-R) che permette di realizzare diversi diagrammi :

Diagrammi per modellare gli aspetti statici e dinamici (comportamentali): Diagramma dei casi d’uso Diagramma delle classi Diagramma di sequenza Diagramma di collaborazione Diagramma di stato Diagramma delle attività

Diagrammi di implementazione: Diagramma dei componenti Diagramma di distribuzione

Un caso d’uso è una tipica interazione tra utente e sistema. Permette la rappresentazione di funzionalità esterne e di individuare ruoli e processi del dominio, il tutto in forma grafica. Le relazioni tra i casi d’uso possono essere di due tipi:

<<include>>: è una relazione che formalizza i casi in cui più casi d’uso racchiudono una serie di azioni comuni (per non ripetere comportamenti comuni). Il caso d’uso da solo non ha senso.

<<extends>>: le estensioni sono percorsi aggiuntivi al caso d’uso base. La sequenza opzionale definisce un nuovo caso d’uso che estende il caso di partenza.

Un attore fornisce uno stimolo(input) al sistema e riceve un output; è la rappresentazione di: Una classe di persone fisiche Un altro sistema software Un dispositivo hardware esterno

I legami tra casi d’uso e requisiti funzionali sono: Ogni caso d’uso può soddisfare più requisiti funzionali Un requisito funzionale può dare origine a più casi d’uso Ad ogni caso d’uso possono venire associati più requisiti non funzionali

Per la costruzione di un modello dei casi d’uso ci sono dei passi obbligatori da seguire: Identifica gli attori Identifica i casi d’uso Definisci la comunicazione tra attori e casi d’uso Descrivi i casi d’uso

Ogni caso d’uso ingloba molti percorsi alternativi percorribili in funzione delle condizioni che si verificano. Un percorso alternativo è detto scenario, il cui ruolo è quello di individuare le entità concettuali del sistema (le potenziali classi e oggetti) in seguito all’evento di innesco:

Come e quando il caso d’uso inizia Chi inizia il caso d’uso Interazione tra attore/i e caso d’uso e cosa viene scambiato Come e quando

Negli scenari è possibile descrivere eventi anche attraverso costrutti if oppure cicli while o for, per racchiudere gruppi di passi che devono essere ripetuti più volte.

Il diagramma delle classi (DC), che rappresenta le classi all’interno di un modello, oltre che all’analisi dei requisiti è vincolato anche alla fase di analisi, alla fase di specifica e progetto e alla fase di implementazione (come avviene per le classi).

Le classi vengono rappresentate come descrittori di un set di oggetti con struttura, comportamento e relazioni comuni. Tra diverse classi ci possono essere diverse relazioni:

Associazione: legame semantico tra istanze di classi, caratterizzata da un nome, un ruolo (eventuale) e un valore detto molteplicità dell’associazione (cardinalità delle connessioni). È importante chiarire la direzione dell’associazione

Generalizzazione – Specializzazione: si sfruttano i principi di ereditarietà e polimorfismo Contenimento: se di tipo lasco indica l’indipendenza dal ciclo di vita dell’oggetto

contenuto dall’oggetto contenitore(si introduce nella classe contenitore un puntatore all’oggetto contenuto, che il costruttore del contenitore riceve in ingresso); se invece è di tipo stretto l’oggetto contenuto non esiste da solo, in quanto è parte del contenitore (il contenitore è responsabile della creazione e distruzione del contenuto, e infatti si realizza introducendo nel contenitore una variabile membro della classe contenuto)

Queste relazioni definiscono il modello statico del progetto. Poiché l’UML fondamentalmente descrive aspetti statici, esistono dei diagrammi dinamici che

aggiungono una dinamica comportamentale agli oggetti individuati dall’UML. Si usano infatti: Diagrammi di sequenza: illustrano la sequenza esplicita di messaggi, rappresentando

un’interazione visualizzata rispetto ad una sequenza temporale(in linea orizzontale) e sono indicati a specifiche di tipo real time e scenari complessi

Diagrammi di collaborazione: rappresentano le relazioni tra gli oggetti; maggiormente indicati per evidenziare gli effetti su un dato oggetto durante la progettazione procedurale. Diversamente dal sequence diagram, rappresenta le relazioni tra gli oggetti.

Come scegliere tra i sequence e i collaboration diagrams? I sequence rendono esplicito l’ordinamento temporale delle interazioni e sono molto

simili agli scenari dei casi d’uso (risultano quindi una scelta più naturale se si hanno già i diagrammi case)

I collaboration hanno meno spazio per i dettagli ma sono preferibili quando si deriva un diagramma di interazione da un class diagram poiché valgono anche da controverifica per i class diagramm stessi.

Tutti gli oggetti, istanze di una classe, sono assimilabili a sistemi a stati finiti, facendo attenzione al fatto che le riposte alle sollecitazioni dipendono anche dalla storia dell’oggetto(che corrisponde ai valori correntemente assunti dagli attributi dell’oggetto).

Uno state diagram rappresenta le sequenze di stati, le risposte e le azioni che un oggetto o un’interazione attraversano durante la loro vita in risposta agli stimoli ricevuti.

Una transizione tra due stati può avvenire o meno in modo condizionato; inoltre le condizioni logiche devono essere mutuamente esclusive, per cui una sola sola transizione potrà essere effettuata in un determinato momento.

Gli activity diagram sono un mezzo per rappresentare attività molto complesse tramite l’individuazione di attività componenti e loro punti di incontro (utile per rappresentare i business processes). Come le Reti di Petri sono molto utili nel caso di sistemi concorrenti, anche se non sono indicati gli attori responsabili delle attività (il che lo rende poco chiaro talvolta); viene dunque rappresentato ciò che accade senza mostrare quali sono le classi responsabili delle attività.

La progettazione è la fase intermedia tra i requisiti e l’implementazione. Si occupa di decidere le modalità di passaggio dal ‘’che cosa’’ al ’’come’’. Si procede fondamentalmente scomponendo il sistema in parti e assegnando le responsabilità a ciascuna di esse al fine di raggiungere gli obiettivi globali.

La scomposizione in parti implica una riduzione della complessità poiché ogni sottoinsieme può essere realizzato e analizzato indipendentemente.

Il tipo di scomposizione, i linguaggi di modellazione e le tecniche di progettazione dipendono dalla tipologia di software (scelte di progetto). Queste scelte devono poter cambiare in risposta a mutate esigenze, senza che tutto il progetto ne risenta gravemente.

La modularizzazione fatta bene da notevoli vantaggi alla progettazione; per questo identificare i moduli dalle loro relazioni e mantenere un basso accoppiamento e alta coesione sono le regole fondamentali, oltre alle noteseparazione degli interessi, rigore e formalità, information hiding, riusabilità…

In una realtà che muta così velocemente è indispensabile promuovere un approccio flessibile per facilitare i cambiamenti. L’evolvibilità può far risparmiare sulla spesa più ingente di tutto un progetto: LA MANUTENZIONE.

Quali cambiamenti vanno previsti?: Algoritmi e rappresentazione dei dati Macchina astratta sottostante (linguaggio,SO,DBMS) Cambiamenti di periferiche Cambiamenti dell’ambiente sociale Cambiamenti dovuti al processo di sviluppo

I due approcci tipici alla progettazione sono top-down (scomposizione) o bottom-up (composizione). Mentre il primo permette una modularizzazione significativa, ostacola due concetti chiave quali l’information hiding e il riuso. La documentazione è più chiaramente comprensibile attraverso un approccio top-down.

Si trovano soluzioni ai problemi di: Interfacciamento attore-sistema: in genere poiché non esistono regole generali si

utilizzano oggetti coordinatori per la conduzione di uno o più casi d’uso Collezionamento degli oggetti: si ricorre a classi si libreria oppure classi specifiche Persistenza degli oggetti: uso di DBMS OO o di classi per la memorizzazione Collaborazione distribuita: uso di middleware o soluzioni ad hoc (proxy, pattern…) Prestazioni Dislocazione fisica

I diagrammi di implementazione mostrano gli aspetti legati all’architettura del sistema. Un diagramma dei componenti mostra le dipendenze tra i componenti software (codice sorgente,

binario o eseguibile), come per esempio dipendenze di compilazione, di librerie, etc.. Un diagramma di allocazione descrive invece le scelte d’allocazione delle componenti software

sulle unità fisiche. Rappresenta una configurazione del sistema a run time, pertanto mostra solo i componenti che esistono a tempo di esecuzione. Può essere utile per descrivere l’architettura fisica (hardware e software). Si va quindi a specificare dove i vari componenti sono dislocati attraverso:

Nodi : unità computazionali; possono contenere istanze di componenti (il componente vive in quel nodo)

Componenti: moduli di codice compilabili ed eseguibili separatamente; possono contenere oggetti (l’oggetto è parte di quel componente)

Relazioni: dipendenze tra moduli dislocati e connessioni fisiche tra i nodi Per raggruppare componenti omogenee del sistema che manifestano un elevato livello di coesione

interna si utilizzano i PACKAGES. Sono contenitori di elementi, che consentono una semplificazione nella gestione di software complessi, e possono anche essere in correlazione fra loro mediante interfacce o dipendenze comuni.

Vediamo la lista delle possibili dipendenze tra packages, ovvero le voci tra << … >> Extend Include Access (un package A ha il diritto di accedere alla classe x del package B B::x) Import (tutta la parte pubblica di B appartiene al namespace di A quindi usa le sue classi) Use (la semantica di A dipende dalla semantica di B) Derive (A è calcolato a partire da B) Friend (visibilità degli attributi protetti altrui) instanceOF bind (legame tra una classe A e la classe template B) instantiate refine (se A e B sono lo stesso oggetto a differente livello di astrazione) become (se A è un evoluzione temporale di B) copy call send (manda un evento)

Nella traduzione da UML ad un linguaggio OO scelto si deve far attenzione a rispettare le regole: Gli attributi diventano le variabili membro delle classi, con i qualificatori private, public,

protected, static. Se il tipo dell’attributo è una classe può diventare in C++ una variabile membro di tipo

classe o un puntatore, oppure in Java sarà un riferimento alla classe. Tutti gli attributi vanno inizializzati mediante un apposito costruttore I metodi vengono tradotti rispettando lo schema : visibilit_ funzione tipo_ritorno

nome_funzione(lista parametri) Nel C++ i metodi UML diventano funzioni membro, I metodi virtuali puri diventano

funzioni membro virtuali pure, i metodi ereditati da una classe derivata si traducono in funzioni membro virtuali, e tutti i metodi di una classe saranno funzioni membro di tipo static.

In Java i metodi UML saranno funzioni membro di egual visibilità, i metodi virtuali puri si traducono in funzioni membro abstract (metodi astratti), non vi è il problema di sovrapposizione dei metodi in una gerarchia. Tutti i metodi della classe saranno funzioni membro di tipo static.

Lo scambio dei valori in C++ viene effettuato per valore (input semplici) o per riferimento (input complessi o in/out)

In Java si usa per default lo scambio per valore, ma ci sono metodi appositi per i parametri di input complessi (clone() ) e classi wrapper dedicate per i parametri di in/out semplici che effettuano lo scambio per riferimento ma con meccanismi appositi. Si usa lo scambio per riferimento solo per parametri in/out complessi.

Le classi astratte definiscono i metodi virtuali puri , a cui non corrisponde alcun comportamento già prestabilito. Sta dunque alla classe derivata implementarne il comportamento estendendo il comportamento della classe astratta. Ovviamente una classe astratta non istanzia oggetti.

I metodi virtuali non puri sono invece già definiti in classi, e possono essere ridefiniti o completati nelle classi derivate. Si parla a tutti gli effetti di polimorfismo poiché gli oggetti derivati possono avere comportamenti diversi rispetto alla classe base.

L’ingegneria del software applicata al mondo del web è l’evoluzione che permette agli utenti che navigano su internet di interagire attivamente attraverso applicazioni web.

Il web engineering provvede a sanare i problemi del software web più comuni come la non soddisfazione dei clienti, il fallimento dei progetti a causa dei ritardi, il superamento del budget oppure la pessima documentazione correlata al progetto;

Incorpora molti approcci della software engineering applicata però alla sfera web, in cui cambiano per esempio il ciclo di vita o i metodi di programmazione .

Il processo di sviluppo ha quattro funzioni fondamentali:1. Fornire indicazioni precise sull’ordine delle attività da svolgere2. Specificare quali elaborati sviluppare3. Dirigere il lavoro dei singoli sviluppatori e del gruppo nel suo insieme4. Offrire criteri per il controllo e la valutazione degli elaborati e delle attività

Il modello del sistema è la rappresentazione di un sistema da un particolare punto di vista. Risulta particolarmente utile per gestire la complessità dei sistemi poiché, se validi, tutti i modelli di un sistema sono consistenti tra loro e quindi intercambiabili in caso di necessità.

Esistono diversi pattern architetturali : Façade : una serie di oggetti business e di controlli costituiscono l’informazione dinamica Page compositor: ogni pagina web viene assemblata a runtime da frammenti più piccoli Templated page: una pagina template regola il comportamento di tutte le altre pagine Thin web client: sposta la logica applicativa sul server alleviando il ruolo del client (browser) Rich client: la logica business è eseguita maggiormente sul client (Applet,ActiveX,Flash) Web delivery: il browser è un dispositivo di distribuzione in sistema distribuito ad oggetti

La programmazione server-side consente di generare “dinamicamente” tutto o parte del documento HTML richiesto da un browser.

Ogni disciplina Ingegneristica associa attività di costruzione con attività di verifica dei prodotti intermedi e del risultato finale. Stesso principio va applicato ovviamente all’ingegneria del software , considerando ovviamente le dovute accezioni ai termini “costruzione” e “verifica”.

L’attività di verifica del software infatti è particolarmente difficile a causa di: Molti requisiti, spesso contrastanti, di qualità Struttura evolutiva Non linearità Distribuzione dei guasti irregolare

Si capisce che non c’è un approccio comune che può essere applicato a tutte le soluzioni, ma si deve scegliere in base alle esigenze e alle caratteristiche di ogni singolo progetto. Due concetti chiave sono:

Validazione: il sistema software soddisfa i reali bisogni dell’utente?(are we building the right software?) Esamina se il software risolve il problema per cui è stato prodotto.

Verifica: il software soddisfa la specifica dei requisiti?(are we building the software right?) E’ l’insieme delle attività che stabiliscono se il software è corretto per le specifiche

Il testing (collaudo) è un processo di esecuzione del software allo scopo di scoprirne i malfunzionamenti. Un buon test-case ha un’elevata probabilità di rilevare errori non ancora scoperti, e se ne trova qualcuno si dice che esso ha successo. Si mira a scoprire sistematicamente differenti classi di errori con il minimo sforzo.

Dimostra che il software rispetta le specifiche e i requisiti e fornisce indicazioni sull’affidabilità

Non può tuttavia dimostrare l’assenza di difetti (tesi di Dijkstra) Se si rivelano errori facilmente correggibili il test indica che il sistema è affidabile e di

qualità; oppure che i casi di test sono stati troppo leggeri (inadeguati) È impossibile fare una stima temporale di un caso di test. Se si trovano con molta frequenza errori gravi da correggere il testing mette in

discussione l’affidabilità e la qualità del progetto Alcune definizioni importanti sono:

Debugging: processo di scoperta delle anomalie a partire da malfunzionamenti noti Test case: insieme di input, condizioni di esecuzioni e un criterio di pass/fail Test case specification: requisito da essere soddisfatto da uno o più casi di test Test suite: è un insieme di casi di test per singoli moduli, sottoinsiemi, o caratteristiche Test obligation: specifica dei casi di test parziale che richiede una proprietà ritenuta

importante per il test completo

Test execution: l’attività dei casi di test e valutazione dei risultati Oracolo: descrizione del comportamento atteso valutato con il criterio pass/fail Criterio di adeguatezza: predicato su una coppia <programma, test suite>. Utile per

derivare una insieme di test obligation L’analisi statica a differenza del testing (che mira a rilevare malfunzionamenti) studia il

comportamento del programma senza eseguirlo (non prevede malfunzionamenti dinamici). Quando può essere applicata è particolarmente efficiente poiché consente di sostituire cicli macchina all’intervento umano.

L’analisi dinamica invece prende in esame l’insieme delle esecuzioni di un programma, riducendo però il numero di casi da esaminare.

Vi sono due approcci generali al testing: BLACK-BOX testing: conoscendo le specifiche funzionali si effettuano test per dimostrare

che ciascuna funzione è completamente operativa, ignorando i dettagli interni. I test sono condotti sulle interfacce software per verificare la coerenza e l’integrità dei dati senza preoccuparsi della struttura interna del software.

WHITE-BOX testing: conoscendo il funzionamento interno dei vari componenti si testa che i meccanismi funzionino correttamente. Vengono esaminati i dettagli del codice e si confrontano i cammini logici interni, consapevolmente però sapendo che non si possono percorrere tutti i cammini possibili.

Il testing di unità verifica l’unità fondamentale del software: il modulo. Si utilizzano driver che simulano i moduli chiamati e stub (moduli fittizi) per simulare i moduli gerarchicamente inferiori al modulo da testare. Sia driver che stub sono componenti onerosi poiché sebbene utili per la fase di test non faranno parte del prodotto finale.

I test di integrazione permettono di rilevare errori relativi all’integrazione tra moduli. Si consiglia infatti di costruire il sistema globale aggiungendo i moduli poco alla volta, poiché sebbene testati singolarmente, i moduli possono mostrare errori nella comunicazione con altri componenti o di interazione.

L’integrazione top-down si presenta in due approcci : Depth-first: il cammino principale d’integrazione è arbitrario. Breadth-first: i moduli vengono aggregati muovendosi orizzontalmente in ogni livello

gerarchicoSi articola in 4 passi:

1. Il main è usato come driver del test, e gli stub sono costituiti dai moduli direttamente subordinati.

2. Dopo l’integrazione di ogni modulo si eseguono i test specifici3. Alla fine di ogni test un altro modulo reale viene aggiunto sostituendo lo stub.4. Su può procedere con il testing di regressione per accertarsi che non ci siano nuovi errori.

Mostra dei chiari problemi di natura logistica poiché richiede l’elaborazione dei livelli bassi per un test accurato di quelli superiori. Per rimediare si procede con l’integrazione bottom-up

L’integrazione bottom-uo inizia partendo dai moduli al livello più basso (quelli senza figli) eliminandola necessità degli stub. Si articola in diversi passi:

1. Aggregazione dei moduli di basso livello in gruppi (cluster) che eseguono una sottofunzione2. Realizzazione di un driver per coordinare l’esecuzione3. Test del cluster4. Sostituzione dei driver con i moduli reali aggregati al programma

In definitiva i principali vantaggi del top-down sono gli stub, mentre il bottom-up non permette di vedere il programma vero e proprio finchè non è aggregato l’ultimo modulo(il main) a vantaggio per dei test case che sono più semplici da progettare poiché non esistono stub e i driver sono meno onerosi.

Il software infine viene integrato con altri elementi del sistema (hardware, informazioni..) e il tutto viene testato e validato; questo passaggio non è condotto solo dall’ingegnere del software, anzi è anche l’utente che attraverso i test di accettazione contribuisce alla scoperta di eventuali bug o problemi.

La fase di Validazione&Verifica può iniziare addirittura prima che il software esista e dura ben oltre la consegna del prodotto stesso. In genere va dallo studio di fattibilià fino alla manutenzione.

Non esiste una buona tecnica di Analisi&Test generica da applicare a tutte le soluzioni. Si procede spesso nel combinare le varie tecniche a seconda delle esigenze.

Sebbene il testing miri a rilevare i guasti, dev’essere chiaro che non è mai possibile rimuovere tutti i guasti. Si decide pertanto di rilasciare il prodotto quando si raggiunge il livello di qualità prestabilito, ignorando piccoli malfunzionamenti difficilmente eliminabili in questa release.

Un buon prodotto software non ha una sola release. Il test e l’analisi infatti non terminano alla prima release, e contribuiscono alla correzione dei malfunzionamenti per i futuri rilasci.

Quando si progetta bisogna sempre cercare di non commettere gli stessi errori di un precedente processo. Obiettivo fondamentale è il miglioramento della qualità del processo, vediamo come:

Definire i dati da collezionare e implementare procedure per collezionarli Analizzare i dati raccolti per identificare le classi di guasti rilevanti Analizzare le classi di guasto selezionate per identificare problemi nello sviluppo e nella

misurazione della qualità Intervenire sul processo di sviluppo e sulla gestione della qualità

Random testing: si scelgono gli input in modo uniforme evitando la possibile influenza del progettista nella scelta; gli input vengono trattati tutti allo stesso modo

Systematic testing: si selezionano gli input particolarmente rilevanti, scegliendo tra i valori di classi che tendono a fallire spesso o a non fallire mai.

Il test funzionale appartiene alla tipologia sistematica e non random così da garantire una distribuzione non uniforme dei fault. Lo scopo del test funzionale è quello di scovare i problemi, e cercare di rimuoverli sistematicamente.

Grazie al partizionamento dei test si può andare a cercare prima nelle regioni in cui gli input assumono sicuramente valori particolari o propensi a contenere fault. Purtroppo non sempre gli input causano fallimenti addensati in un'unica zona, ma sparsi.

Il partizionamento dello spazio degli input viene fatto grazie allo studio delle specifiche (formali o informali). I test vengono condotti sulle interfacce software per verificare che:

Gli input siano accettati in modo appropriato Gli output siano corretti Le informazioni esterne mantengano l’integrità delle informazioni

Data la vastità delle combinazioni di ingresso-uscita il dominio degli input viene suddiviso in classi di dati; un test-case ideale rileva da solo una classe di errori. Ogni classe rappresenta l’insieme degli stati validi/non validi per le condizioni d’ingresso (intervallo di valori, insieme di valori, condizione booleana).

Il test funzionale è la tecnica base per progettare i casi di test. Risulta essere efficace temporalmente, efficiente, ampiamente applicabile, economico. Non necessita del codice del programma nei test preliminari e permette già da subito notevoli benefici. Non è alternativa al test strutturale ma complementare.

È possibile applicare il test funzionale a tutti i livelli di granularità: Unità Integrazione Sistema (non presente nel test strutturale) Regressione (non presente nel test strutturale)

Il test combinatoriale consiste nella strutturazione (manuale) delle specifiche di test in un’insieme di proprietà che possono essere sistematicamente variate in insiemi di valori. I principali vantaggi sono l’automatizzazione dei test, la possibilità di ridurre l’intero spazio dei valori in un subset, e il poter ottenere combinazioni rappresentative per una funzionalità.

I due approcci per il testing combinatoriale sono:

Partition testing: identificazione manuale degli attributi nello spazio degli input e applicazione di vincoli per ridurre il numero dei casi di test secondo ipotesi di compatibilità, di errore o singolarità.

Pairwise testing: identificazione degli attributi dello spazio degli input; gli attributi appartengono ad un set di valori ridotto considerando coppie dei valori degli attributi. L’idea è che la maggior parte dei fallimenti software sono dovuti a combinazioni di coppie/triple di input.

Per la vasta tipologia degli errori, alcuni dei quali non possono essere rilevati dal black-box testing, si procede con il test funzionale, il quale permette una maggior comprensione degli errori logici, e maggiore probabilità di innescare casi speciali. Sono esaminati i dettagli procedurali e i cammini logici interni (non tutti)

Un Call Graph (CG) è un grafo orientato che rappresenta le relazioni chiamante-chiamato tra procedure. I nodi rappresentano le procedure e gli archi le relazioni di chiamate tra esse.

A seconda della scelta dei criteri di valutazione si possono rilevare diverse classi di errore; tuttavia la coverage piena è difficilmente raggiungibile. Si adopera infatti piuttosto che sull’adeguatezza piena, sul ‘’grado di adeguatezza’’ di una test suite.

Oltre alle tecniche di tipo combinatoriale le specifiche dei casi di test possono essere derivate in un modello, ovvero una descrizione “conveniente” del sistema. I modelli sono più semplici dei sistemi che descrivono e ne facilitano la comprensione.

Il model-based testing è una tecnica in cui il comportamento a tempo d’esecuzione di una implementazione viene verificato rispetto alle predizioni fatte da una specifica formale (modello). In poche parole il modello descrive come un sistema dovrebbe comportarsi quando sottoposto a stimoli.

I modelli possono essere estratti dalle specifiche o dal design, permettendo di sfruttare informazioni riguardo il comportamento atteso.

Per generare la sequenza dei casi di test possiamo adottare diversi criteri : Random walk (simile al random testing) All transitions (copertura delle transizioni) All state (copertura degli stati) Shortest paths first Most likely paths first

I vantaggi dell’approccio model-based sono la semplicità nel trovare i casi di test, i bassi costi nella manutenzione e nella ricerca dei casi di test. L’unica parte più complessa è la creazione del modello, per cui richiede competenze e test di conformità.

Il reverse engineering è quel processo che consente di derivare la progettazione e le specifiche dal codice sorgente.

L’obiettivo del re-engineering dei dati è il migliorare la struttura del sistema per renderla più semplice da capire, da mantenere e per apportare cambiamenti pianificati. Il processo di re-engineering può prevedere: source code translation, reverse engineering, program structure improvement, program modularisation e re-engineering dei dati.

Concurrent Version System (CVS) : controllo delle versioni che fornisce un accesso controllato ai file mediante la storia dei cambiamenti. È un sistema client-server con strumenti di check-out e check-in. Il numero di revisione permette diramazioni per supportare l’evoluzione parallela dei files. Lo sviluppo delle diramazioni può avvenire benissimo in parallelo al flusso principale (trunk)

La stima dei costi è essenziale in fase di pianificazione, ed essenziale per valutare: Vantaggi legati all’investimento in strumenti moderni Adozione di metodi formali Quanti benefici porterà l’aggiunta di una funzionalità al prodotto e quanto costerà in

termini di tempo Qual è il numero di progettisti necessari Se applicare o meno azioni correttive al ciclo di sviluppo

È influenzata dalla misura della produttività de personale coinvolto e dalla misura delle complessità del software.

La metrica di produttività misura la quantità di valore o di funzionalità prodotta per unità di tempo. I punti funzione (function point) sono una possibile metrica per la stima dei costi. Si vincolano dalla tecnologia usata e sono applicabili nelle prime fasi del ciclo di sviluppo del SW.

La function point analysis introduce una metrica che quantifica le funzionalità di un sistema software. L’analisi è rivolta alle funzionalità già delineate dalla fase di analisi dei requisiti. Il conteggio dei FP avviene iterativamente e l’unica cosa necessaria è la conoscenza dei requisiti funzionali. Può essere adottata anche in fase di manutenzione, ed è adatta ai software gestionali.

Il conteggio dei FP avviene in due passi consecutivi:1. Valutazione degli Unadjusted Function Point (UFP)2. Valutazione dei fattori di Aggiustamento

Il COCOMO (constructive cost model) è un modello per la stima dei costi. Assume che il ciclo di sviluppo sia a cascata proponendo tre diversi livelli di dettaglio: Basic :stima veloce dei costi; abbastanza approssimato Intermediate: aggiunge fattori correttivi alla stima effettuata dal basic Detail: procede come l’intermediate ma si sofferma su ogni fase del ciclo di sviluppo del SW

È un modello empirico nato negli anni 80 tramite il quale è possibile ricalcolare rapidamente il valore della stima variando il valore dei fattori correttivi. Non fornisce una stima accurata dei costi ma rimane uno strumento molto valido. È fortemente legato al ciclo di sviluppo a cascata e alla stima delle linee di codice del prodotto.

L’evoluzione del modello precedente è il COCOMO II il quale supera il limite del modello a cascata, adottando altri modelli e metodologie (agili). Si compone di altri modelli e usa gli Objects Point: non conta il numero di oggetti in un applicazione poiché il loro valore è dato dalla somma pesata di diversi fattori. Si distingue dalla prima versione poiché stima il costo in base alla sua effettiva costruzione il progetto è già disponibile.