Qualit del Software: si intende linsieme di attributi che caratterizzano un bene o un servizio, e che ne

determinano la capacit di soddisfare i bisogni impliciti e espliciti dellutenza. Parlando di qualit del software, distinguiamo fra: Qualit del processo Qualit del prodotto: o Qualit esterne: percepite dagli utenti. o Qualit interne: percepite dagli sviluppatori.

Norme internazionali (ISO 9126):

1. Funzionalit Correttezza: coerenza delle funzioni offerte dal prodotto rispetto alle esigenze dellutenza. Accuratezza: precisione dei risultati prodotti. interoperabilit: capacit del prodotto di interagire con altri sistemi software. Conformit: a standard, convenzioni o regolamenti rilevanti per il settore applicativo del prodotto. Sicurezza: capacit del prodotto di prevenire accessi non autorizzati alle informazioni e funzioni gestite dal prodotto. 2. Affidabilit. Maturit: distribuzione dei malfunzionamenti in funzione degli errori presenti nel software. Tolleranza ai guasti: capacit di mantenere livelli predeterminati di prestazioni anche in presenza di malfunzionamenti o utilizzi scorretti del prodotto. Robustezza: capacit del prodotto di ripristinare il livello appropriato di prestazioni del prodotto e di recuperare tutte le informazioni rilevanti a valle di un malfunzionamento del prodotto. 3. Usabilit Comprensibilit: facilit di comprensione per lutenza dei concetti del prodotto. Apprendibilit: facilit di apprendimento del prodotto. Facilit di utilizzo del prodotto da parte dellutenza. 4. Efficienza Prestazioni temporali: grado di efficienza dal punto di vista dei tempi di risposta. Utilizzo delle risorse: grado di efficienza nellutilizzo delle risorse di sistema. 5. Manutenibilit Analizzabilit: facilit con la quale possibile localizzare un errore nel codice del prodotto. Modificabilit: facilit con la quale possibile cambiare il codice del programma. Stabilit: livello del rischio di effetti indesiderati attraverso la modifica del codice. Controllabilit: sforzo necessario per verificare il programma. 6. Portabilit Adattabilit: capacit del prodotto di essere adattato a diversi ambienti operativi. Installabilit: facilit di installazione del prodotto. Conformit: a standard relativi alla portabilit. Intercambiabilit: facilit con cui si pu utilizzare il prodotto al posto di un altro componente.

Il processo di sviluppo software: framework allinterno del quale si svolgono le attivit necessarie per
produrre software di alta qualit. Un generico processo di sviluppo software costituito da uno o pi set di Attivit portanti (progettazione dellarchitettura, suddivisione del prodotto in moduli, codifica, controllo di avanzamento..), alle quali si affiancano le Attivit ausiliarie.(project management, revisioni tecniche formali, documentazione..).

Capability Maturity Model: individua un insieme di capacit corrispondenti al livello di maturit di processo di una
software house. Misura esclusivamente la validit di processo. CMM prevede 5 livelli di valutazione, ad ognuno dei quali sono associate pi Key Process Areas (KPA). Per conseguire un livello bisogna soddisfare tutte le sue KPA. Ogni KPA si articola in pratiche: obbiettivi, impegni, capacit, attivit, metodi di controllo, metodi di verifica. Livello Iniziale: il processo di sviluppo definito di volta in volta. Risulta confuso, spesso non nemmeno definito. Livello Gestito: nell'azienda esistono processi basilari per la gestione dei progetti, al fine di tenere sotto controllo costi, tempi e soddisfacimento dei requisiti. Le metodologie usate in progetti di successo precedenti vengono ripetute in progetti successivi. Livello Definito: il processo conforme ad uno standard aziendale definito, stabile e documentato sia per quanto riguarda le attivit portanti che per quanto riguarda le attivit ausiliarie. Livello Gestito Quantitativamente: sia il prodotto sia il processo software sono valutati quantitativamente e qualitativamente sulla base di misure dettagliate. Livello Ottimizzato: utilizzo di tecnologie e metodologie innovative al fine di raggiungere un livello ottimo di gestione del processo software e sviluppo del prodotto.

Modelli di processo: la strategia adottata da unazienda per gestire il processo di sviluppo software.
Lo status quo dello sviluppo software viene modificato attraverso delle iterazioni che prevedono: - La definizione del problema - Lo sviluppo tecnico - Lintegrazione della soluzione Una iterazione produce un nuovo status quo che pu essere modificato con successive iterazioni.

Modelli prescrittivi
Sequenziale lineare: seq. di fasi, ciascuna delle quali produce un output che costituisce linput per la fase successiva. Allinizio di ciascuna fase si verifica la qualit del lavoro effettuato nella fase precedente. Le fasi sono: strutturazione e modellazione del sistema e dei dati, analisi dei requisiti, progettazione, codifica e testing. Si applica sia alla realizzazione iniziale di un software, sia alla sua manutenzione. Vantaggi: semplice da capire e da organizzare con una divisione del lavoro accentuata; Svantaggi: Altamente rischioso. I primi risultati visibili/comprensibili, arrivano verso fine progetto. Si basa su assunzioni il pi delle volte sbagliate. (Es. in fase iniziale di progetto chiarire tutti i requisiti del sistema. Definiti i requisiti, gli stessi non cambino pi fino termine progetto. Definire requisiti,stimare tempi/costi di progetto senza possedere competenza necessaria sugli aspetti tecnici ed implementativi). Incrementale: offre una serie di rilasci chiamati Incrementi. Ad ogni incremento aumentano progressivamente le funzionalit offerte al cliente. Il primo incremento fornisce la base(cuore) del prodotto. I successivi incrementi vengono effettuati dopo una primo utilizzo/valutazione del prodotto da parte del consumatore. Questo processo viene ripetuto fino al completo soddisfacimento del cliente(rilascio completo del prodotto). Vantaggi: consegna di qualcosa di concreto prima daver completato lintero sistema. Maggiore flessibilit nellassegnazione delle persone ai compiti progettuali; Svantaggi: condivide le assunzioni errate del precedente. Prototipale: prevede una prima fase di raccolta dei requisiti(massimale/incompleta). Una seconda di progettazione del prototipo, sulla base dei requisiti raccolti nella fase precedente e una di realizzazione del prototipo. Questultimo deve soddisfare i requisiti noti al momento dello sviluppo, ma non le caratteristiche fondamentali del software di qualit;il prototipo serve al committente per valutare laderenza dellapplicaz alle proprie necessit. Il feedback dellutente permette di generare un ulteriore prototipo raffinato per arrivare infine alla fase di ingegnerizzazione la quale prevede di gettare il prototipo. Vantaggi: il committente vede crescere il prodotto. Sviluppatore agevolato. Tempi di sviluppo molto rapidi(apparent). Svantaggi: Prodotto funzionante ma spesso di scarsa qualit. Difficolt e costi della fase di ingegnerizzazione sono percepiti con difficolt dal committente. A spirale: modello di sviluppo di tipo Iterativo. Strategia realistica per lo sviluppo di sistemi sw di grande dimensioni. La spirale parte dal centro, con un insieme di obiettivi e requisiti iniziali per il progetto. Ogni ciclo comporta leffettuazione di una serie di attivit, dette task regions(comun con il cliente, pianificaz., analisi rischi, progettaz. ecc). Larticolazione di un progetto iterativo guidata da una gestione sistematica dei rischi di progetto, per arrivare alla loro progressiva diminuzione. Inizialmente con la costruzione di prototipi e successivamente ogni iterazione ha lo scopo di costruire in modo progressivo, nuove porzioni del sistema verificate dal committente. Vantaggi: gestione dei rischi attraverso iterazioni volte alla loro progressiva riduzione. Maggiore qualit dei prodotti, costi e tempi inferiori. Svantaggi: impossibile prevedere il n di iterazioni, durata, e obbiettivi specifici. Richiede un controllo sistematico degli avanzamenti. Deve esistere collaborazione sistematica tra committenti e gruppo di progetto. Cleanroom: consiste nellevitare la dipendenza da costosi processi di rimozione degli errori scrivendo porzioni di software correte per principio, e verificandone la correttezza prima del collaudo. Si basa sullutilizzo combinato di: specifiche formali di progetto, verifica di correttezza, tecniche di SQA su base statistica. Adotta il modello di processo di tipo incrementale.

Per ogni incremento: si definisce una descrizione informale dei requisiti a livello utente. Si descrivono le specifiche di progetto mediante strutture a scatole e metodi formali. Progettazione e sviluppo vengono effettuati mediante raffinamento delle specifiche formali. Le box structures vengono progressivamente estese e dettagliate fino ad avere un design completo della porzione di codice da sviluppare nellincremento. Il team di sviluppo effettua le verifiche di correttezza dellapplicazione in ogni stadio del ciclo di vita: dalle semplici specifiche di progetto, allarchitettura, allo sviluppo. Segue una fase finale delle verifiche di correttezza, rivolta al riesame del codice sorgente. Si progettano ed eseguono i test cases in modo da esercitare il software secondo una distribuzione probabilistica delluso; quando si raggiunto il livello desiderato di affidabilit la porzione di software certificata. Vantaggi: la verifica di correttezza un processo finito. Ogni elemento di specifica, progettazione e codifica viene esaminato ed approvato dallintero team. Gli errori vengono individuati prima rispetto allo unit testing. La qualit ottenuta mediante progettazione rigorosa. Resistenze: diffusa convinzione che sia troppo teorico, troppo matematico, troppo radicale per essere utilizzato. Richiede la padronanza dei metodi formali o altre tecniche a base matematica. Richiede la sostituzione dello Unit Testing con le verifiche di correttezza e il controllo statistico della qualit. Immaturit dellindustria software. Linvestimento necessario per implementare Cleanroom elevato. Unified Process: processo di sviluppo, orientato allo sfruttamento delle caratteristiche UML (non uno standard). E utilizzato in ambiti applicativi molto diversi. Risponde agli obbiettivi primari di time to market, controllo del rischio e visibilit degli stati di avanzamento. Le caratteristiche principali del processo RUP(schema generale di processo) sono: guidato dai casi duso (Use cases), incentrato sullarchitettura del sistema, iterativo ed incrementale. Fasi di RUP Avvio: definizione dei limiti, della fattibilit tecnica e della giustificazione economica dellintervento. Questa fase si pu considerare conclusa quando gli obbiettivi vengono consolidati e reputati fattibili. Elaborazione: approfondimento dei requisiti e delle caratteristiche funzionali, strutturali e tecniche del sistema. Questa fase si pu considerare conclusa quando larchitettura e i requisiti sono consolidati. Costruzione: produzione incrementale del sistema. Questa fase si pu considerare conclusa quando il prodotto software completamente testato, sufficientemente stabile da poter essere sottoposto agli utilizzatori. Transizione: completamento del sistema, attraverso rimozione degli errori e produzione della versione rilasciabile. Questa fase si pu considerare conclusa quando il committente soddisfatto e tutti sono concordi nel considerare il progetto completato. Per ogni fase sono previste pi iterazioni a grana fine. - Discipline di RUP: in ogni fase si svolgono diverse tipologie di attivit, denominate discipline. Alcune vengono svolte una tantum altre iterativamente e sono: Business modeling, requirements, analysis e design, implementation, test, deployment, config. e change management, project management, environment. Vantaggi: processo ampiamente utilizzato, sperimentato e consolidato. Comprende una notevole mole di documenti, linee guida, esempi Definisce in modo molto approfondito i ruoli coinvolti nel processo di sviluppo, le attivit da effettuare, i documenti in input e output alle diverse attivit, gli strumenti per supportare il processo di sviluppo. Svantaggi: ha costi piuttosto elevati in termini di impatto organizzativo, impatto culturale, impatto tecnologico.

Processi agili
Extreme Programming (XP): una disciplina di sviluppo sw basata su valori di semplicit, comunicazione , feedback continuo e basata su una serie di pratiche tra cui: Whole Team: rifiuta la suddivisione dei compiti in ruoli rigidi. Ogni persona coinvolta nel processo di sviluppo. Il committente fa parte del team e lavora con gli sviluppatori per lintera durata del processo. Planning Game: Prevede due tipi di pianificazione: Release Planning: il committente presenta al team I propri requisiti che vengono valutati in termini di costi e difficolt di realizzazione(stima imprecisa). Iteration Planning: costruisce il codice mediante iterazioni di durata prefissata con lobbiettivo di produrre sw funzionante al termine di ogni iterazione. Il committente vede crescere il prodotto e pu controllare il progetto. Customer Test: il committente definisce obbligatoriamente i test di accettazione. Small Releases: il team realizza piccoli rilasci, release parziali del prodotto da consegnare. Simple Design: si cerca di scegliere sempre la soluzione pi facile ad un problema.

