Introduzione all Ingegneria del Software

Transcript

1 Introduzione all Ingegneria del Software Alessandro Martinelli 28 novembre 2014 Introduzione all Ingegneria del Software Ingegneria del Software Modelli di Sviluppo del Software Waterfall Model Modelli a Spirale Sviluppo Incrementale ed Iterativo Agile Software Development ed Extreme Programming Il Rilascio del Software e le Versioni Fondamenti di Informatica II

2 Ingegneria del Software Due parole : Software e Ingegneria Software Linguaggi (C,Java), Paradigmi (Procedurali, ad Oggetti), Metafore di Programmazione Codice di Programmazione Strumenti di Case (Eclipse) Ingegneria Progettazione, Disegno Sviluppo e Produzione Verifica, Collaudo Uso di Strumentazione Tecnica Applicazione di Standard A. Martinelli Modelli di Sviluppo 28 novembre / 72

3 Ingegneria del Software Ingegneria del Software Ingegneria del Software Un insieme di pratiche Ingegneristiche che servono a supportare e a migliorare la realizzazione di un prodotto software. Migliorare? Ridurre i tempi di sviluppo Ridurre gli errori di produzione. Sfruttare soluzioni standard di cui beneficino modularità, riciclabilità, portabilità, usabilità... A. Martinelli Modelli di Sviluppo 28 novembre / 72

4 Alcuni Elementi di Ingegneria del Software Le pratiche dell Ingegneria del Software Tra le pratiche principali dell Ingegneria del Software troviamo: Metriche : forniscono valutazioni oggettive e misurabili del codice. Design Pattern : offrono dei modelli di progettazione utili e riciclabili. Linguaggi di Modellazione : offrono uno strumento per l analisi e la progettazione del Software. Esempio: i Diagrammi delle Classi UML Metodologie e Tool per lo Sviluppo : formalizzano la tecnica di sviluppo del Software, standardizzando lo sviluppo stesso, consentendo un più semplice coordinamento tra gli sviluppatori. Questa lezione è dedicata soprattutto ai Modelli di Sviluppo. A. Martinelli Modelli di Sviluppo 28 novembre / 72

5 Alcuni Elementi di Ingegneria del Software Metriche Alcuni esempi di metriche: LoC (Lines of Code) : ne esistono molte varianti Fattore di qualità : Q = LoC N Errori Critica alle Metriche LoC o simili Famose intorno agli anni 80, venivano usate per misurare la produttività degli sviluppatori e sono state estremamente criticate, perché: Poco significative. Favoriscono la ripetizione e la duplicazione di codice. Sfavoriscono interventi volti a migliorare la riusabilità del codice. Perchè: le metriche buone (come la Lack of Cohesion in Methods) sono quelle che l ingegnere usa per valutare la qualità del proprio operato, non quelle usate dai dirigenti per valutare la produttività degli ingegneri. A. Martinelli Modelli di Sviluppo 28 novembre / 72

6 Modelli di Sviluppo del Software Modelli di Sviluppo del Software Per agevolare l organizzazione ed il flusso di lavoro di grandi progetti è necessario definire un Modello di Sviluppo attraverso il quale vengono pianificate ed organizzate le attività di Sviluppo. La scelta del Modello di Sviluppo è vincolata: Dalle persone coinvolte Dai requisiti temporali (i.e. Pagamento alla consegna) Dalla dimensione del progetto Dalla tipologia di Progetto Dal periodo storico in cui il progetto è iniziato Sulle Metodologie di Sviluppo Il tema della Metodologia di Sviluppo è un tema molto caldo al giorno d oggi. Le Metodologie moderne sono talvolta complesse. C è una forte entropia sull argomento, perchè gli interessati si informano unicamente sul web. C è una diffusa ingenuità ed ignoranza sull argomento. A. Martinelli Modelli di Sviluppo 28 novembre / 72

7 Modelli di Sviluppo del Software Le Fasi dello Sviluppo Ogni Modello di Sviluppo ha come obiettivo quello di pianificare lo Sviluppo in fasi ben determinate Ogni fase avrà obiettivi specifici e farà uso di strumenti differenti. Il coordinamento delle fasi deve consentire di raggiungere l obiettivo finale che è la realizzazione di un progetto. Fasi tipiche dello sviluppo : Definizione dei Requisiti Analisi Codifica Validazione (Testing/Debugging) Rilascio A. Martinelli Modelli di Sviluppo 28 novembre / 72