Pair Programming: lattivit di stesura del codice svolta da coppie di programmatori che lavorano sulla stessa macchina. Produce codice migliore, pi efficiente e con meno errori. Si diffonde la conoscenza attraverso il team, se le coppie cambiano durante lo sviluppo del progetto. Test-Driver Development: sviluppo ossessivamente guidato dai test che devono essere eseguiti con esito positivo ogni volta che un programmatore modifica una singola riga di codice sorgente. Continous Integration: ogni modifica apportata al codice da ogni singolo membro del team di sviluppo, viene integrata attraverso un processo di build che ne verifica, la qualit e la coesione con il resto del codice. Collective Code Ownership: ogni coppia di programmatori pu liberamente modificare porzioni di codice scritte da altri. Il codice riceve le attenzioni di pi programmatori e risulta migliore e meno incline agli errori. Coding Standard: XP incoraggia ladozione di stili e standard di codifica comuni per tutti gli sviluppatori, in modo che sembri sviluppato da una sola persona (codice autoesplicativo). Metaphor : XP promuove ladozione di terminologia comune allinterno di team per evitare incomprensioni. Sustainable Pace: livello di sollecitazione e impegno sostenibile da tutti quelli del team per un periodo di durata indefinita. Vantaggi: Processo molto efficiente, in grado di fare fronte al cambiamento di requisiti. Risultati migliori di qualit del prodotto, favorisce la creazione di team coesi, molto apprezzato da chi lo pratica. Svantaggi: lazienda difficilmente mette a disposizione una propria persona per lintera durata del progetto. Profonde trasformazioni degli aspetti organizzativi e delle politiche del personale. Non tutti sono in grado di lavorare in gruppi. Richiede lutilizzo di strumenti di sviluppo evoluti. Scrum: prodotti intermedi flessibili, pianificazione flessibile, gruppi piccoli, revisioni frequenti, collaborazione, approccio orientato agli oggetti. Pre-Game e Post-Game sono processi definiti e i loro input e output sono definiti. Game composto da un numero imprecisato di sprints (processo empirico che richiede controlli dallesterno). Le caratteristiche del prodotto possono essere modificate durante Pre-Game e Game. Pre-Game Planning: definizione del prodotto basata su gli elem. in possesso del gruppo di lavoro (requisiti del committente, conoscenza del dominio applicativo, esperienza del team, strumenti di sviluppo,). Architecture: definizione delle modalit con cui i requisiti verranno soddisfatti. Game: serie di attivit intensive a durata limitata, denominate sprint che si articola in 4 parti: Develop: normale ciclo di sviluppo (analisi, design, sviluppo, test, stesura di documentazione). Wrap: assemblaggio dei componenti al fine di creare un prodotto intermedio eseguibile. Review: incontro dei team per discutere del proprio lavoro e dei problemi. Adjust: il risultato dellincontro si traduce in aggiustamento dei componenti. Durante lo sprint obbligatorio effettuare quotidianamente uno scrum(riunione di 15 min) per identificare i colli di bottiglia dello sviluppo. Post-Game: Closure: avviene quando il management stabilisce che gli sprint hanno portato al miglior compromesso possibile fra le variabili che influenzano il progetto. Vantaggi: permette di lavorare in modo produttivo anche in situazioni caotiche. Orientato ai risultati concreti e alla gestione dei cambiamenti. Favorisce la creazione di team coesi. Pu essere adottato da ogni organizzazione. Svantaggi: definisce solo pratiche di project management, deve essere integrato con altri approcci per coprire le parti mancanti.

l paradigma orientato agli oggetti (OOP): OOP permette di descrivere un problema reale nei termini
del problema reale. Oggetto= rappresentazione di un elemento del problem space.

Caratteristiche degli oggetti (base del paradigma O-O)

Un oggetto rappresenta il modello di un qualsiasi elemento del mondo reale. Un programma un insieme di oggetti che interagiscono tra loro. Ogni oggetto immagazzina dei dati al suo interno. Ogni oggetto appartiene ad un determinato tipo (o classe). Tutti gli oggetti di un determinato tipo possono ricevere gli stessi messaggi.

Oggetto: entit strutturata dotata di identit(espressa da un nome comprensibile), stato(include i nomi degli attributi),comportamento(rappresentato da metodi,che utilizzano/cambiano il valore degli attributi delloggetto) la cui struttura invisibile allesterno delloggetto. Variabili di istanza: variabili contenute nelloggetto che rappresentano il suo stato interno. Messaggio: richiesta ad un oggetto di invocazione di uno dei suoi metodi. Metodo: azione che accede/manipola lo stato interno delloggetto. Classe: nome collettivo di tutti gli oggetti con stessi metodi,variabili di istanza, aventi le stesse caratteristiche.

Vantaggi della programmazione ad oggetti (Riuso - Modularit)

Riuso: benefici Riduzione dei tempi di sviluppo. Minore manutenzione. Maggiore robustezza e affidabilit. Maggiore efficienza, maggiore consistenza. Riuso: resistenze Problemi tecnici: i moduli per essere riusabili devono essere riadattabili. Problemi non tecnici: paura ad affidarsi al codice scritto da altri. Paura di perdere efficienza. Timore di non riuscire a gestire componenti riusabili quando crescono in numero. Modularit: un sistema modulare se diviso in parti che hanno una sostanziale autonomia individuale ed una ridotta interazione con le altre parti. Lobbiettivo la riduzione della complessit. Nellapproccio tradizionale alla programmazione un modulo pu essere una procedura, libreria, pool di dati. La metodologia di riferimento la decomposizione funzionale TOP-DOWN. Nellapproccio o-o, il concetto di modulo espresso dalla classe. La metodologia di riferimento BOTTOM-UP.

Il modello di processo ad oggetti: il modello a oggetti influenza tutte le fasi del ciclo di vita.
Object-Oriented Analysis (OOA) Object-Oriented Design (OOD) Object-Oriented Programming (OOP)

Caratteristiche della programmazione ad oggetti

Incapsulamento: meccanismo di programmazione che riunisce il codice ed i dati da esso manipolati, proteggendoli da interferenze esterne e da un utilizzo scorretto. Information Hiding: nascondere tutti i dettagli di un oggetto che non concorrono alla sua natura essenziale visibile dallesterno. Allinterno di un oggetto, le funzioni, i dati o entrambi possono essere: Public: il dato e la member function sono accessibili a chiunque. Private: solo il creatore della classe pu accedere al dato e alla member function. Protected: il creatore della classe e le classi derivate possono accedere al dato e alla member function. Ereditariet: derivare una classe preesistente(Classe Base), mantenendo tutte le caratteristiche della classe di partenza, ma integrandole con modifiche ed estensioni(Classe Derivata). Duplicazione dellinterfaccia: tutti i metodi che possono essere invocati per la classe base possono essere invocati anche per la classe derivata. La classe derivata dello stesso tipo della classe base. Estensione della classe: ci sono due modi per differenziare la classe derivata dalla classe base: Aggiungere alla classe derivata dei metodi che la classe base non possiede. Overriding: Implementare nella classe derivata un metodo della classe base in modo diverso rispetto alla classe base. Polimorfismo: meccanismo grazie al quale un singolo nome di operazione o di attributo pu essere definito per pi di una classe e pu assumere diverse implementazioni in ciascuna di quelle classi. Upcasting: processo in base al quale trattiamo un oggetto di classe derivata come se appartenesse alla sua classe base. Late binding: quando la scelta di quale implementazione del metodo eseguire non conosciuta dal compilatore ma determinata a runtime in base all'oggetto realmente istanziato. Early binding: quando il compilatore gi in grado di determinare, prima della esecuzione del programma, quale la variabile che verr utilizzata o quale la implementazione del metodo che verr eseguita.

Unified Modeling Language (UML):

un linguaggio di modellazione standard, progettato per agevolare il processo di elaborazione di modelli: visualizzare il sistema, specificare la struttura ed il comportamento del sistema, implementare il sistema, documentare tutte le decisioni prese durante le varie fasi di lavoro. UML definisce 5 punti di vista sullarchitettura di un sistema: degli Uses Cases: coinvolge utenti e sistemi esterni: descrive cosa far il sistema senza specificare come lo far. del progetto:descrive gli elementi strutturali, dinamici e comportamentali del sistema. del processo: descrive gli aspetti legati al flusso di controllo del sistema ed alla sua temporizzazione. dellimplementazione: descrive i vari componenti del sistema, prodotti dai vari attori del processo, che devono essere assemblati al fine di implementare la soluzione software. del deployment: descrive la topologia del sistema: si focalizza sulla distribuzione dei vari componenti sw e hw.

Classificazione dei diagrammi

Diagrammi strutturali: Class, Object, Component, Deployment, Package. Diagrammi comportamentali: Use Cases, Activity, Statechart, Sequence, Collaboration. - Diagramma delle classi: rappresenta le classi del sistema in via di sviluppo. Costituisce lo strumento principale per rappresentare graficamente ed illustrare la struttura del sistema. Mostra gli attributi e le operazioni delle classi, e i vincoli che si applicano ai collegamenti fra gli oggetti. Nome della classe Attributi

Operazioni (metodi)

Gli attributi sono espressi nella forma:

-

visibilit nome : tipo [molteplicit] [stringa di propriet]

Tutti gli elementi possono essere omessi ad eccezione del nome dellattributo. Visibilit: indica se lattributo pubblico o privato. Nome: identificativo univoco dellattributo allinterno della classe. Tipo: data type dellattributo. Pu essere predefinito (integer, boolean) oppure una classe definita dallutente. Molteplicit: indica quanti elementi costituiscono lattributo. *1+ *0...1+ *0*+ Stringa di propriet: si utilizza per specificare caratteristiche aggiuntive dellattributo. {ordered} {readOnly} Le operazioni sono espresse nella forma: visibilit nome : (parametro : tipo, parametro tipo, ):tipo Esempio: + controllaData (data : date) : boolean

Associazione: modo alternativo per rappresentare una propriet. E il tipo pi comune di Relazione fra classi.
La direzione della freccia indica la navigabilit dellassociazione. Lassociazione Ordine -> RigaOrdine indica che RigaOrdine un attributo della classe Ordine.

Gli attributi dentro la classe vengono usati per i dati di minor rilevanza, come date o flag booleani. Gli oggetti pi complessi e strutturati, per i quali si definisce una classe apposita, si usa lassociazione fra classi, che permette inoltre la rappresentazione della relazione molti-a-uno fra classi.

Associazione Bidirezionale

Classi di associazioni
Viene utilizzata per modellare associazioni complesse che al di l delle classi che collegano, presentano caratteristiche peculiari. Utile nel caso di relazioni molti-a-molti. Es. LibroAutore mette in relazione un Autore con un Libro specificando il ruolo di quella relazione: lAutore pu essere lautore principale,un collaboratore, leditor

Generalizzazione: tipo di relazione che viene utilizzata quando una classe un caso particolare di unaltra.
La generalizzazione la rappresentazione UML di uno dei concetti portanti della programmazione ad oggetti: lereditariet. Tutti i linguaggi ad oggetti permettono di definire classi derivandole da altre classi gi esistenti: la sottoclasse eredita tutte le caratteristiche della classe base e le integra con altre.

Dipendenza: si ha una dipendenza fra due classi di un diagramma se

la modifica alla definizione delluna comporta una modifica dellaltra. Si tratta di un caso particolare di associazione. La classe A dipende dalla classe B