8 Il Modello a Cascata Il Waterfall Model (Modello a Cascata) Il Modello a Cascata definisce un elenco di attività che devono essere svolte in sequenza. Il concetto di Modello a Cascata può essere applicato a differenti tipologie di Cascate. Il modello originale prevedeva questi passi: Definizione delle Specifiche Progettazione Implementazione Integrazione (con i dispositivi e gli altri sistemi con cui il progetto si deve integrare) Validazione: Testing(per verificare l esistenza di errori) e Debugging (per rimuove gli errori). Installazione. Manutenzione. A. Martinelli Modelli di Sviluppo 28 novembre / 72

9 Il Modello a Cascata Il Waterfall Model (Modello a Cascata) Specifiche Progetto Implementazione Verifica Manutenzione A. Martinelli Modelli di Sviluppo 28 novembre / 72

10 Il Modello a Cascata Il Waterfall Model : Difetti La fase di definizione delle Specifiche è Definita una volta per tutte. Questo rende impossibile rivedere le specifiche qualora durante lo sviluppo si presentassero delle complicazioni. La fase di progettazione avviene prima di tutto lo sviluppo; anche in questo caso è impossibile tornare sui propri passi qualora le cose non andassero come si deve La fase di Manutenzione è particolarmente critica. Il progetto è chiuso. Qualsiasi esigenza aggiuntiva diventa difficile da soddisfare in un secondo momento. A. Martinelli Modelli di Sviluppo 28 novembre / 72

11 Il Modello a Spirale Il Modello a Spirale Le critiche al Modello a Cascata suggeriscono un l uso di un Modello che consenta di tornare sui propri passi. Il Modello a Spirale complica quello a cascata con le seguenti considerazioni: Definito l elenco di specifiche e di funzionalità di un prodotto, gli sviluppatori selezionano alcuni obiettivi iniziali. Il processo di sviluppo, che qui è detto ciclo, prevede questi step: Definizione Specifiche Valutazione dei rischi legati allo sviluppo Implementazione Validazione (Testing-Debugging) Terminato il processo di Validazione, vengono considerati nuovi obiettivi e nuovi requisiti e si ricomincia da capo. Il Modello è a Spirale perchè ad ogni ciclo di sviluppo si produce una nuova versione del progetto, di dimensione crescente. Soprattutto nella fase iniziale, le versioni sono dette Prototipi, ed il processo di selezione dei requisiti nelle prime fasi viene detto Prototipazione. A. Martinelli Modelli di Sviluppo 28 novembre / 72

12 Il Modello a Spirale Il Modello a Spirale 3 4 Implementazione Validazione Rilascio Prototipo 2 Valutazione Rischi Requisiti 1 A. Martinelli Modelli di Sviluppo 28 novembre / 72

13 Il Modello a Spirale Il Modello a Spirale Il Modello a Spirale è in genere vantaggioso perchè consente di descrivere un processo un poco per volta. La fase di valutazione dei rischi rende più robusta la gestione del progetto La progettazione a piccoli passi consente di valutare più rapidamente eventuali difficoltà di sviluppo. Lo sviluppo un poco alla volta rende anche più facili le fasi di testing e debugging: E più facile definire test adeguati. E più facile trovare gli errori se si è modificato meno codice. A. Martinelli Modelli di Sviluppo 28 novembre / 72

14 Il Modello a Spirale Sviluppo Incrementale ed Iterativo Col Modello a Spirale spesso si introducono il concetto di Sviluppo Incrementale ed Iterativo. Sviluppo Iterativo Quando lo sviluppo segue delle iterazioni, ovvero è ciclico. Sviluppo Incrementale Quando lo sviluppo si basa su specifiche che vengono definite un po alla volta. I clienti/commissionanti od utenti possono giocare un ruolo fondamentale. In tutti i casi l uso dello Sviluppo Incrementale ed Iterativo favorisce lo sviluppo dei Prototipi che possono essere rilasciati al commissionante. Questo consente al commissionante di Rivalutare le specifiche, diventando parte integrande e fondamentale del processo di Sviluppo. A. Martinelli Modelli di Sviluppo 28 novembre / 72