Aggregazione
Tipo particolare di associazione: una relazione tutto/parte nella quale una classe parte di unaltra classe. La classe associata al rombo la classe intera, la classe allaltro estremo la sua parte. Se unistanza della classe aggregata viene eliminata, allora anche la corrispondente istanza della classe parte viene eliminata, in quanto non ha pi ragione di esistere. - Diagramma degli oggetti: del tutto analogo al diagramma delle classi, con la differenza che vengono rappresentate istanze delle classi. Nome della classe a cui loggetto appartiene viene specificato dopo un segno di due punti; se necessario il nome proprio delloggetto (istanza viene rappresentato prima dei due punti. Il nome delloggetto sottolineato. Ogni attributo della classe ha un valore specifico per ogni oggetto appartenente a quella classe(istanza).

Funzioni astratte e classi astratte/concrete

Funzione astratta: una funzione che viene definita nella classe base, ma non pu essere implementata in essa. Una classe che contiene almeno una funzione astratta detta Classe Astratta, e il suo nome viene indicato in corsivo oppure con letichetta ,abstract-. Classe astratta: una classe dalla quale non possibile istanziare oggetti(normalmente, perch la classe ha una o pi operazioni astratte). Una classe astratta in genere utilizzata come origine dalla quale una classe discendente eredita e definisce le proprie operazioni concrete. FormaGeom un elemento logico a cui non corrisponde nulla di fisico: nel sistema esistono Quadrati, Triangoli e Rettangoli, ma a FormaGeom non corrisponde nulla di fisico: non ha senso parlare di figure geometriche in generale, quando per FormaGeom non possibile calcolare larea. In altri termini, la classe astratta FormaGeom non pu essere istanziata.

Tuttavia utile per raggruppare le caratteristiche comuni a tutte le forme geometriche(calcolo della posizione) e dichiarare quali sono le caratteristiche che tutte le figure geometriche devono possedere (il calcolo dellarea). Classe concreta: una classe dalla quale possibile istanziare oggetti.

Principio di Sostituibilit li Liskov

Oggetti di una classe derivata (subclass) sono sostituibili ad oggetti della classe pi generale. Classe Interfaccia: una classe completamente astratta (cio non contenente limplementazione di nessun metodo).

Steriotipi: Gli stereotipi sono unestensione al vocabolario di base UML, al fine di rappresentare costrutti di
modellazione simili ad elementi UML gi esistenti (Es. interface, create,become..).

Vincoli
Costrutto UML utilizzato per estendere la semantica di un elemento del modello. Vengono utilizzati nei diagrammi UML per specificare delle condizioni che devono essere sempre soddisfatte da un elemento del modello. Possono essere applicati a attributi di una classe o a relazioni fra classi.

Template
Un Template di classi un costrutto che rappresenta una famiglia di potenziali classi. Un template presenta un insieme di parametri formali. Un tipico esempio di template sono le Classi Contenitore. Classe contenitore: classe progettata per contenere oggetti di altre classi, in modo tale che pu contenere qualunque tipo di oggetti, il numero di oggetti da contenere non noto a priori e pu variare dinamicamente al runtime, possibile accedere agli elementi contenuti in modo semplice e intuitivo.

Package: raggruppamento concettuale di elementi che fanno parte del modello. Utili per
suddividere il modello in sottosistemi anche al fine di suddividere il lavoro su pi team di sviluppo. In genere vengono usati per raggruppare classi. Unica regola: un elemento di un modello UML pu appartenere ad un solo package.

Use cases: rappresentano la specifica UML per lidentificazione dei requisiti del sistema. Gli Use Cases prevedono
dei ruoli interpretati dagli Attori del sistema. Un Attore rappresenta: un ruolo interpretato da un utente nellinterazione con il sistema oppure unentit allesterno del sistema stesso. Un utente pu prendere parte a pi use cases. Use Case sono una sequenza di azioni compiute da un attore allinterno del sistema al fine di ottenere un determinato scopo. Linsieme di tutti gli Use Cases di un sistema esprime i requisiti funzioni espressi dal committente.

Flussi di eventi: rappresentano la sequenza di azioni dellattore e risposte del sistema a tali azioni, che si
susseguono durante il processo di interazione fra lutente ed il sistema. In ogni sistema di delineano due tipologie di flussi di eventi: - Flusso di eventi principali: descrive il fluire del processo di interazione che si verifica in mancanza di errori da parte degli attori o del sistema. Ogni Use Case deve avere un flusso di eventi principale. - Flusso di eventi eccezionale: un percorso attraverso lo Use Case che descrive una condizione di errore o quantomeno una situazione limite che si verifica raramente.

Relazioni fra Use Cases

Inclusione: relazione in cui uno Use Case include esplicitamente il comportamento di un altro use case in un punto specifico del corso dazione. Viene usato al fine di circoscrivere comportamenti che si ripetono in pi punti del sistema, e che come tali si ripeterebbero in pi use cases. Estensione: relazione in cui uno use case base include implicitamente il comportamento di un altro use case in uno o pi punti specifici del corso dazione, detti Punti di estensione. Viene usato al fine di delineare comportamenti opzionali o che si verificano solo in determinate circostanze.

Analisi di robustezza: consiste nellanalisi del testo di uno use case, nellidentificazione di un primo insieme di
oggetti che vi prenderanno parte e nella classificazione di tali oggetti in base alle loro caratteristiche. E in diretta relazione con i diagrammi di interazione: diagramma di sequenza, diagramma di comunicazione. Parte integrante dellanalisi di robustezza la definizione delle Classi di Analisi, che costituiscono il nucleo del modello di analisi. Esistono tre tipi di classi di analisi: classi di confine, classi entit, classi di controllo. - Un oggetto confine un elemento con il quale interagisce un attore in uno use cases. - Un oggetto identit contiene informazioni persistenti (es. dati memorizzati in un database). - Un oggetto controllo viene utilizzato per rappresentare concetti come il coordinamento e la sequenza di eventi oppure interazioni che coinvolgono pi oggetti entit in presenza di segnali provenienti da oggetti confine. Esempio LUtente clicca sul pulsante Login nella Home Page. Il sistema visualizza la pagina di accesso al sistema. Lutente digita il suo codice identificativo e la sua password, poi clicca OK. Il sistema convalida i dati inseriti dallutente confrontandoli con quelli presenti nel Profilo Utente, e in caso positivo fa tornare lutente alla Home Page.

- Diagrammi di Interazione: sono ideali per modellare levoluzione di un singolo use case. -

Diagramma di comunicazione: si focalizza sulle relazioni

statiche fra oggetti e sullinvio dinamico di messaggi fra oggetti. Riprende i concetti di base dellanalisi di robustezza, con in pi lindicazione dellordine temporale con cui avviene lo scambio di messaggi.

Diagramma di sequenza: presenta unorganizzazione pi rigida e si focalizza sulla sequenza temporale delle interazioni fra gli oggetti.

- Diagramma di sequenza: si focalizza sullordinamento temporale dei messaggi che vengono scambiati fra gli oggetti. Messaggio: si definisce messaggio una comunicazione fra due oggetti che d origine ad una attivit. Unattivit implica una o pi azioni. Azioni: consistono in istruzioni eseguibili aventi come risultato il cambiamento di valore di uno o pi valori di ritorno alloggetto che ha inviato il messaggio. Esistono 5 tipi di azioni: Azione di chiamata: consiste nellinvocazione di un metodo di un oggetto. Un oggetto pu eseguire unazione di chiamata su altri oggetti, ma anche su se stesso. - Azione di risposta: consiste nella restituzione di un valore in risposta ad unazione di chiamata. Il meccanismo di chiamata e risposta sincrono. Nei diagrammi di sequenza, non deve obbligatoriamente esserci corrispondenza 1-1 fra chiamata e risposta: se la risposta deducibile dal contesto, si possono anche indicare azioni di chiamata senza le relative azioni di risposta. - Azione di creazione: crea un oggetto, ossia unistanza di una classe. - Azione di distruzione: distrugge un oggetto.

- Azione di invio: invia un segnale ad un oggetto. Un segnale un elemento di comunicazione asincrona fra oggetti.

- Diagrammi degli Stati: rappresenta la macchina a stati di un oggetto. Rappresenta un costrutto ideale per la modellazione di un oggetto che presenta queste caratteristiche: ammette un numero limitato di valori, ha delle restrizioni sulle transazioni fra questi valori. Eventi: un evento un qualcosa che accade ed ha rilevanza per un oggetto. UML supporta la rappresentazione di 4 tipi di eventi: - Segnale: comunicazione asincrona fra oggetti. - Evento di chiamata: comunicazione sincrona durante la quale un oggetto invoca un metodo di un altro oggetto, oppure un proprio metodo. - Evento temporale: avviene dopo un periodo di tempo specificato. - Evento di cambiamento: avviene quando verificata una particolare condizione. Stati, Transizioni,Azioni Stato: condizione nella quale un oggetto, durante il suo ciclo di vita, pu trovarsi per un periodo di tempo finito. Stato iniziale, stato finale Transizione: passaggio di un oggetto da uno stato ad un altro. Pu avvenire in corrispondenza di un evento oppure incondizionatamente. Azione di entrata: eseguita da un oggetto subito dopo essere passato in uno stato. Azione di uscita: eseguita da un oggetto subito prima di uscire da uno stato. Stati compositi: sono stati che contengono altri stati, detti sottostati. Sottostati sequenziali: oggetto che in un determinato - Sottostati concorrenti: oggetto che in un momento pu trovarsi solo in uno dei sottostati di determinato momento pu trovarsi in pi sottostati uno stato composito. di uno stato composito.

History states: interruzione del flusso interno di uno stato composito,con successivo recupero nel punto in cui stato interrotto.

Diagrammi di attivit: rappresentano unestensione dei normali

flowchart: la differenza fondamentale che permettono di rappresentare processi paralleli. Le aggiunte rispetto ai flowchart sono: Fork: processo con un flusso in entrata e pi flussi in uscita. I flussi in uscita vengono eseguiti in modo concorrente, dunque i fork permettono di rappresentare elaborazioni parallele. Join: processo con pi flussi in entrata e un flusso in uscita. I join sono elementi di sincronizzazione, che permettono lavanzamento solo quando tutti i flussi in entrata sono terminati. Merge: processo con pi flussi in entrata e un flusso in uscita, che rappresenta il termine di un processo condizionale iniziato con un diamond di decisione.

Design Pattern:

costituiscono soluzioni sperimentate a problemi ricorrenti, utilizzabili in contesti applicativi differenti. I pattern costituiscono un bagaglio pubblicamente disponibile di esperienza e di soluzioni, a cui il progettista pu attingere nel momento in cui si trova di fronte a problemi che non ha mai affrontato, o per i quali ritiene sia utile confrontarsi con punti di vista diversi dal proprio.

Struttura dei pattern

Un design pattern identifica gli aspetti fondamentali di una struttura progettuale utile per creare codice objectoriented realmente riusabile. Il pattern comprende: le classi che partecipano alla soluzione, le loro responsabilit, le loro relazioni, le loro istanziazioni. In generale un pattern ha 4 elementi essenziali: - Pattern name: un nome univoco per identificare un problema ricorrente e la sua soluzione. - Problem: descrive il problema ed il contesto nel quale si presenta; in altri termini descrive quando applicare il pattern. - Solution: descrive gli elementi che compongono limplementazione del pattern, le loro relazioni, responsabilit e collaborazioni. Fornisce una descrizione astratta di un problema di progettazione e come sia possibile risolverlo. - Consequences: descrive risultati, costi e benefici dellapplicazione del pattern.

Catalogazione dei pattern

Linsieme di tutti i design pattern conosciuti denominato Pattern Catalog. I pattern del catalogo sono suddivisi in: - Pattern Creazionali: si focalizzano sul processo di creazione di oggetti (Es. Singleton, Factory, Builder). - Pattern Strutturali: si focalizzano sulla composizione di una gerarchia di classi, allo scopo di soddisfare particolari condizioni (Es. Bridge, Proxy). - Pattern Comportamentali: si focalizzano sulle azioni compiute dalle classi e sullattribuzione di responsabilit fra di esse (Es. Iterator, Observer, Visitor).

Rappresentazione dei pattern

Esistono molti modi per documentare un pattern. La forma pi diffusa la rappresentazione che segue: - Nome: scelto in modo evocativo. - Categoria: pattern creazionale, strutturale o comportamentale. - Scopo: breve descrizione dellobbiettivo del pattern. - Motivazione: descrizione del problema reale al quale il pattern offre soluzione. - Applicabilit: casi in cui possibile applicare il pattern, vincoli che ne impediscono lapplicazione. - Struttura: diagramma delle classi della soluzione. - Partecipanti: il ruolo di ogni classe. - Esempio: implementazione di un esempio. - Conseguenze: vantaggi e svantaggi dellapplicazione del pattern. - Usi conosciuti: casi reali di applicazione del pattern.

Singleton (pattern creazionale)

Scopo: garantire che una classe dellapplicazione abbia una ed una sola istanza. Partecipanti: Singleton provvede autonomamente al controllo che esista una sola istanza. Definisce un metodo Istance() attraverso il quale viene fornito laccesso allunica istanza esistente della classe. Implementa le operazioni della classe.

Factory Method (pattern creazionale)

Scopo: definire uninterfaccia univoca per la creazione di oggetti, lasciando alle classi derivate il compito di creare gli oggetti stessi. Partecipanti - Product: classe astratta, base degli oggetti creati mediante factory method. - ConcreteProduct: gli oggetti che vengono effettivamente creati mediante factory method. - Creator: classe astratta, dichiara il metodo. - ConcreteCreator: classe concreta, derivata da Creator,che implementa il metodo factory.

Il metodo Factory ritorna una specifica istanza di un ConcreteProduct.

Proxy (pattern strutturale)

Scopo: fornire un surrogato o placeholder ad un oggetto, al fine di controllarne laccesso. Partecipanti Subject: definisce linterfaccia comune sia per il proxy, che per loggetto che dovrebbe essere realmente il destinatario delle varie richieste. Real subject: loggetto rappresentato, e, se si vuole, nascosto dal proxy. Proxy: implementa linterfaccia definita da Subject, implementata anche dal Soggetto Reale, e mette a disposizione un accesso controllato al Real Subject.

Observer (pattern comportamentale)

Scopo: il pattern Observer permette di definire una relazione di dipendenza uno-a-molti fra gli oggetti dellapplicazione, in modo tale che quando un oggetto cambia stato, tutti gli oggetti che dipendono da esso vengono automaticamente aggiornati. I partecipanti sono: - Il soggetto, che rappresenta i dati, su cui si basano. - Le viste, che si mantengono sincronizzate coi dati e che presentano, una rappresentazione dei dati. Il soggetto si mantiene una lista di tutte le viste che lo osservano e, quando lo riterr opportuno, notificher i vari osservatori di questo fatto. Questi ultimi potranno interrogare il soggetto e ricavarne informazioni sufficienti per aggiornarsi e rimanere cos consistenti coi dati.

Visitor (pattern comportamentale)

Scopo: implementare nuove operazioni su una gerarchia di classi senza modificare le classi stesse. Partecipanti - Visitor: classe astratta che dichiara un metodo di visita a tutte le classi della gerarchia. - Concrete Visitor: classi concrete derivate da Visitor al fine di implementare i metodi di visita. Ogni classe identifica unoperazione da compiere sulle classi della gerarchia, e implementa un metodo per compiere tale operazione. - Element: classe astratta alla base della gerarchia di classi non modificabili. Dichiara il metodo di accettazione. - Concrete Element: classi concrete della gerarchia di classi non modificabili. Implementano i metodi di accettazione. - Object Structure: costrutto che gestisce una lista di Concrete Elements. Pu essere una classe apposita, ma la gestione di della lista pu anche essere in una funzione esterna o nel main.

La progettazione del software comprende:

ingegneria dei sistemi informatici: insieme di elementi organizzati in modo da raggiungere uno scopo prefissato mediante lelaborazione di dati. Gli elementi che concorrono alla realizzazione di un sistema informatico sono: software, hardware, basi di dati, utenti, procedure, documentazione. ingegneria dei requisiti: prende in esame i meccanismi che sottendono: la comprensione dei desideri dellutente, lanalisi delle reali necessit del cliente, la negoziazione di una soluzione ragionevole, la specifica non ambigua di una soluzione, la modellazione del sistema, la validazione dei requisiti da parte del cliente, la gestione dellevoluzione dei requisiti. principi e tecniche di progettazione.

Ingegneria dei requisiti

Analisi dei requisiti: fornisce al progettista software una rappresentazione delle informazioni, delle funzionalit e dei comportamenti che possono essere tradotti nei progetti dei dati dellarchitettura, delle interfacce e dei componenti. Normalmente i requisiti vengono individuati dagli analisti conducendo una serie di interviste mirate agli interessati. La difficolt dellindividuazione dei requisiti sono principalmente dovute a: problemi di comprensione, problemi di portata, problemi di volatilit. Esistono tecniche pi incisive per lindividuazione dei requisiti: FAST: promuove la creazione di un team congiunto di sviluppatori e committenti, che attraverso una serie di incontri collaborano allindividuazione dei requisiti. La tecnica FAST prevede: Una riunione preliminare nella quale i rappresentanti dellazienda committente e dellazienda sviluppatrice definiscono lambito del problema, una sua soluzione generale, e nominano un moderatore per i successivi incontri. Prima della riunione successiva, ogni partecipante stila una lista di servizi, vincoli e criteri prestazionali che la soluzione dovr soddisfare, secondo la propria ottica. Alla riunione successiva, il moderatore crea un elenco combinato mettendo insieme le liste dei partecipanti ed eliminando le voci duplicate. Lelenco combinato viene discusso, e si ripetono i passi precedenti fino al raggiungimento del consenso unanime sullelenco dei requisiti. Il team viene suddiviso in gruppi di lavoro che si concentrano su particolari sottoinsiemi dellelenco, al fine di formalizzare i requisiti in modo pi completo. Il lavoro dei vari gruppi viene messo insieme dal moderatore, che compila il documento completo di specifica dei requisiti. Le specifiche complete vengono discusse dallintero team, fino al raggiungimento del consenso unanime. Il team definisce i criteri di validazione dei requisiti. JAD: variante della tecnica FAST ma che pone maggiormente laccento sui ruoli assunti dai vari attori nellambito della definizione dei requisiti: Project sponsor: responsabile del progetto per il cliente. Project leader: responsabile del progetto per lo sviluppatore. Record keeper: responsabile dei verbali delle riunioni e della redazione dei documenti di progetto. Time keeper: responsabile della puntualit delle riunioni. Business Users: gruppo di utenti del sistema. Analyst: gruppo di analisti e sviluppatori. QFD: pone laccento sulla comprensione degli aspetti realmente importanti per il cliente, e sulla valorizzazione di questi aspetti nel corso della progettazione del software, al fine di massimizzare la soddisfazione del cliente stesso. QFD suddivide i requisiti in: Normali: esplicitati dal committente mediante normali interviste e incontri con il team di progetto. Attesi: sono requisiti impliciti, cos fondamentali che il cliente spesso li d per scontati e non li richiede esplicitamente. Straordinari: requisiti che superano le aspettative del cliente (e che spesso non vengono richiesti esplicitamente).

I principi di analisi: lanalisi dei requisiti deve essere articolata secondo i seguenti principi operativi: Analisi del dominio delle informazioni: definire le tipologie, gli attributi, le relazioni dei dati. Analisi delle funzionalit: identificare le funzioni che operano sui dati, indicare il flusso dei dati attraverso il sistema, identificare produttori e consumatori di dati. Analisi del comportamento: identificare i diversi stati del sistema, specificare gli eventi che causano le transizioni fra gli stati.

Specifica dei requisiti Il prodotto finale delle attivit di individuazione e analisi dei requisiti il documento di specifica dei requisiti che formalizza e descrive dettagliatamente: le informazioni gestite dallapplicazione, le funzionalit dellapplicazione, le modalit di interazione con lapplicazione, le prestazioni attese, i vincoli del sistema, i criteri di validazione dei requisiti. Lo standard internazionale per la stesura del documento di specifica dei requisiti lo IEEE std 830-1998 (SRS) Secondo la norma, una buona SRS deve essere: - Corretta: ogni requisito espresso nel documento rappresenta un requisito che il software deve soddisfare. - Non ambigua: ogni requisito espresso nella SRS ha una sola possibile interpretazione. - Completa: la SRS deve contenere la definizione di tutte le funzionalit, gli attributi, i vincoli, le interazioni del sistema, la risposta del sistema a tutte le possibili classi di dato in ingresso. - Consistente: i requisiti non devono essere in conflitto tra loro. - Classificata: i requisiti sono accompagnati da indicatori di importanza e priorit temporale. - Verificabile: ogni requisito deve essere accompagnato da criteri di validazione oggettivi. - Modificabile: La SRS deve essere strutturata in modo da seguire levoluzione dei requisiti nel tempo. - Tracciabile: la SRS deve presentare un indice delle revisioni.

La progettazione del software: la rappresentazione ingegneristica dellapplicazione che deve essere realizzata, a
partire dai requisiti del cliente e nel pieno soddisfacimento dei requisiti di qualit. Si concentra su quattro aree: dati, architettura, interfacce, componenti. Il prodotto finale della fase di progettazione il documento di specifiche di progetto (IEEE std 1016-1998, SDD) che formalizza e descrive dettagliatamente: le funzioni, larchitettura, le interfacce, i componenti, gli stati e le transizioni, lorganizzazione dei dati, gli algoritmi di processo dei dati del sistema. Modellazione: la progettazione del software si fonda su unintensa attivit di modellazione. Per progetti sviluppati con tecnologie ad oggetti lo standard lUML; esistono tuttavia altre tipologie di diagrammi, utilizzabili anche in progetti condotti con metodologie tradizionali: - ERD diagramma entit-relazioni - DFD diagramma di flusso di dati - STD diagramma stati-transizioni Linsieme dei tre diagrammi comunemente denominato Modello Concettuale.

Architettura del software: si riferisce alla struttura complessiva del sistema e ai modi con cui tale struttura sorregge
lintegrit concettuale del sistema stesso. La progettazione dellarchitettura riguarda la struttura gerarchica dei componenti di un programma, la modalit con cui tali comportamenti interagiscono, la struttura dei dati manipolati.

Stili di architettura software

Call and return: molto spesso nei programmi che comunemente utilizziamo c un modulo principale che richiama alcuni moduli, che a loro volta richiamano altri moduli, prima di ritornare il controllo al modulo principale. Questa architettura pu essere rappresentata tramite un diagramma ad albero. Data-centered A flusso di dati

A livelli

Il paradigma MVC: uno stile di architettura molto comune, soprattutto quando si ha a che fare con programmi che hanno un certo grado di interazione con lutente. Si presta molto bene alla progettazione di programmi dotati di interfaccia grafica. Pu essere considerato un caso particolare di architettura a livelli. E fondato sullidea di separare tra loro alcune funzionalit fondamentali di unapplicazione, suddividendone gli elementi in tre categorie: - Gli oggetti Modello: contengono un modello del funzionamento, solo la base della conoscenza, sono i depositari del modo di lavorare. Raramente hanno una rappresentazione visibile. Sono oggetti molto importanti, costituiscono il nucleo dellapplicazione. - Gli oggetti Vista: rappresentano qualcosa direttamente visibile su uno schermo e in generale rappresentano un modo per esporre e rendere disponibile qualcosa. Un oggetto Vista rappresenta dei dati e modalit di interazione. - Gli oggetti Controllore: si trovano a met strada tra gli oggetti Vista e gli oggetti Modello. Se gli oggetti Vista sono solo la Forma e gli oggetti Modello sono pura sostanza, chi si preoccupa di mediare tra questi due estremi sono gli oggetti Controllore.

Concetti di progettazione
Modularit: Suddivisione del software in elementi distinti, etichettati e indirizzabili, combinati al fine di soddisfare i requisiti del problema. I singoli elementi sono detti moduli. La modularit fornisce enormi vantaggi in termini di gestione della complessit.

Indipendenza funzionale: si raggiunge sviluppando moduli dedicati ad una sola funzione ed evitando eccessive interazioni fra i moduli. Rappresenta un obbiettivo di progettazione del software che mira alla creazione di moduli tali che: ogni modulo di riferisce ad una determinata sottofunzione dei requisiti; ogni modulo una uninterfaccia semplice e ben definita verso gli altri elementi del programma. Encapsulation e Information Hiding sono assiomi che favoriscono lindipendenza funzionale dei moduli di un programma ad oggetti. Lindipendenza funzionale ottenuta dalla combinazione di due diversi aspetti: - Coesione: un modulo coeso se esegue un singolo compito allinterno del sistema, espone uninterfaccia limitata agli altri moduli, ha poche interazioni con procedure eseguite da altre parti del programma. - Accoppiamento: una misura dellinterconnessione dei moduli di unapplicazione. Dipende dalla complessit dellinterfaccia dei moduli, e dalla quantit di dati e procedure visibili trasversalmente nellapplicazione.

Il collaudo del software

Obbiettivo del collaudo software scoprire gli errori nellapplicazione. Si tratta di una attivit complessa che investe aspetti tecnici, organizzativi e psicologici. Utilizzando metodologie di testing allo stato dellarte, strumenti di test avanzati, procedure e misurazioni sottoposte a rigorosi processi di certificazione, possibile ridurre significativamente il costo sostenuto dai produttori di software a causa di errori nel software.

Terminologia: la terminologia adottata relativamente al collaudo del software prevede le seguenti definizioni:
Verifica: insieme delle attivit volte a stabilire se il programma costruito soddisfa le specifiche. Testing: particolare tipo di verifica fatta mediante esecuzione del programma, selezionando alcuni dati di ingresso e valutando i relativi risultati. Il testing permette di individuare la presenza di errori nel programma, ma non la loro localizzazione allinterno del codice. Test case: singola unit di testing, volta a verificare un sottoinsieme di risultati a fronte di un sottoinsieme di dati in ingresso. Convalida: processo che permette di stabilire che le specifiche funzionali sono corrette, ossia descrivono i veri requisiti dellutente. Debugging: processo che permette di localizzare e correggere gli errori nel codice. Programmazione difensiva: insieme di tecniche di programmazione che aumentano probabilit di correttezza e facilitano verifica e debugging.

La catena degli errori

Malfunzionamento: il comportamento del sw diverso da quello atteso. Difetto: frammento di codice scorretto rispetto alle sue specifiche. Errore: errata interpretazione delle specifiche durante la codifica.

Tecniche di collaudo del software - White-box: fondato su test cases che esercitano determinati cammini logici allinterno del programma. Per
cammino logico si intende una determinata sequenza di scelte logiche o procedurali nel corso del flusso del programma. I diversi metodi di collaudo white-box permettono la costruzione di test cases che si focalizzano su aspetti diversi: Collaudo per copertura delle istruzioni: test set tale che ogni istruzione sia eseguita almeno una volta. Collaudo per copertura dei rami: test set tale che ogni ramo del flusso di controllo sia attraversato almeno una volta. Collaudo per copertura delle condizioni: test set tale che ogni condizione semplice assuma almeno una volta il valore vero e il valore falso e ogni componente di una condizione composta assuma almeno una volta il valore vero e il valore falso. Collaudo per copertura dei cammini di base: una tecnica di collaudo mediante la quale possibile: calcolare una misura complessiva della complessit logica di un programma, ricavare da tale misura indicazioni per la scelta di un insieme di cammini di esecuzione, realizzare dei test cases per linsieme di cammini in modo da garantire che ogni istruzione del programma sia eseguita almeno una volta. Si basa sul grafo di flusso del programma, che rappresenta il flusso logico di controllo del programma. Il grafo di flusso composto da: Nodi: raggruppano una sequenza di blocchi flowchart. Lati: connettono i nodi del grafo. Regioni: aree racchiuse da un insieme di lati. Il nodo da cui parte il flusso detto Nodo Iniziale. Il nodo in cui termina detto in Nodo Finale. Un nodo da cui partono due lati detto Nodo Predicato. Complessit ciclomatica= 4

Si definisce Cammino una sequenza di nodi del grafo di flusso che permette di attraversare lintero grafo dal nodo iniziale al nodo finale. Un cammino detto indipendente se attraversa almeno un lato non ancora percorso da altri cammini. Il grafo dellesempio presenta i seguenti cammini indipendenti: Cammino 1: 1 - 11 Cammino 2: 1 - 2,3 - 4,5 - 10 - 1- 11 Cammino 3: 1 - 2,3 - 6 - 7 - 9 - 10 - 1 - 11 Cammino 4: 1 - 2,3 - 6 - 8 - 9 - 10 - 1 - 11 Si definisce Complessit Ciclomatica di un programma la misura della complessit logica di un programma. E indicata con V(G). Nellambito dei cammini di base, corrisponde al numero massimo di cammini indipendenti che possibile individuare nel grafo di flusso. La complessit ciclomatica pu essere calcolata in pi modi: V(G)= NR (numero di regioni) V(G)= E - N + 2 (E=numero di lati, N=numero di nodi) V(G)= P + 1 (P=numero di nodi predicato) Il collaudo per cammini di base prevede la preparazione di 4 test cases per avere la certezza che ogni istruzione del programma sia eseguita almeno una volta. Va detto per che normalmente i cammini indipendenti hanno un peso diverso allinterno del programma. Per costruire dei test cases pesati, utile ricorrere ad una rappresentazione tabellare del grafo di flusso, detta Matrice del grafo di Flusso. Ogni 1 in tabella rappresenta un lato del grafo. In questo modo ogni lato ha peso 1; assegnando pesi diversi ai lati possibile costruire dei test cases pesati.

Copertura: le tecniche di collaudo white-box si basano sul concetto di copertura: dove Nc il numero di elementi coperti, Ntot il numero totale di elementi. -

Black-box: le metodologie di collaudo black-box derivano i test cases dalle specifiche. Lobbiettivo costruire
insiemi di condizioni di ingresso che esercitino completamente tutti i requisiti funzionali del programma. Mediante il collaudo black-box, si verificano i dati di output a fronte di determinati input di programma, dunque si tratta di una metodologia adatta per rilevare: funzionalit errate o mancanti, errori di interfaccia utente, errori nellaccesso a dati esterni, limiti prestazionali, crash di sistema.

Il dominio di input: linsieme di tutti i possibili valori assunti dai dati di ingresso dellapplicazione.
Equivalence partitioning La Suddivisione in classi di equivalenza un metodo di collaudo black-box che suddivide il dominio di input in base a criteri di equivalenza. I Sottodomini sono classi di equivalenza dove lequivalenza definita empiricamente. In base al Principio della copertura completa, linsieme dei test cases deve essere composto in modo da contenere almeno un elemento per ciascun dominio.

Boundary value analysis: lanalisi dei valori limite una tecnica complementare alla suddivisione in classi di
equivalenza. Lanalisi dei valori limite prevede la selezione dei casi di prova ai confini della classe, cio selezionando i valori limite della classe. Le linee guida BVA prevedono: - Se una condizione di ingresso specifica un intervallo di valori delimitato da a e b, necessario costruire dei test cases per i valori di input a e b. - Se una condizione di ingresso specifica un set di valori, necessario costruire dei test cases per i valori minimo e massimo. - Se lapplicazione presenta strutture dati con dimensione predefinita, necessario costruire dei test cases che esercitino le strutture dati ai valori limite. Collaudo ad array ortogonale: una tecnica di testing a base statistica, volta a verificare le interazioni fra i parametri di input. Un array si dice ortogonale se, prese due colonne qualsiasi, tutte le possibili combinazioni dei parametri si presentano una ed una sola volta.

Strategie di collaudo del software: rappresenta un insieme di attivit che comprende: pianificazione, allestimento
dellambiente del test, progettazione dei test cases, esecuzione dei test cases, raccolta e valutazione dei risultati. E possibile individuare elementi comuni ad ogni strategia di collaudo: - Il collaudo inizia a livello di singolo componente e prosegue verso lesterno fino a comprendere lintegrazione dellintera applicazione. - E opportuno adottare diverse tecniche di collaudo. - Il collaudo deve essere condotto dagli stessi sviluppatori e da un gruppo indipendente (software testers). - Il collaudo deve includere prove a basso livello e prove di interfaccia ad alto livello. - Lo stato di avanzamento dei collaudi deve essere misurabile e prevedere una serie di milestones da presentare alla direzione.

Il team di collaudo
Gli sviluppatori: sono coloro che meglio conoscono i moduli da loro realizzati, spesso hanno poca visione dinsieme dellintera applicazione, spesso sono (inconsciamente) portati a difendere il proprio operato cio tendono a realizzare test cases che dimostrano che il programma funziona. I software testers (SQA): hanno visione dellintera applicazione, quindi con facilit realizzano prove che coinvolgono lintero applicativo, hanno difficolt a comprendere i dettagli interni di un modulo, quindi spesso devono rivolgersi agli sviluppatori, hanno la missione di demolire il prodotto, individuando quanti pi errori possibile.

Lambiente di test: lesecuzione dei test richiede lallestimento di un particolare ambiente detto Scaffolding.
AUT: lapplicazione da testare. Pu essere il programma completo, oppure un suo sottoprogramma. Driver: programma esterno che utilizza lapplicazione da testare. Stub: eventuali moduli esterni richiamati dallapplicazione da testare. Oracolo: programma esterno in grado di controllare la corrispondenza fra il risultato prodotto dalla AUT e dei risultati di riferimento.

Problemi dello scaffolding - Il costo per la creazione dellambiente di test non trascurabile. - La differenza fra AUT e programma effettivamente commercializzato non permette di individuare alcune categorie di errori. - Non sempre le applicazioni producono risultati facilmente osservabili. - Gli oracoli sono strumenti sofisticati e fragili. - Volatilit dei test cases in seguito a modifiche introdotte nella AUT.

La documentazione di test: si tratta di uno o pi documenti nei quali si descrivono dettagliatamente: le persone
coinvolte nelle attivit di collaudo e validazione, le modalit e le tecniche utilizzate, gli ambienti di test, gli strumenti, le procedure da mettere in atto in caso di individuazione di malfunzionamenti, le fasi del collaudo. Lo standard internazionale per la stesura di piani di test lo IEEE Std 730-1998.

Unit test: si concentra sulla verifica della pi piccola unit di progettazione software (es. componente,modulo,classe).
E basato principalmente su tecniche white-box. Il collaudo per cammini di base ha ampia applicazione nello unit test; vista lelevata complessit ciclomatica delle applicazioni, necessario limitarsi ad una bassa copertura. Il collaudo per condizioni, per flusso di dati e per cicli permette di individuare particolari categorie di errori. Nello unit test vengono applicate anche tecniche black-box. Il collaudo di unit unattivit molto onerosa. Tuttavia: Nellambito di un progetto complesso, il collaudo di pi moduli pu essere condotto in contemporanea. Se la unit una classe fortemente coesa, cio con poche interconnessioni con altri moduli, la realizzazione di driver e stub molto semplice.

Integration Test
Il collaudo di integrazione una tecnica sistematica per la costruzione della struttura di un programma conducendo allo stesso tempo prove tese a rilevare errori relativi allinterfacciamento e allinterconnessione fra i moduli. Le tecniche di integrazione incrementale permettono di costruire il programma assemblando piccolo sottosistemi che vengono fatti crescere fino a costruire lintera applicazione. Integrazione Top-Down: una tecnica di integrazione incrementale che partendo dal main, prevede la graduale sostituzione degli stubs con moduli reali, procedendo dal modulo principale verso i moduli foglia. Ad ogni sostituzione necessario rieseguire parte dei test effettuati in precedenza. Vantaggi: il fatto di arrivare fino ai moduli foglia permette di testare un sottoinsieme di funzionalit reali dellapplicazione. E possibile avere risultati tangibili in tempi relativamente rapidi. Svantaggi: ci sono molti moduli fittizi quindi difficile progettare test cases significativi. Se i moduli dei livelli pi alti dipendono da elaborazioni effettuate nei livelli pi bassi, i primi step di integrazione non producono risultati significativi. Integrazione Bottom-Up: tecnica di integrazione incrementale, complementare alla precedente. I componenti di basso livello vengono aggregati in cluster che realizzano una particolare sottofunzione. I drivers vengono via via sostituiti con moduli reali, fino ad arrivare al modulo principale. Vantaggi: facile costruire test cases significativi allinterno dei cluster. Se i cluster sono fortemente coesi, laggiunta di nuovi moduli driver ha poche probabilit di causare errori a livello pi basso. Svantaggi: i primi risultati tangibili arrivano pi tardi rispetto allintegrazione Top-Down, perch il tempo necessario per creare un cluster pu essere lungo. Integrazione Sandwich: tecnica di integrazione incrementale mista che prevede lutilizzo del metodo TopDown per i livelli pi alti dellintegrazione, e Bottom-Up per i livelli pi bassi. Smoke Testing: tecnica di integrazione big-bang utile per realizzare prodotti sw in breve tempo. In ogni fase del processo di sviluppo, tutte le parti del programma realizzate fino a quel punto vengono messe insieme in un programma che viene testato costantemente. Vantaggi: si riducono i rischi derivanti dallintegrazione fra moduli. Eventuali errori di progettazione dellarchitettura vengono individuati molto presto. La rispondenza del programma alle specifiche funzionali pu essere verificata fin dalle prime fasi. Svantaggi: difficile localizzazione degli errori.

Validation test: dopo il collaudo di integrazione, il software viene assemblato in un pacchetto unitario. La fase
successiva il collaudo di validazione, durante il quale laccento viene posto sulladerenza dellapplicazione ai requisiti. Si tratta di una fase molto lunga al termine della quale lesito positivo certifica laccettazione del prodotto software da parte del committente. Il collaudo di validazione viene condotto con metodologie black-box. La validazione viene effettuata da gruppi misti che coinvolgono la software house e lutente finale. Per prodotti complessi, si divide in due fasi ben distinte: Alfa test: condotto presso la software house, vede coinvolti i software testers con la collaborazione degli sviluppatori. Beta test: condotto presso un insieme selezionato di clienti con il supporto dei software testers.

System test: in generale il sw commissionato al produttore deve interagire con elementi esterni preesistenti.
Lapplicazione che ha superato i test di accettazione deve essere messa alla prova nellambito dellintero sistema informatico. Deve essere eseguito il collaudo di sistema. Recovery testing: verifica la tolleranza del sistema a malfunzionamenti generati dallapplicazione. Security testing: verifica i meccanismi di sicurezza che impediscono laccesso a dati sensibili o a procedure riservate a determinati utenti. Prove di stress: verifica la rispondenza del sistema a particolari condizioni di carico dellapplicazione.

Il debugging: in tutte le fasi del collaudo viene rilevata una notevole mole di malfunzionamenti, che devono essere
esaminati e corretti dagli sviluppatori con lattivit di debugging. Il processo di debugging prevede: analisi del malfunzionamento, identificazione delle cause, classificazione dellerrore, stima del tempo necessario per la correzione, correzione, creazione di nuovi test case.

Metriche del software

Definizione: Misura quantitativa delle caratteristiche dei prodotti software e dei processi di sviluppo.

La pi antica metrica del software

LOC (linee di codice): l'indicatore che viene utilizzato per misurare le dimensioni di un programma dato dal numero delle sue linee di codice. Utilizzato anche per derivare indicazioni empiriche su numero di errori presenti e il tempo necessario per il suo sviluppo. Indicatore abbastanza criticabile in quanto non misura la dimensione dei dati. Il numero di linee di codice deve essere integrato da altre informazioni per giungere ad una buona valutazione delle qualit del software.

Procedura di misurazione si articola in 5 attivit:

Formulazione: derivazione di misure e metriche appropriate alla rappresentazione del software in esame. Raccolta: meccanismo in base al quale si accumulano i dati dai quali ricavare metriche. Analisi: calcolo delle metriche sui dati raccolti, con applicazione di strumenti matematici. Interpretazione: valutazione dei risultati, allo scopo di trarre indicatori sulla qualit del software in esame. Feedback: indicazioni per lo sviluppo, ricavate dallinterpretazione delle metriche.

I principi della misurazione

Gli obiettivi della misurazione devono essere fissati prima di cominciare la raccolta dei dati. Ogni metrica del software deve essere definita in modo non ambiguo. Le metriche devono essere stabilite sulla base di una teoria valida per il dominio applicativo. Le metriche devono essere adattate ai prodotti ed ai processi specifici. Ove possibile, raccolta ed analisi dei dati devono essere automatizzate, al fine di ridurre gli errori umani nella misurazione. Nellinterpretazione delle misure, mettere in relazione attributi interni del software e fattori di qualit esterni solo sulla base di principi certi e dimostrabili. Per ogni metrica, stabilire principi e linee guida per linterpretazione.

Attributi delle metriche efficaci per il software (IEEE Std 1061-1998)

Per essere efficace, una metrica del software deve essere: Semplice e calcolabile: il suo calcolo non deve essere troppo complicato o richiedere troppo tempo/potenza di calcolo. Empiricamente e intuitivamente persuasiva: la metrica deve riflettere le nozioni intuitive sullattributo in esame. Coerente ed oggettiva: deve fornire risultati non ambigui e ripetibili, deve essere coerente nelluso delle unit di misura e delle dimensioni.

Indipendente dal linguaggio di programmazione: le metriche si devono fondare su analisi, progettazione e struttura del programma, non sul linguaggio di programmazione utilizzato. Facilmente intellegibile: deve fornire al tecnico informazioni utili a migliorare la qualit del software.

Tipologie di metriche per il software

Metriche di processo e di progetto o SSPI (statistical sw process improvement) o Metriche per le specifiche o Metriche per il modello progettuale Metriche di prodotto o Dimensionali o Function Points o FP Estese o Metriche bang Metriche per sistemi orientati agli oggetti o Metriche CK o Metriche do Lorenz-Kidd o MOOD o Metriche di blinder Metriche per il collaudo o Complessit ciclomatica o Misure di Halstead Metriche per la manutenzione o Misure di affidabilit o Software Maturity Index

Metriche Dimensionali
Le metriche dimensionali si ottengono normalizzando le misure di qualit e produttivit sulla base delle dimensioni del software prodotto, espresse in LOC.

Metriche Function Points

Adottano come fattore normalizzante il numero di funzionalit fornite dallapplicazione, espresse in punti funzione. I punti funzione si ricavano tramite una relazione empirica fondata su misure dirette sul dominio dei dati e su stime della complessit del software in esame. Il calcolo FP si articola in tre passi: Conteggio dei parametri di misurazione: o Numero di input utente (I): si conta ogni valore immesso dallutente che fornisce dati applicativi. o Numero di output utente (O): si conta ogni valore generato dal programma che fornisce dati applicativi. o Numero di interrogazioni utente (Q): si conta ogni input in linea che causa una scelta allinterno del programma. o Numero di file (F): si contano i file esterni (o le tabelle di database)che costituiscono un raggruppamento logico di dati. o Numero di interfacce esterne (E): si conta il numero di file di interscambio dati (o tabelle di database) che permettono di trasmettere informazioni ad un altro sistema. - Applicazione dei fattori di peso: Applicazione di criteri (soggettivi ed empirici) per determinare se un certo parametro di misurazione semplice, medio o complesso. La somma dei parametri di misurazione moltiplicata per i fattori di peso determina il Count Total (CT). - Applicazione del fattore di aggiustamento della complessit (VAF): il calcolo del VAF viene effettuato sulla base delle risposte a 14 domande relative alle caratteristiche del sistema in esame: comunicazione dati, distribuzione dell' elaborazione, prestazioni, utilizzo estensivo della configurazione, frequenza delle transazioni, inserimento dati interattivo, efficienza per l' utente finale, aggiornamento interattivo, complessit elaborativa, riusabilit, facilit d' installazione, facilit di gestione operativa, molteplicit di siti, facilit di modifica. Ad ogni caratteristica possibile assegnare una valutazione della sua influenza sull'applicazione su di una scala di valori 0-5: Il grado di influenza (TDI) la somma dei punteggi interi da 0 0: Non presente, o di nessuna influenza a 5 attribuiti alle 14 caratteristiche. 1: Influenza secondaria Il fattore di aggiustamento della complessit dato da: 2: Influenza moderata VAF = 0.65 + 0.01 * TDI 3: Influenza media Da cui si ottiene il calcolo dei Function Points: 4: Influenza significativa FP = CT * VAF 5: Influenza forte generalizzata Le metriche FP sono molto pi accurate rispetto alle metriche dimensionali basate su LOC. Le metriche FP sono in genere inadatte ai sistemi con elevato grado di complessit algoritmica, ai sistemi real time in quanto la loro focalizzazione molto spostata sui dati del sistema.

Metriche FP Estese
- 3D Function Points: il calcolo analogo a FP, ma oltre ai 5 parametri di misurazione FP si prendono in esame anche: T: numero di trasformazioni dei dati, R: numero di transizioni di stato del sistema. In questo modo oltre alla dimensione dati si tengono in considerazione anche le dimensioni funzioni e controlli. - COSMIC-FFP: metriche basate su FP ma adatte anche alla misurazione di sistemi realtime, sistemi distribuiti, sistemi per le telecomunicazioni, sistemi operativi. Sono compatibili con i principi O-O e con le specifiche UML.

Backfiring: esprime la connessione fra la dimensione del programma espressa in LOC e la dimensione espressa in FP.
Si parte da un coefficiente LC dipendente dal linguaggio di programmazione utilizzato (Es C++=29). Parallelamente va calcolato il coefficiente di complessit BAF che tiene conto di tre aspetti: complessit del problema, complessit delle strutture dati, complessit del codice. Ad ognuno dei tre aspetti va assegnato un valore che va da 1 a 5. La somma dei tre valori la complessit totale CT. La somma dei tre valori la complessit CT: BAF = 0.7 + 0.05 * ( CT 3 ) Da cui si ottiene il coefficiente di backfiring: backfiring= LC * BAF (esprime il numero di LOC per FP)

Metriche CK: insieme di 6 metriche per i sistemi orientati agli oggetti

WMC (Weighted Methods per Class): il numero di metodi di una classe un indicatore del tempo e dello sforzo necessario per implementare e manutenere la classe. Per calcolare WMC, ad ogni metodo viene assegnato un peso in base alla sua dimensione o alla sua complessit. Le classi con elevato WMC sono poco inclini al riuso. Il numero di errori proporzionale al suo WMC. DIT (Depth of inheritance Tree): numero di livelli dellalbero delle classi dellapplicazione. Un elevato DIT indica notevole riuso, ma anche complessit di progettazione. Secondo alcuni studi, consigliabile mantenere DIT <= 5 per avere il miglior compromesso fra riuso e complessit. NOC (Number of children): numero di classi che ereditano da una classe. Un elevato DIT indica notevole riuso, ma anche complessit di progettazione. CBO (Coupling Between Object classes) : indice dellaccoppiamento fra classi, definite come numero di metodi di una classe che fanno uso di metodi o attributi di altre classi. Se CBO basso, le modifiche in una classe non implicano modifiche in altre classi, dunque la modularit dellapplicazione alta. RFC (Response for a Class): numero massimo di metodi di una classe che pu essere invocato in risposta ad un messaggio ricevuto dalla classe. RFC = M + R. M = numero di metodi pubblici o protetti della classe. R = numero massimo di metodi che possono essere invocati da altri metodi, anche ricorsivamente. Rappresenta un indice della complessit interna di una classe. Le classi con elevato RFC sono difficili da comprendere. Difficolt nel testing e nella manutenzione della classe. LCOM (Lack of Cohesion in Methods): Indicatore del numero di metodi di una classe che condividono uno o pi attributi. E calcolato in questo modo: - P=Q=0 Per ogni coppia di metodi della classe: se accedono ad attributi diversi, P++ se invece condividono almeno un attributo, Q++: - (Se P > Q) LCOM = P Q - (Se P <= Q) LCOM = 0 NB: costruttori e distruttori non sono considerati. Una classe avente LCOM = 0 completamente coesa. Un valore di LCOM elevato indica che la classe pu essere suddivisa in due o pi classi, perch i suoi metodi accedono ad insiemi di attributi separati.
:

Metriche di Lorenz-Kidd: altro insieme di metriche per i sistemi orientati agli oggetti.
CS (Class Size): data dalla somma non pesata dei metodi e degli attributi della classe. Analogamente a WMC, una classe di dimensione elevata rende difficile il riuso ed potenzialmente pi esposta agli errori. NOO (Number of Overridden Operations): numero di metodi di classi dei livelli superiori della gerarchia ridefiniti nella classe in esame. Un NOO elevato indica che poche operazioni della gerarchia sono state raccolte a fattor comune nelle classi di livello pi alto, e generalmente questo un indice di cattiva progettazione. La gerarchia fragile e il prodotto pi difficile da collaudare e manutenere. NOA (Number of Operations Added): numero di metodi implementati nella classe in esame, che non sono ridefinizioni di metodi delle classi superiori. Al crescere di NOA, la classe si allontana dallastrazione rappresentata dalla sua classe base, perch significa che la specializzazione elevata. Una classe altamente specializzata rende difficile il riuso.

Metriche MOOD: Insieme di 6 indicatori per il grado di utilizzo di information hiding, ereditariet e polimorfismo in
un progetto orientato agli oggetti. MHF (Method Hiding Factor): grado di utilizzo della information hiding in un sistema orientato agli oggetti. E basato sul calcolo del Fattore di Visibilit VF: VF = (somma accessi ai metodi da altre classi / n. classi - 1) / totale metodi Da cui si ricava: MHF = ( 1 - VF ) * 100 AHF (Attribute Hiding Factor): analogo al precedente, ma applicato agli attributi. Idealmente, tutti gli attributi dovrebbero essere privati, quindi il valore consigliato AHF = 100%. MIF (Method Inheritance Factor): grado di utilizzo dellereditariet in un sistema orientato agli oggetti. MIF = n. metodi ereditati / n. totale metodi * 100 Il range consigliato 20% < MIF < 80%. AIF (Attribute Inheritance Factor): analogo al precedente, ma applicato agli attributi. Il range consigliato AIF < 48%. PF (Polymorphism Factor): misura del grado di ridefinizione dei metodi di una gerarchia. PF = n. metodi ridefiniti / n. totale metodi * 100 Il range consigliato PF > 20% (senza un limite superiore). CF (Coupling Factor): indicatore di accoppiamento fra classi. E calcolato come il CBO delle metriche CK. Il range consigliato CF < 12% (senza un limite inferiore).

Metriche per il collaudo: le metriche per il collaudo sono in realt metriche per la complessit computazionale
dellapplicazione: infatti maggiore la complessit e maggiore sar il numero di test cases necessari per effettuare il collaudo. La complessit ciclomatica di Tom McCabe una delle principali misure per il collaudo. Misure di Halstead In un programma, date le seguenti grandezze: n1 = numero di operatori distinti n2 = numero di operandi distinti N1 = numero totale delle occorrenze di operatori N2 = numero totale delle occorrenze di operandi Si definisce difficolt del programma: D = ( n1 / 2 ) * ( N2/ n2 ) Si definisce vocabolario del programma: n = n1 + n2 Si definisce lunghezza del programma: N = n1 log2 n1 + n2 log2 n2 Si definisce volume del programma: V = N log2 n Si definisce impegno del programma: e=V*D

Secondo una denominazione piuttosto diffusa: per operatori si intendono i costrutti di controllo del flusso, i costrutti condizionali e le formule matematiche. Per operandi si intendono le variabili e le costanti del programma. n1 = 6 n2 = 5 N1 = 8 N2 = 35

Metriche per la manutenzione

Misure di affidabilit: insieme piuttosto vasto di misure volte a determinare lincidenza dei difetti sullapplicazione, sul progetto e sul team di sviluppo. Per la misura dellaffidabilit dei sistemi si usano molto comunemente: MTTF (Mean Time To Failure) = tempo medio prima che si verifichi un guasto. MTTR (Mean Time To Repair) = tempo medio di risoluzione del guasto. Affidabilit = MTBF (Mean Time Between Failure) = MTTF + MTTR Disponibilit = MTTF / (MTTF + MTTR) * 100 Se MTTR tende a 0, laffidabilit dipende dalla frequenza dei guasti, mentre la disponibilit tende al 100%.

Il Software Maturity Index (SMI) un indicatore che definisce il grado di stabilit di un prodotto software sulla base di delle modifiche via via apportate alle nuove versioni del prodotto. Dati: MT = numero totale di moduli nella versione corrente. Fc = numero di moduli modificati nella versione corrente. Fa = numero di moduli aggiunti nella versione corrente rispetto alla precedente. Fd = numero di moduli eliminati nella versione corrente rispetto alla precedente. Si definisce: SMI = [ MT ( Fc + Fa + Fd ) ] / MT Al tendere di SMI a 1, il prodotto tende a stabilizzarsi.

Gestione di progetti Software

Project Manager: il suo compito guidare un progetto al successo.

Attivit del Software Project Manager: pianificazione, prevedere costi/tempi/uso risorse/volume di software da
sviluppare, pianificare le attivit, allocare e gestire le risorse, avviare le attivit, coordinare lo svolgimento dei lavori, controllare lo stato di avanzamento dei lavori, chiudere il progetto.

Il Software Project Manager prima di tutto un uomo di relazioni: raccoglie permanentemente informazioni
tecniche e non, risultati, impressioni e le consolida in delle previsioni che aggiorna di continuo. Attraverso le relazioni con una serie di interlocutori cerca di far accettare idee di cambiamento, cerca di capire cosa crea ostacoli e di eliminarlo, in un continuo compromesso tra il voler far meglio e il fare il possibile. Gli interlocutori del Project Manager sono normalmente chiamati Stakeholders. Il ruolo professionale del Software Project Manager richiede: capacit relazionali, competenze tecniche.

Pianificazione di progetto: scopo della pianificazione di progetto definire una strategia pratica per controllare,
coordinare e monitorare un progetto tecnico complesso. Gli obiettivi della pianificazione di un progetto software sono quelli di stabilire un quadro di riferimento che permetta al capo progetto di stimare realisticamente le risorse, i costi e i tempi di progetto.

La portata del software: la portata del software descrive i dati e i controlli che devono essere elaborati, le funzioni, i
vincoli, le interfacce e il grado di prestazioni e affidabilit che il sistema deve garantire.

Fattibilit: Una volta stimata la portata del software, bisogna stabilire se il progetto: possibile dal punto di vista
tecnico, possibile dal punto di vista delle risorse disponibili, conveniente dal punto di vista economico e/o organizzativo.

Le risorse: il secondo compito della pianificazione la stima delle risorse necessarie per portare a compimento lo
sviluppo del software. Risorse umane: compito del pianificatore determinare limpegno richiesto dal progetto in termini di risorse umane. Lesame delle risorse umane necessarie deve tenere conto di aspetti diversi: o Numero di persone necessarie o Livello di specializzazione delle persone o Costo delle persone o Disponibilit temporale o Organizzazione dei team di lavoro Componenti software riusabili: lutilizzo di architetture software orientate alla modularit ed al riuso offre alle software house la possibilit di riutilizzare componenti software. I componenti software si possono suddividere in 4 categorie: o Componenti di serie: software esistente e funzionante, sviluppato in proprio o da terzi, pronto alluso, certificato e documentato. o Componenti gi sperimentate: specifiche, progetti, codice o dati per collaudi sviluppati per progetti precedenti, largamente simili al progetto in esame. I membri dellattuale team di sviluppo hanno una sufficiente conoscenza di questi componenti e del loro ambito applicativo, quindi le modifiche da apportare comportano rischi ridotti.

o o

Componenti parzialmente sperimentati: simili ai precedenti, ma necessitano di modifiche sostanziali per poter essere utilizzati nel progetto corrente. Nuovi componenti: componenti software che devono essere necessariamente sviluppati ex novo per il progetto corrente.

Strumenti hardware e software o SEE (Software Engineering Environment): ambiente costituito dallinsieme di strumenti hardware e software necessari per sviluppare lapplicazione. o Target environment: ambiente sul quale dovr essere realmente eseguito il software, una volta consegnato allutente finale.

Stima ed incertezza: spesso viene richiesta una stima sulla base di pochi elementi. Una stima accurata richiederebbe
requisiti precisi, una fase di progettazione relativamente dettagliata, la conoscenza di chi svilupper il prodotto. Daltra parte una stima di massima e spesso necessaria per verificare la percorribilit del progetto. Dobbiamo stimare di fronte allincertezza.

Certezza e Accuratezza
Una stima certa e una stima che sicuramente comprende nel proprio range il valore vero. Una stima accurata ha un errore relativo basso, es. 1%.

Tecniche di stima - Stime dimensionali: le stime dimensionali si basano su tecniche di scomposizione.

o Stime dimensionali basate su LOC: la scomposizione viene effettuata dividendo il sistema in funzioni, sotto-funzioni, sotto-sotto-funzioni etc. fino a raggiungere un livello di granularit tale che ogni funzione atomo sia ragionevolmente confrontabile con una funzione gi sviluppata, in termini di LOC oppure, stimabile in termini di LOC con un ragionevole grado di certezza e accuratezza. Si stima cos la dimensione in LOC della funzione atomo, producendo tre valori: sopt stima ottimistica sm stima probabile spess stima pessimistica A questo punto si applica una media pesata delle tre stime, sulla base di fattori di correzione stabiliti dal project manager (es: S(i) = (sopt + 4 * sm + spess ) / 6 ). La somma delle stime S(i) di tutte le funzioni atomo costituisce la stima S della dimensione del prodotto finito, espressa in LOC. Determiniamo la produttivit media degli sviluppatori, espressa in linee di codice. Pm= LOC / m-m A questo punto pu essere calcolato limpegno E per lo sviluppo del software: E = S / Pm Problemi: stima della dimensione largamente empirica risente dei problemi delle metriche basate su LOC assume produttivit media costante non tiene conto dell interferenza fra gli sviluppatori o Stime dimensionali basate su FP: anzich concentrarsi sulle funzioni, la scomposizione viene effettuata in base ai criteri delle metriche FP. Anche in questo caso per ogni fattore di misurazione opportuno stimare un valore ottimistico, probabile e pessimistico in termini di FP e generare una media pesata in base a fattori di correzione. Si giunge cos alla stima S della dimensione del progetto, espressa in FP: Pm = FP / m-m E = S / Pm

Stime Model-based: le stime Model-based applicano modelli matematici ad una stima dimensionale del
prodotto da realizzare. Si tratta quindi di stime di secondo livello: - Prima si stima la dimensione del prodotto (in LOC o FP) poi si applicano modelli matematici su questa stima, per determinare sforzo e tempo (incertezza). o Il modello COCOMO (COnstructive COst MOdel): basato su un modello algoritmico. Si basa sul processo di sviluppo a cascata e consente di calcolare, tramite una serie di formule ed in base a parametri, una stima di: quantit di lavoro M (espressa in m-m) tempo di sviluppo T (espresso in mesi)

COCOMO divide le applicazioni in tre tipi: Semplici (Organic Mode): applicazioni semplici e di dimensioni limitate, senza requisiti particolarmente stringenti. Intermedie (Semi-detached Mode): complessit e dimensioni medie. Complesse (Embedded Mode): attento controllo del processo di sviluppo, rigida applicazione di precise normative di controllo qualit. Per ognuno dei tre modelli sono definite le formule per la stima di M e T, secondo un livello di dettaglio crescente. 1) Basic COCOMO: stima i costi sulla base della sola dimensione complessiva. Si adatta ai progetti pi semplici. b d M = ab* S b T = cb * M b I valori ab, bb,cb, db variano in funzione del tipo di applicazione Esempio: Consideriamo unapplicazione Organic Mode di dimensione stimata S = 32 KDSI. Indicatori derivati: 1.05 1.05 M = 2.4 (S) = 2.4 (32) = 91 m-m Productivity: 32,000 DSI / 91 m-m = 352 DSI/m-m 0.38 0.38 T = 2.5 (M) =2.5 (91) = 14 mesi Average staffing: 91 m-m / 14 mesi = 6.5 FSP 2) Intermediate COCOMO: la stima di M viene raffinata mediante luso di coefficienti correttivi (detti cost drivers) relativi a caratteristiche e vincoli di progetto. Il valore di T viene calcolato allo stesso modo del modello Basic. ci < 1 fattore che agevola lo sviluppo bi d M = ai * S * cj T = cb * M b ci = 1 fattore ininfluente ci > 1 fattore che ritarda lo sviluppo 3) Detailed COCOMO: fornisce alcuni miglioramenti alle limitazioni dellintermediate cocomo: Phase-Sensitive Effort Multipliers: introduce dei moltiplicatori di quantit di lavoro a livello di fase di progetto. Three-Level Product Hierarchy: tratta in modo differenziato: - Effetti che tendono a variare con ogni modulo sono trattati a livello modulo. - Effetti che variano meno frequentemente sono trattati a livello sottosistema. - Effetti come la dimensione totale del prodotto sono trattati a livello sistema. Ipotesi alla base di COCOMO Il modello COCOMO si basa su alcune assunzioni: - Modello di sviluppo a cascata - Requisiti ritenuti sostanzialmente stabili - Progetto svolto da poche persone molto capaci e con profonda conoscenza del dominio applicativo - Progetto di dettaglio, codifica e test a livello di modulo compiuti in parallelo da vari team di programmazione - Documentazione scritta in modo incrementale

Equazione del Software (Putnam): un modello di stima multivariabile che prevede una particolare distribuzione dellimpegno nel corso di un progetto di sviluppo software. Nella sua formulazione 1/3 4/3 originale, lequazione : Project Size = (Process Productivity) ( Effort / Skill factor ) ( Time ) Lequazione del software contiene due parametri di stima indipendenti, una stima dimensionale in LOC, una stima della durata del progetto in mesi. 1/3 4/3 Equazione risolta per produttivit: PP = (LOC) / ( E / SF ) ( T ) Dove PP = Process Productivity, SF = Skill Factor. 3 4 Risolta per Effort, lequazione diventa: E = [ LOC / PP ] * SF * ( 1 / T )

Expert estimate: prevede la scomposizione dello sviluppo in una serie di attivit, ad ognuna delle quali
viene assegnato un impegno espresso in m-m, sulla base di esperienze precedenti. E opportuno fornire stime pessimistiche, probabili e pessimistiche in termini di impegno e generare una media pesata in base a fattori di correzione. Limpegno E del progetto dato dalla somma degli impegni delle varie attivit.

Make or buy: In ogni progetto software, in molte aree applicative il management si trova davanti ad una scelta fra
sviluppo interno (make) o acquisto di componenti software da fornitori esterni (buy). Lacquisto pu essere di tre tipi: 1. Software gi commercializzato come pacchetto 2. Componenti software gi sperimentati, che devono essere modificati per poter essere incorporati nellapplicazione 3. Outsourcing: software commissionato ad un produttore esterno, al quale vengono fornite le specifiche.