15 Il Modello a Spirale Sviluppo Incrementale ed Iterativo Requirements, Testing Analisi, Design Implementation Initial Planning Deployment Evaluation Testing I Rilasci (Deployment) diventano un elemento fondamentale perchè consentono all utente finale di avere una valutazione in corso d opera del lavoro svolto. A. Martinelli Modelli di Sviluppo 28 novembre / 72

16 Il Modello a Spirale I Modelli Evolutivi e l Agile Software Development Modelli Evolutivi L Agile Software Development (in italiano si usa l espressione Metodologie Agili) rientra nei cosidetti Modelli Evolutivi, che si fondano sull idea centrale di coinvolgere il cliente o l utente, fornendogli continue nuove versioni in modo che possa essere partecipe nello sviluppo del progetto. L Obiettivo principale dell Agile Software Development è rendere il cliente il più soddisfatto possibile. Inoltre, si cerca di sostituire il modello di ciclo fisso, con qualcosa di più elastico e dinamico. A. Martinelli Modelli di Sviluppo 28 novembre / 72

17 Il Modello a Spirale Dal Manifesto dell Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. A. Martinelli Modelli di Sviluppo 28 novembre / 72

18 Il Modello a Spirale Dal Manifesto dell Agile Software Development Individuals and interactions Le Persone e le loro relazioni sono molto più importanti della strumentazione tecnica o degli strumenti che vengono utilizzati per produrre software. Working software E inutile realizzare del software difficile da utilizzare o poco comprensibile da capire e poi fornire tonnellate di documentazione. E molto meglio scrivere codice facile da capire e da usare. Nell Agile Software Development il cliente diventa un elemento partecipe del progetto e le considerazioni di cui sopra lo coinvolgono. Customer collaboration La partecipazione del cliente o del committente al progetto, aumenta la probabilità che sia soddisfatto del lavoro che viene svolto. La partecipazione avviene effettuando continui rilasci e dando quindi la possibilità al cliente di vedere il proprio progetto crescere. A. Martinelli Modelli di Sviluppo 28 novembre / 72

19 Il Modello a Spirale Responding to change (Operare per il cambiamento) Responding to change over following a plan : questo punto di vista ha un enorme importanza perché non seguire un piano significa evitare, del tutto o in parte, la fase di analisi. Cambiamento Tutti i sistemi cambiano e si evolvono nel tempo. I Clienti partecipano e contribuiscono con nuove idee, o propongono nuove caratteristiche. I cambiamenti in corso d opera rendono la manutenzione del Software difficile. Come deve avvenire la Progettazione per tenere conto del Cambiamento? A. Martinelli Modelli di Sviluppo 28 novembre / 72

20 Il Modello a Spirale Responding to change : Progettazione Agile La Progettazione Agile non avviene in un momento ben definito. Avviene continuamente, tutte le volte che nel codice si verifica uno dei seguenti problemi. Cambiamento Rigidità: il sistema è difficile da cambiare Fragilità: le modifiche causano malfunzionamenti Immobilità: i sorgenti sono difficili da riutilizzare Viscosità: i cambiamenti compatibili con l architettura sono difficili da realizzare Complessità inutile: il sistema è più complicato del necessario Ripetizioni inutili: i sorgenti contengono codice simile Opacità: la funzione dei moduli non è facilmente comprensibile Nello Sviluppo Agile non si fa mai progettazione, ma si fa piuttosto Riprogettazione (Refactoring) A. Martinelli Modelli di Sviluppo 28 novembre / 72

21 Il Modello a Spirale Responding to Change : Modularità Fin dall inizio della storia della programmazione si è cercato di definire il concetto di Modularità Modularità Lo studio di metodologie agili ha contribuito a migliorare il concetto di Modularità, soprattutto per quanto riguarda la programmazione ad oggetti Il Refactoring aiuta ad ottenere moduli con una elevata Coesione ed un Basso livello di Accoppiamento, e a definire astrazioni, in modo da rende gli oggetti più riciclabili. E l Agile Software Development che ha introdotto i principi SOLID, oggigiorno considerati principi generali di una buona programmazione ad oggetti. Perché è fondamentale nell Agile Software Development rispondere ai cambiamenti di specifiche: Se i moduli sono coesi, sono tanti e piccoli ed è più facile fare le modifiche solo dove occorre. Se i moduli sono disaccoppiati, le modifiche non si propagheranno nel codice. I principi SOLID aiutano a mantenere alta la Coesione e basso l Accoppiamento. A. Martinelli Modelli di Sviluppo 28 novembre / 72

22 Il Modello a Spirale Extreme Programming (XP) (1/4) Formulato da Kent Beck, Ward Cunningham e Ron Jeffries intorno al 1999, Istituisce su una serie di pratiche per lo Sviluppo Agile: Pair Programming Planning Game Test-Driven Development Whole-Team Continuous Integration Refactoring o Design Improvement Small Releases Coding Standards Collective Code Ownership Symple Design System Metaphor Sustainable Pace A. Martinelli Modelli di Sviluppo 28 novembre / 72

23 Il Modello a Spirale Extreme Programming (XP) (2/4) Pair Programming Due Programmatori lavorano allo sviluppo del codice. Questa pratica ha lo svantaggio di aumentare i tempi di sviluppo, ma diminuisce la probabilità che durante lo sviluppo vengano fatti errori. Planning Game La Pianificazione non avviene una volta per tutte, ma avviene continuamente e sulla base di interventi anche del cliente, un po come in un gioco dove il cliente fa la prima mossa, il programmatore lo segue e così via fino a progetto realizzato Test-Driven Development I Test vengono realizzati prima ancora di scrivere codice. Questa prassi ha l enorme vantaggio di aiutare a capire come devono essere sviluppate certe cose, oltre a fornire una base stabile per le fasi di debugging. Whole-Team L Utente finale del sistema DEVE contribuire ed essere parte integrante dello sviluppo, la sua opinione conta più di ogni altra idea su come il progetto debba andare avanti. A. Martinelli Modelli di Sviluppo 28 novembre / 72

24 Il Modello a Spirale Extreme Programming (XP) (3/4) Continuous Integration I cambiamenti vengono integrati continuamente nel codice, e mai rimandati ad una successiva fase di progettazione. Refactoring La riscrittura del codice che non cambia la funzionalità del programma, è usata perchè rende il codice più snello, generale e quindi più semplice da integrare e riutilizzare nel tempo. Small Releases Continue consegne rendono il cliente e l utente sia più responsabile del lavoro che viene svolto, sia più fiducioso. Coding Standards Il codice dovrebbe sempre seguire delle regole standard definite fin dall inizio del progetto A. Martinelli Modelli di Sviluppo 28 novembre / 72

25 Il Modello a Spirale Extreme Programming (XP) (4/4) Collective Code Ownership Tutti sono responsabili di tutto. Il codice è condiviso ed appartiene a tutti. Symple Design Nella progettazione, le soluzioni più semplici dovrebbero essere sempre le migliori System Metaphor Usare delle metafore su come il sistema funziona. Le Metafore possono essere viste come storie (Users Stories) che forniscono informazioni sul sistema, ma che dovrebbero farlo in modo più semplice da capire per tutti. Sustainable Peace Non fare straordinare, non eccedere, fare pause. I programmatori quando sono freschi e riposati fanno meno errori... A. Martinelli Modelli di Sviluppo 28 novembre / 72

26 Il Modello a Spirale Un tipico ciclo di sviluppo nell Extreme Programming Stima rilascio Iterazione con l'utente iterazione Acceptance Test ogni giorno Pianifica Rilascio Pianifica Iterazione Test Driven Development continuamente Implementazione Refactoring Integrazione Working Software A. Martinelli Modelli di Sviluppo 28 novembre / 72

27 Il Modello a Spirale Il Rilascio del Software Rilascio (Deployment) Con rilascio si intende la generazione di una versione che viene messa a disposizione degli utenti finali. Lo Sviluppo Incrementale ed Iterativo e l Extreme Programming prevedono un meccanismo a rilasci continui che consente l interazione con l Utente Finale L utente finale diventa partecipe allo sviluppo del software Ma chi sono gli utenti? Nei software commerciali o comunque pensati per il grande pubblico, gli sviluppatori con chi dovrebbero andare a parlare? A. Martinelli Modelli di Sviluppo 28 novembre / 72