Analisi e gestione dei rischi: ogni progetto software caratterizzato da un certo margine di rischio, che pu
coinvolgere alcune parti del progetto e, nei casi peggiori, far fallire lintero progetto. Compito dellingegnere del software comprendere i rischi e prendere le misure preventive necessarie per evitarli o gestirli. Gestire un rischio significa: identificarlo, stimare la probabilit che si verifichi, stimare limpatto dellevento sul progetto, stabilire un piano da attuare nel caso in cui il problema dovesse effettivamente verificarsi.

Identificazione del rischio: i rischi vengono individuati e catalogati in diverse categorie:

Dimensione del prodotto: rischi associati alla dimensione complessiva del software da realizzare. Impatto commerciale: rischi associati ai vincoli imposti dal management o dal mercato. Caratteristiche del cliente: rischi associati alla sofisticazione del cliente e alla capacit dello sviluppatore di comunicare con esso. Maturit del processo: rischi associati alla precisione con cui il processo di sviluppo definito e seguito dalla societ. Tecnologia: rischi associati alla complessit tecnologica del sistema da realizzare. Persone: rischi associati allesperienza tecnica e progettuale dei membri del team di sviluppo.

Classificazione del rischio: i rischi vengono classificati in base alla loro probabilit ed in base alla gravit delle
conseguenze. Un indicatore di gravit lesposizione al rischio, definita dalla seguente espressione: ER = P(EN) * C(EN). P(EN) la probabilit che si verifichi levento EN, C(EN) la perdita economica (stimata) conseguente allevento EN.