28 Il Modello a Spirale Il Rilascio del Software: le Versioni Il Deployment genera Versioni. Quando l Utente è un commissionante, o comunque una persona fisica Si usa il termine Milestone per indicare un insieme di specifiche ed una data entro cui devono essere raggiunte. Fornitore e commissionante si accordano sulle Milestone valide, e prevedono un rilascio a testimonianza di ogni Milestone. Quando l Utente è un gruppo e non c è una persona fisica a cui rivolgersi Una possibilità è pagare o coinvolgere degli utenti tipo per contribuire allo sviluppo. L avvento di internet ha tuttavia stravolto il modo in cui certi progetti vengono seguiti. I Deployement vengono fatti in rete. Gli utenti possono contribuire attraverso sistemi con chat e dibattiti in rete. A. Martinelli Modelli di Sviluppo 28 novembre / 72

29 Il Modello a Spirale Il Rilascio del Software: Tipologie di Rilascio La pratica di rilasciare versioni in rete ha contribuito alla nascita di una terminologia per la classificazione dei rilasci: Pre-Alpha Una versione Pre-Alpha è una versione esemplificativa delle funzionalità che il programma potrebbe avere. Alpha Una versione Alpha è una versione del programma non completa, ma con alcune cose funzionanti Beta Una versione Beta è una versione di Test. Le versioni Beta dovrebbero avere tutte o quasi tutte le funzionalità già implementate. Versione Candidata per il rilascio (talvolta Gamma o Delta) Una Versione che si suppone essere definitiva. E tuttavia noto che questi termini sono spesso usati in modo approssimativo. A. Martinelli Modelli di Sviluppo 28 novembre / 72

30 Il Modello a Spirale Il Problema delle Licenze (Copyright) (cenni)... la diffusione in rete del software ha anche contribuito ad alimentare il dibattito sul problema dei Diritti Legali correlati al software I Diritti sul Software Il software viene legalmente considerato come Bene Intellettuale. L Autore è proprietario di qualsiasi diritto ed è suo diritto decidere chi è come L insieme di regole fornite dall Autore è detto licenza (copyright). In Teoria ognuno potrebbe scriversi la propria licenza In Pratica esistono delle Licenze preconfezionate ed è consigliabile fare sempre affidamente ad una di esse. A. Martinelli Modelli di Sviluppo 28 novembre / 72

31 Il Modello a Spirale Il Problema del Copyright : le licenze Open (cenni) CopyLeft Nel Mondo delle Licenze stanno assumendo una rilevanza sempre più grande le Licenze Open Source, che rilasciano. Il Software Open si è diffuso soprattutto grazie alla possibilità di rilasciare in rete il codice Sorgente. L idea del Software Open è quella di consentire a chiunque di personalizzare un prodotto software esistente. Licenza GNU GPL (General Public License) Consente a chiunque di modificare il codice sorgente di un programma, ma obbliga a rilasciare le versioni modificate con licenza GNU GPL. Licenza GNU LGPL (Lesser General Public License) Consente a chiunque di modificare il codice sorgente di un programma, e non da obblighi sui rilasci. A. Martinelli Modelli di Sviluppo 28 novembre / 72

32 Il Modello a Spirale La Validazione mediante i Test La Validazione del Codice La Validazione del Codice è l insieme di attività che vengono svolte per verificare la validatà del codice. Alcune tipologie di attività specifiche della Validazione: Test Porzioni di codice dedicate alla verifica di alcune caratteristiche di un sistema. Il Test deve consentire di definire con chiarezza se la funzionalità sta operando correttamente. Test Unitari Test dedicati alla verifica specifica del funzionamento di un componente. Test Automatici Gruppi di Test che vengono validati in automatico, riducendo di molto il tempo di validazione. Debugging Attività di rimozione degli errori dal codice. A. Martinelli Modelli di Sviluppo 28 novembre / 72

33 Test Driven Development Il Test Driven Development Test Driven Development (TDD) Il TDD è il processo di Sviluppo del Software che usa i Test come strumento di Pianificazione e Sviluppo. I Test si realizzano prima di ogni altra cosa Il TDD: Si Basa sull identificazione/valutazione/invenzione di casi pratici di utilizzo di un sistema per capire come deve essere realizzato. Aiuta la pianificazione ad oggetti, perchè dato un modulo consente di scrivere immediatamente codice che descrive come dovrà essere utilizzato Consente agli sviluppatori di riflettere sulle funzionalità prima ancora di implementarle Gli sviluppatori testano più di frequente e scoprono i problemi in anticipo; questo rende più semplice la risoluzione dei problemi. Nei contesti in cui questo è possibile, fa un forte utilizzo di Test Automatici e dei Test Unitari A. Martinelli Modelli di Sviluppo 28 novembre / 72

34 Test Driven Development Nota sui metodi di Test Test Driven Development, Testing Unitario e Testing Automatico sono tre tecniche di Testing distinte, ognuna con un obiettivo specifico: Test Driven Development: fornisce una solida guida alla progettazione del codice basata su esempi. Testing Unitario: spezza i test in test piccoli, in modo che sia più facile individuare l anello debole della catena. Testing Automatico: rende molto più veloce la verifica/validazione dei test (ed è apprezzabile nel caso di test unitari). Data l importanza di tutti e tre i contributi, di solito le 3 tecniche di testing vengono combinate tra di loro, ma questo è a discrezione del team di sviluppo e può dipendere dalla tipologia di progetti presi in considerazione. A. Martinelli Modelli di Sviluppo 28 novembre / 72

35 Test Driven Development Test Driven Development: Esempio di Test Unitario 1 Test dell Area di un Rettangolo public class TestRect{ Rect rect=new Rect (); public void testarea (){ } } rect. setwidth (10); rect. setheight (20); assertequals (200, rect. getarea ()); Questo test è : Unitario : perché esiste un metodo di test specifico per testare il metodo getarea, all interno della classe TestRect che contiene tutti i test dei metodi di Rect Automatico : perché verifica in automatico se la condizione di validità del test. A. Martinelli Modelli di Sviluppo 28 novembre / 72