Livello di riferimento per i rischi: il verificarsi di un rischio di progetto causa un impatto su: tempi di sviluppo, costi
di sviluppo, decadimento delle prestazioni, necessit di supporto. Per un rischio ri, si definisce Punto di rottura il punto nello spazio tempi/costi tale che, per costi superiori e per tempi superiori non ha pi senso continuare il progetto. La curva che unisce i punti di rottura di tutti i rischi detta Livello di riferimento per i rischi.

Gestione dei rischi idea di fondo:

- ordinare i rischi in base allesposizione al rischio - prevedere azioni correttive per tutti i rischi aventi unesposizione superiore ad una certa soglia. I rischi vengono gestiti con una strategia preventiva; lanalisi e gestione dei rischi un processo continuativo.

Pianificazione temporale e controllo dei progetti: il risultato dellattivit di pianificazione temporale il piano di
progetto, documento che descrive dettagliatamente: i singoli compiti che costituiscono il progetto, i responsabili dei vari compiti, la pianificazione temporale dei compiti, i punti di controllo.

Principi fondamentali della pianificazione temporale

Ripartizione: il progetto deve essere ripartito in un insieme di singole attivit dalle dimensioni ragionevoli. Interdipendenza: occorre determinare le dipendenze reciproche fra le attivit. Alcune di esse possono essere svolte in parallelo, altre devono essere messe in sequenza perch vincolate dal completamento di altri compiti. Assegnazione: ad ogni attivit deve essere assegnati: - un certo numero di unit di lavoro. - le persone dello staff che effettivamente svolgeranno il lavoro. - data di inizio e data di fine, in funzione delle interdipendenze e delle milestones imposte al progetto. Validazione dellassegnazione: in ogni istante del progetto, necessario verificare che il totale delle persone assegnate alle varie attivit non superi il numero totale di risorse assegnate al progetto. Responsabilit: necessario nominare un responsabile per ogni attivit. Risultati: ogni attivit deve produrre un risultato ben definito. Punti di controllo: ad ogni attivit o gruppo di attivit deve essere associato un punto di controllo del progetto.