36 Test Driven Development Test Driven Development: Esempio di Test Unitario 2 Test su un Gioco che gestisce un Labirinto... public void connect( int room1, int room2, String move){//todo } public void setplayerroom( int room){//todo }... public void testmove(){ LabGame g=new LabGame (); g. connect(4,5, E ); g. setplayerroom (4); g. east (); asssertequals (5,g. getplayerroom ()); } I metodi di un modulo vengono progettati mediante i test, e posso essere aggiunti nel modulo in via temporanea con implementazioni parziali ed incomplete. Il vantaggio del Test Driven Development è quello di mettere in luce dall inizio il comportamento che dovranno avere i moduli, nel senso che si chiarisce da subito come si intende usarli. A. Martinelli Modelli di Sviluppo 28 novembre / 72

37 Debugging Bug e Debugging Bug Il termine Bug (Baco in italiano) sta ad indicare un problema o un errore in un programma. E ragionevolmente errato definire bug un errore di compilazione. I bug sono unicamente errori comportamentali che si possono riscontrare esclusivamente a run-time. Il Debugging può essere visto come l insieme di attività che servono a rimuovere i Bug dal Codice: Il Debugging richiede esperienza: i Bug si trovano più facilmente quando rientrano in una categoria di problemi noti e che si verificano di frequente. Esistono tuttavia alcune tecniche e strumenti utili che vengono in aiuto quando il programmatore non è in grado di identificare i problemi sulla base della propria esperienza. Nota importante L Attività di Debugging è una della attività più costose in termini di tempo ed energie che un qualsiasi progetto software debba affrontare. A. Martinelli Modelli di Sviluppo 28 novembre / 72

38 Debugging Tecniche di Debugging : Circoscrivere il problema La Circoscrizione del Problema è uno degli aspetti più critici del Debugging. Spesso infatti, l errore si trova in una o poche righe di codice ed i Sintomi sono tutt altro che Chiari. L Esperienza può aiutare a definire i punti del codice che possono essere causa di un problema più alla svelta. Tuttavia, spesso: E indispensabile conoscere la struttura del programma, la documentazione può venire in aiuto. E necessario utilizzare delle tecniche che consentano di andare a caccia dell errore. A. Martinelli Modelli di Sviluppo 28 novembre / 72

39 Debugging Tecniche di Debugging : Logging Il Logging è il meccanismo di Debugging più semplice ed in molti casi il più efficace. Consiste nello stampare dei messaggi utili attraverso strumenti di stampa come: Stampa sullo stream di Output: printf o System.out Stampa sullo stream di Errore: System.err Stampa su Strumenti di Log specifici della piattaforma Stampa su File Vantaggi: Si tiene traccia dell ordine con cui certi eventi si verificano o con cui sono fatte certe chiamate.... ma i messaggi devono essere riportati in modo sincrono. NOTA Lo Stream di output e di errore sono stream separati. Quando stampati sulla stessa console, i messaggi non sono necessariamente sincronizzati. A. Martinelli Modelli di Sviluppo 28 novembre / 72

40 Debugging Tecniche di Debugging : Debugging ad Eccezioni La Gestione delle Eccezioni è di per sé un Elemento fondamentale per il Debugging. Fornisce uno strumento per il trattamento di casi eccezionali che possono essere rilevati in modo più accurato. (In Java) fornisce l elenco delle chiamate che hanno generato il problema. (In Eclipse) consente di arrivare immediatamente alla righe di codice che hanno generato il problema con un click. Un Uso Pratico La gestione delle Eccezioni può essere sfruttata per capire la causa di un problema, quando è chiaro che il problema è dovuto ad un passaggio di dati errato. L uso delle RunTimeException può essere sfruttato per costringere il programma a stampare la traccia delle chiamate che generano un problema noto all interno di un metodo. A. Martinelli Modelli di Sviluppo 28 novembre / 72

41 Debugging Modalità di Debugging Molti programmi di CASE come Eclipse sono forniti di una modalità di Debugging: Durante la modalità di Debugging, l esecuzione del Codice viene monitorata. Il programmatore è in grado di recuperare informazioni aggiuntive e di controllare il flusso del programma. Caratteristiche della modalità di Debugging: Consente di ottenere informazioni molto precise e dettagliate con facilità. Richiede tuttavia di aver già capito dove si trova il problema. Un Consiglio La Modalità di Debugging rallenta l esecuzione, e andrebbe usata solo una volta che il problema è stato significativamente circoscritto. A. Martinelli Modelli di Sviluppo 28 novembre / 72

42 Debugging Elementi ed Operazioni tipiche della Modalità di Debugging BreakPoint Un BreakPoint è un punto del codice in cui si vuole mettere in pausa (sospendere) l esecuzione del programma. Definito il BreakPoint e lanciato il programma, la Modalità di Debugging fermerà l esecuzione non appena raggiunto il BreakPoint. E possibile rilanciare il programma fino al BreakPoint successivo. Step by Step I Debugger consentono varie tipologie di modalità a Step (Passi), che consentono di eseguire il codice riga per riga; un pulsante di controllo consente di passare alla riga successiva. Solitamente, è più utile usarla dopo un BreakPoint che dall inizio del programma. Monitoring delle Variabili I Debugger sono muniti di pannelli che elencano le variabili utilizzate all interno di un metodo ed i loro valori. Questi pannelli giocano un ruolo fondamentale nel documentare lo stato della situazione quando si arriva ad un BreakPoint o nei passi di una esecuzione a Step. A. Martinelli Modelli di Sviluppo 28 novembre / 72

43 Refactoring Il Refactoring Il Refactoring è una attività il cui obiettivo è quello di migliorare la qualità del codice senza alterarne le funzionalità. Il refactoring contempla operazioni come: La scrittura di nuovi metodi La scrittura di nuove classi e la frammentazione di classi preesitenti. L introduzione di interfacce e di relazioni di ereditarietà. La ridenominazione di alcuni attributi, metodi, variabili. Lo spostamento di attributi e metodi da una classe ad un altra. L introduzione di Design Pattern Solitamente questi interventi si effettuano con l intento di realizzare codice di programmazione modulare, molto spesso nel rispetto dei principi SOLID. Code Smell Un Code Smell è un difetto specifico del codice. I Code Smell sono strumenti molto importanti in fase di Refactoring, perché: più semplici da identificare precisi nell indicare le operazioni di refactoring risolutive. A. Martinelli Modelli di Sviluppo 28 novembre / 72

44 Refactoring I Code Smell Si riportano solo alcuni Code Smell molto significativi. Codice Duplicato Blocchi di codice duplicato o parzialmente duplicato in più punti del codice. Cause: Copia e Incolla Soluzioni L Estrazione di Metodo, cioè la generazione di un metodo contenente il codice duplicato. Metodi Troppo Lunghi Un metodo è molto lungo, e quindi di difficile lettura. Una linea guida da considerare è che un metodo è lungo se supera le 10 righe di codice (anche se ovviamente non è vero in generale). Soluzioni L Estrazione di Metodo, cioè la generazione di uno o più metodi contentente parte del codice del metodo lungo. A. Martinelli Modelli di Sviluppo 28 novembre / 72