Individuazione delle attivit

Per unefficace pianificazione temporale del progetto, opportuno che tutte le attivit rientrino nel piano di progetto. Le varie fasi del progetto vengono scomposte in una serie di attivit al massimo grado di dettaglio possibile.

Diagramma di Gantt: Le attivit sono rappresentate mediante barre orizzontali in scala temporale. Ad ogni attivit
vengono assegnati: un ID univoco, data di inizio, durata, vincoli. Le milestones sono delle attivit a durata 0. E possibile definire delle attivit riepilogo, che raggruppano altre attivit. Diagrammi PERT/CPM (PERT: Program Evaluation and Review Technique, CPM: Critical Path Method) Sono strumenti quantitativi che consentono al project manager di: Rappresentare graficamente la sequenza delle attivit (non in scala temporale) Stabilire le stime dei tempi necessari per il completamento delle singole attivit Definire la finestra temporale entro la quale ciascuna attivit deve iniziare e terminare Determinare il cammino critico, ossia la sequenza di compiti che determina la durata complessiva del progetto

Analisi del valore acquisito: lanalisi del valore acquisito (EVA Earned Value Analysis) una tecnica quantitativa
per valutare i progressi durante lavanzamento di un progetto. Consente di calcolare la percentuale di completamento del progetto, con un ragionevole grado di approssimazione. 1. Indicatori di avanzamento: Si basano sullesame dei costi preventivi delle attivit (Budgeted Cost of Work Scheduled/Performed). BCWSi= costo previsto per lattivit i del progetto, espresso in giorni-uomo. E data dalla durata prevista dellattivit i moltiplicata per il numero di persone assegnate ad essa. Budget At Completion BAC = BCWSi per i = tutte le attivit del progetto. In un tempo t dellavanzamento del progetto, si calcolano: BCWP = BCWPk per k = attivit del progetto che sono state effettivamente completate al tempo t. BCWS = BCWSk per k = attivit del progetto il cui completamento era stato pianificato entro t. Con queste grandezze possibile calcolare i seguenti indicatori: Schedule Performance Index: SPI = BCWP / BCWS Schedule Variance: SV = BCWP BCWS % completamento prevista = BCWS / BAC % completamento effettiva = BCWP / BAC Un valore di SPI prossimo a 1 indica una buona pianificazione del progetto. 2. Indicatori di controllo dei costi: i calcoli visti finora si riferiscono ai costi budget, ossia costi preventivi. Esistono altri indicatori, che fanno uso dei costi consuntivi delle varie attivit. Actual Cost of Work Performed ACWPi = costo effettivo dellattivit i del progetto, espresso in giorni-uomo. E data dalla durata effettiva dellattivit i moltiplicata per il numero di persone che hanno lavorato ad essa. ACWP = ACWSk per k = attivit del progetto che sono state effettivamente completate al tempo t. Si ottengono cos gli indicatori: Cost Performance Index: CPI = BCWP / ACWP Cost Variance: CV = BCWP ACWP Un valore di CPI prossimo a 1 indica un buon controllo dei costi di progetto. Esempio:

Gestione delle Configurazioni: unattivit volta a garantire che tutte le informazioni relative ad un progetto siano
consistenti in ogni istante del ciclo di vita. Ogni elemento interessato alla SCM detto SCI (Sw. Configuration Item): Dati: Documenti: Programmi: - Strutture dati esterne ai programmi - Documenti di progetto - Codice sorgente - Manuali utente - Eseguibili - Test Cases Il database che tiene traccia di tutte le versioni dei SCI detto Repository. La fotografia di tutti gli SCI in uno stato consistente detta Baseline.

Processo di Gestione delle Configurazioni: in un progetto reale i SCI possono essere migliaia. La necessit di
modificarli molto frequente. Le modifiche sono a carico di persone diverse, e non possono essere introdotte in contemporanea. Per evitare il caos, necessario definire il Processo di Gestione delle Configurazioni del progetto. Il processo prevede le seguenti attivit: - Allestimento di un repository definendo quali sono gli elementi interessati alla SCM. - Definizione di una serie di procedure aziendali che regolano le modifiche ai SCI. - Definizione dellente aziendale che controlla lintroduzione di nuove modifiche nel repository.

Check-Out: estrazione dal repository di una copia locale del SCI. Normalmente solo una sola persona alla volta pu modificare un SCI: il sistema pone un lock sullelemento, e il checkout detto esclusivo. Se invece pi persone in contemporanea possono modificare lo stesso SCI, il check-out detto condiviso. Dopo aver effettuato il check-out, lutente pu modificare la versione locale del SCI senza che questo interferisca con il lavoro degli altri membri del team. Una volta ultimate le modifiche, lutente sottopone al CCB una richiesta di introduzione di modifiche. Normalmente questo viene fatto tramite un documento nel quale si specifica: motivazione della modifica, tipologia della modifica, descrizione tecnica, SCI correlati, test effettuati, grado di rischio. Il CCB si riunisce periodicamente ed esamina tutte le richieste pervenute. Sulla base degli elementi riportati in una richiesta, il CCB pu decidere di: approvare la richiesta, richiedere nuove modifiche, respingere la richiesta. In caso di approvazione, lutente autorizzato ad introdurre la propria versione del SCI nel repository. Questo viene fatto mediante un Check-In dellelemento. Il check-in rilascia leventuale lock sullelemento e crea una nuova versione del SCI nel repository. Lintroduzione di pi modifiche che generano una nuova situazione consistente porta alla definizione di una nuova baseline per il progetto.

Versioning: la gestione dellevoluzione delle varie versioni di tutti i SCI possibile solo con lutilizzo di strumenti di
Versioning, che permettono: Gestione delle versioni, con regolamentazione degli accessi al repository da parte di tutti i membri del team. Confronto fra versioni diverse dello stesso file. Memorizzazione di commenti di check-in, per una facile tracciabilit delle modifiche introdotte. Assegnamento di tag a particolari versioni di un file, al fine di identificare versioni particolarmente significative. Gestione di modifiche concorrenti allo stesso file. Annullamento di modifiche con regressione a versione precedente. Possibilit di sviluppi paralleli. Allineamento automatico delle modifiche.

Introduzione ai metodi formali

I Metodi Formali sono particolari tecniche di formulazione delle specifiche di progetto basate sullutilizzo di linguaggi formali. I Linguaggi formali: sono linguaggi per i quali esiste sia una sintassi che una semantica ben definita. I metodi formali partono dallapplicazione di concetti matematici alla stesura delle specifiche.

Linguaggi di specifica formali: presenta tre aspetti fondamentali:

1. Una sintassi, che definisce la notazione per le specifiche. 2. Una semantica, che definisce luniverso degli elementi utilizzati per descrivere il sistema. 3. Un insieme di relazioni, che definiscono le regole in base alle quali si pu stabilire quali elementi soddisfano una specifica.

Concetti di base dei metodi formali

Invariante: una condizione che deve essere sempre verificata durante lesecuzione di un sistema che gestisce dati. Stato: insieme dei dati memorizzati ai quali il sistema accede e che il sistema modifica. Operazione: azione che si svolge nel sistema e che consiste nel leggere/modificare dati che fanno parte dello stato. Precondizione: definisce le circostanze nelle quali loperazione ammessa. Postcondizione: definisce leffetto delloperazione sullo stato.

Reingegnerizzazione del software

Attivit di ristrutturazione, manutenzione e aggiornamento di una soluzione software, effettuata ai fini di migliorare la sua architettura, la sua manutenibilit, comprensibilit, etc. Spesso la reingegnerizzazione viene svolta su progetti ereditati da altri. In questo caso lattivit di reingegnerizzazione parte dal reverse engineering dellapplicazione. In altri casi, la reingegnerizzazione viene svolta preventivamente, al fine di anticipare possibili problemi. Si parla in questo caso di manutenzione preventiva dellapplicazione. The two hats Cappello dello sviluppatore: quando si aggiungono nuove funzionalit allapplicazione, si indossa il primo cappello. Non si dovrebbe modificare il codice gi esistente; semplicemente si aggiungono nuove classi, o nuovi metodi a classi preesistenti, etc. Cappello del ristrutturatore: quando si ristruttura lapplicazione, si indossa il secondo cappello. Si modifica il codice gi esistente, ma non si aggiungono nuove funzionalit. In realt, durante lo sviluppo i due cappelli vengono scambiati continuamente.

Refactoring: uno dei principi fondamentali del refactoring la bassissima probabilit di introdurre nuovi bachi
effettuando la reingegnerizzazione. Il risultato ottenuto attraverso lesecuzione sistematica di test sullapplicazione. Il refactoring: migliora il design della soluzione software, aiuta ad eliminare duplicazioni di codice, migliora la comprensibilit del codice, aiuta a scoprire errori e bachi, aiuta a migliorare le performance dellapplicazione, permette di aumentare la produttivit degli sviluppatori. I Processi Agili fondano la loro stessa natura sul refactoring continuativo della soluzione in via di sviluppo.

Catalogo dei refactorings: tutti i refactorings presentati nel testo hanno la seguente forma:
Nome: identificativo univoco del re factoring. Descrizione: breve descrizione del refactoring, accompagnata da diagrammi UML e/o codice sorgente per illustrare la soluzione prima e dopo il refactoring. Motivazione: descrizione delle finalit del refactoring, dei casi in cui pu essere applicato, dei casi in cui deve essere evitato. Meccanica: descrizione dettagliata dei passi da compiere per effettuare il re factoring. Esempio: illustra un utilizzo molto semplice del re factoring. Il catologo presenta in totale 72 refactorings.

public static void P(){ // Entry while(A) { X; if (B) { if(C) Y; else Z; // p } else { V; W; } // q } // Exit: r } }

int trasformaVett(int A[], int N, int X) { int i = 0; while (i < N && A[i] < X) { if (A[i] < 0) A[i] = -A[i]; i++; } return 0; }