Tests:Your Life Insurance! Migration Strategies 1 Corso di Evoluzione Sistemi Software e Reverse Engineering 2008/2009 – Prof.ssa Arcelli Università degli.

Presentazione sul tema: "Tests:Your Life Insurance! Migration Strategies 1 Corso di Evoluzione Sistemi Software e Reverse Engineering 2008/2009 – Prof.ssa Arcelli Università degli."— Transcript della presentazione:

1 Tests:Your Life Insurance! Migration Strategies 1 Corso di Evoluzione Sistemi Software e Reverse Engineering 2008/2009 – Prof.ssa Arcelli Università degli Studi di Milano Bicocca – Laurea Magistrale in Informatica Carella Carmine Faustinoni Fabrizio Falco Giuseppe Passoni Alberto Object Oriented Reenginnering Pattern Riferimenti: Object Oriented Reenginnering Pattern - S.Demeyer, S.Ducasse, O.Nierstrasz, 2008.

2 Tests: Your Life Insurance! 2 Il tema principale del cluster è: lutilizzo di strategie di testing nel contesto della reingegnerizzazione per ridurre i rischi del processo di cambiamento di un sistema legacy critico per il business aziendale. N.B: le strategie di testing presentate non sono le uniche possibili, ma quelle più rilevanti nel caso di un progetto di reengineering.

3 Tests: You Life Insurance!3 Pattern che compongono il cluster e loro relazioni:

4 Write Test to Enable Evolution OBIETTIVO: proteggere il valore del legacy system attraverso un testing sistematico. PROBLEMA: minimizzare i rischi in un processo di reengineering. Modificare un legacy è rischioso per il business. Quali Rischi? – Non soddisfare lobiettivo del reengineering; (miglioramento legacy system evoluzione) – Introdurre ulteriore complessità nel sistema; – Compromettere le funzionalità critiche per il business; – Intraprendere una strada sbagliata: troppi sforzi per un task che non è quello designato; – Aumentare ulteriormente i costi di mantenimento. Tests: You Life Insurance!4

5 Problema Difficile perché: La valutazione dei cambiamenti non sempre è possibile Test non sempre è applicabile – componenti non comprese perché non documentate test progettato male – Dipendenze nascoste, destabilizzano il sistema. Problema risolvibile – Sistema in esecuzione e si determina cosa funziona e non funziona – Sono note le parti del sistema stabili e quelle soggette a cambiamenti Soluzione – Un processo di testing basato su test ben progettati. (Well-designed test) Tests: You Life Insurance!5 Write Test to Enable Evolution

6 Well-Designed test – proprietà – Automatico: test eseguiti senza intervento umano. Test pienamente automatici. – Persistente: un test, per essere automatico deve essere memorizzato. Memorizzare i dati del test, le azioni da eseguire e il risultato atteso. Documentazione del sistema; Soggetto a controllo delle versioni, come altro codice; – Ripetibile: dopo ogni implementazione di un cambiamento il test deve essere rieseguito. Data una nuova funzionalità deve esser possibile aggiungere facilmente nuovi test tra quelli esistenti (test suite). – Unit testing: i test dovrebbero essere associati a componenti software atomiche, per identificare chiaramente quali parti testano e ridurre la complessità del test. – Indipendente: minimizzare le dipendenze con gli altri test per evitare effetto a cascata. Il numero di test falliti deve essere un indicatore del numero di problemi rilevati. Tests: You Life Insurance!6

7 Vantaggi: – I test aumentano la fiducia nel sistema e favoriscono cambiamenti sicuri permettendo levoluzione. – Documenti di test come artifacts di un sistema. Descrizione del sistema sempre aggiornata, rispetto alla documentazione scritta. – Framework di supporto esistono per tutti i principali linguaggi object oriented (Smalltalk, Java C++). Svantaggi: – Allocare risorse umane per scrivere i test – I test dimostrano solo la presenza di difetti, non li risolvono. – È impossibile coprire con i test tutti gli aspetti di un sistema legacy – Test progettati male: il test viene eseguito si pensa tutto va bene, ma in realtà non sta testando il comportamento desiderato. Tests: You Life Insurance!7 Write Test to Enable Evolution

8 Difficoltà: – Troppi approcci di testing esistenti. Scelta dellapproccio più adatto. – Legacy system grandi e non documentati testing proibitivo – Management è restio nellinvestire nel testing. – Convincere gli sviluppatori ad adottare il testing: mostrare come il testing non solo velocizza lo sviluppo ma anche lattività di mantenimento – Il testing può essere un attività noiosa: utilizzo del toll di supporto più adatto. Tests: You Life Insurance!8 Write Test to Enable Evolution

9 Conclusioni: I test rappresentano una forma tangibile di fiducia nel sistema, perché permettono di verificare che il sistema sia corretto e possono essere eseguiti quando si vuole per verificarne la consistenza. I test sono la base per il reengineering. Tests: You Life Insurance!9 Tests Automatici Fiducia nel sistemaRiduzione dei rischiFiducia nei cambiamenti al sistema documentazioneEvoluzione Architetturale Attività di Mantenimento Write Test to Enable Evolution

10 Relazioni con altri pattern: – Always have a running version – Migrate system incrementally – Grow your test base incrementally – Test the interface, not the implementation Tests: You Life Insurance!10 Write Test to Enable Evolution

11 Grow Your Test Base Incrementally OBIETTIVO: bilanciare i costi e i benefici dei test, introducendoli incrementalmente solo quando necessario. Tests: You Life Insurance!11

12 Problematiche: – Progettazione dei casi di test occupa una notevole quantità di tempo quando fermarmi nel costruire casi di test? – Impossibile testare tutte le parti che compongono un legacy system data la loro grandezza e complessità – I programmatori che hanno realizzato il sw non sono più reperibili e quindi le conoscenze del legacy sono limitate. Soluzione: – Introdurre i test incrementalmente, solo per quelle parti del sistema su cui stiamo lavorando Tests: You Life Insurance!12 Grow Your Test Base Incrementally

13 Suggerimenti: – Sviluppare i casi di test nel seguente ordine: 1.Inizialmente solo per le componenti più critiche e con priorità più alta. 2.Per le nuove funzionalità create durante la fase di reengineering. 3.Per le parti che presentano bug importanti. – Se si ha una storia dei vecchi bug risolti, usare i vecchi Test bug come punto di partenza. – Testare le interfacce e non limplementazione, iniziando dalle grandi gerarchie di astrazione e, se avanza tempo, testare singolarmente le parti. Tests: You Life Insurance!13 Grow Your Test Base Incrementally

14 Vantaggi: 1.Risparmi del tempo (in quanto si sviluppano solo i test necessari). 2.Costruzione di test per le parti più critiche del sistema. 3.Agevolazione dello sviluppo di funzionalità future e del mantenimento. Svantaggi: –Errori nellindividuazione degli aspetti critici del sistema tempo e risorse sprecate. –I test possono dare troppa fiducia in quanto possono ancora nascondersi bug importanti nel codice. Tests: You Life Insurance!14 Grow Your Test Base Incrementally

15 Tests: You Life Insurance!15 1.Individuare il sottosistema da modificare (ABC) 2.Introdurre i test solo per il sottosistema ABC e per la componente B 3.Applicare i test alla nuova componente B

16 CONCLUSIONI: Una strategia di test incrementale consente di iniziare il processo di reengineering prima di aver sviluppato tutti i test. Minimo investimento di risorse nella fase di test in quanto questa fase è concentrata solo su quelle parti che si intendono modificare e non su tutto il sistema. Tests: You Life Insurance!16 Grow Your Test Base Incrementally

17 Use a testing framework OBIETTIVO: Incoraggiare gli sviluppatori a scrivere ed utilizzare i test di regressione, fornendo un framework che ne renda facile lo sviluppo, lorganizzazione e lesecuzione. PROBLEMA – Come incoraggiare il team a fare testing? Problema Difficoltoso : - i test sono noiosi da creare; - richiedono la creazione di dati ad-hoc per essere effettuati; - è difficile capire la differenza tra un test fallito ed un unexpected error. 17Tests: You Life Insurance!

18 Use a testing framework LA SOLUZIONE E FATTIBILE: - I test (la maggior parte) seguono lo stesso pattern CREAZIONE DATI DI PROVA ESECUZIONE DI ALCUNE AZIONI VERIFICA ESITO - linfrastruttura per eseguire i test è semplice QUINDI… Utilizzare un framework di testing che consenta di comporre una test suite a partire da test case specifici 18Tests: You Life Insurance!

19 Use a testing framework POSSIBILE PROBLEMA: - Non esiste un framework di test per il linguaggio che si sta utilizzando NIENTE PAURA! Combinare le informazioni che si possiedono in accordo con i seguenti principi: - Lutente fornirà casi prova utilizzabili come test e fornirà asserzioni sui risultati; - Il framework fornisce un feedback in caso di successo - insuccesso del test INDICA PRECISAMENTE IL TEST CHE E FALLITO GLI ERRORI DEVONO ESSERE COLLOCATI IN UN REPORT - Il framework consente la creazione di test suite 19Tests: You Life Insurance!

20 Use a testing framework PRO: Un framework per i test semplifica la formulazione dei test ed invoglia i programmatori ad effettuarli. CONS: La fase di test richiede impegno, disciplina e supporto;E difficoltoso convincere il team dellutilità del testing; E complicato inserire la fase di test allinterno del processo di sviluppo di un team che non lha mai considerata. 20Tests: You Life Insurance!

21 Use a testing framework ESEMPI: Junit (test framework for Java) - I test sono definiti come sottoclassi di TestCase - Utente deve definire i metodi setUp(), runTest() e tearDown() - Gli errori sono gestiti e segnalati mediante lutilizzo della classe TestResult - TestCase fornisce metodi standard come assertEquals e asserdFails - I test possono essere inseriti allinterno di una TestSuite ESISTONO FRAMEWORK DI TEST SPECIFICI PER OGNI TIPO DI LINGUAGGIO: Ada, ANT, C, C++, Delphi,.Net (all languages), Eiffel, Forte 4GL, GemStone/S, Jade, JUnit Java, JavaScript, k language (ksql, from kbd), Objective C, Open Road (CA), Oracle, PalmUnit, Perl, PhpUnit, PowerBuilder, Python, Rebol, Ruby, Smalltalk, Visual Objects and UVisual Basic. 21Tests: You Life Insurance!

22 Test the Interface, Not the Implementation OBIETTIVO: costruire test riusabili che non si focalizzino sui dettagli di implementazione, ma piuttosto su comportamenti esterni, per sopravvivere ai cambiamenti del sistema PROBLEMA: Sviluppare test che siano resistenti nel tempo ai cambiamenti della componente a cui sono legati. Problema difficile perché: mentre evolve, il legacy system deve continuare a supportare il processo di business; non si può perdere troppo tempo nella scrittura dei test; non impiegare troppe energie per scrivere test che diventeranno presto obsoleti. Tests: You Life Insurance!22

23 Problema risolvibile: – Le interfacce dei componenti dicono cosa deve esser testato – Le interfecce tendono a essere più stabili dellimplementazione. Soluzione: – Sviluppare test di tipo black-box che sfruttano le interfacce pubbliche delle componenti. – Costruire la soluzione: Come dati di test utilizzare valori estremi (minimo e massimo); Se ci sono molte componenti fine-grained utilizzare una strategia top-down per sviluppare i test; Se si sta modificando una funzionalità ben precisa utilizzare una strategia bottom-up per testarla. Tests: You Life Insurance!23 Test the Interface, Not the Implementation

24 Vantaggi: – Se limplementazione cambia è poco probabile che la sua interfaccia subisca modifiche test sullinterfaccia è più riusabile; – Black-box tests possono essere usati per più implementazioni della stessa interfaccia; – I test sulle interfacce sono più semplici da realizzare; – Evita di scrivere i test troppo presto; Svantaggi: – I Black-box test non coprono tutto il codice; – Se linterfaccia cambia, bisogna modificare il test; – La classe non fornisce la giusta interfaccia per lapplicazione del black-box test, allora altre strategie di testing (white-box testing). Tests: You Life Insurance!24 Test the Interface, Not the Implementation

25 Conclusioni: – Le interfacce di un componente, sono una conseguenza della sua interazione con altre componenti; il black-box test può essere utile nel verificare le principali interazioni di un sistema – Black-box test hanno maggiori probabilità di sopravvivere ai cambiamenti del sistema, perché le interfacce tendono ad essere più stabili. Relazioni con altri pattern: – Record business rule as tests. Tests: You Life Insurance!25 Test the Interface, Not the Implementation

26 Record Business Rules as Tests OBIETTIVO: Mantenere il sistema al passo con le regole di business da esso implementate codificandole come Test. 26Tests: You Life Insurance!

27 Record Business Rules as Tests Problematiche: La documentazione spesso non contiene i dati relativi ai piani business Regole business spesso sono implicite nel codice Il cambiamento degli sviluppatori provoca laumento dei rischi Cambiamento per fattori esterni Risoluzione problematica semplice poiché le regole business seguono delle linee guida 27Tests: You Life Insurance!

28 Record Business Rules as Tests Soluzione: Scrivere test eseguibili che registrano gli affari come casi di test. Gli sviluppatori scrivono i test funzionali I clienti scrivono i test di integrazione 28Tests: You Life Insurance!

29 Record Business Rules as Tests Vantaggi: Regole esplicite, riduzione dipendenza umana Prima di effettuare la reingegnerizzazione del legacy system si devono registrare le regole business Permette levoluzione delle regole business: aggiunta di nuove features e test di regressione per verificare la loro correttezza 29Tests: You Life Insurance!

30 Record Business Rules as Tests Svantaggi: I test codificano solo eventi concreti La logica business prevede molti casi, ma non tutti vengono trattati Registrare business rules non significa estrarre business rules. Lestrazione con la corrente tecnologia è ancora un sogno. Registrare business rules è difficile se cambia il team 30Tests: You Life Insurance!

31 Record Business Rules as Tests Conclusioni: I test sono un buon metodo per documentare ciò che il sistema fa. Documentando i business rules come test, posso garantire la descrizione di esso durante limplementazione 31Tests: You Life Insurance!

32 Write Test To Understand Obiettivo Registrazione della comprensione di parte del codice sotto forma di test eseguibili, in modo da essere utili quando si modificherà il sistema in futuro 32Tests: You Life Insurance!

33 Write Test To Understand Problematiche Codice non sempre comprensibile Ipotesi su quello che il codice fa e validazione di tali ipotesi Specificare il comportamento del sistema Documentazione obsoleta appena si cambia il codice 33Tests: You Life Insurance!

34 Write Test To Understand Soluzione Codificare ipotesi e conclusioni come test eseguibili 34Tests: You Life Insurance!

35 Write Test To Understand Vantaggi I test aiutano la comprensione I test offrono specifiche precise di certi aspetti del sistema I test sono applicati a diversi livelli di comprensione I test sviluppati aiuteranno il futuro reengineering Maggiore precisione nella creazione e uso delloggetto 35Tests: You Life Insurance!

36 Write Test To Understand Svantaggi Scrivere test comporta la perdita di tempo Oggetti testati non hanno unastrazione Non va bene per processi concorrenti 36Tests: You Life Insurance!

37 Write Test To Understand Conclusioni Per scrivere test automatici bisogna partite dal sistema preso in considerazione e capirlo Registrazione per settare il piano per una futura re- ingegnerizzazione 37Tests: You Life Insurance!

38 Migration Strategies38 Migration Strategies

39 39 Migration Strategies Introduzione Dopo i test la reingegnerizzazione è a buon punto, si ha una buona conoscenza del sistema legacy e si sono scritti i test che iniziano la fase di evoluzione. Domande Siamo sicuri che il nuovo sistema sarà accettato? Come migrare verso il nuovo sistema nonostante quello vecchio sia ancora in uso? Si può testare il nuovo sistema prima che sia pronto?

40 Migration Strategies40 Migration Strategies Punti chiave: Migrazione Big-bang rischiosa Troppe modifiche creano confusione negli utenti Feedback Gli utenti devono fare il loro lavoro, ma non vogliono essere distratti da soluzioni incomplete Data legacy devono rimanere intatti Panoramica Il reengineering non è sufficiente, bisogna introdurre la migrazione graduale verso un nuovo sistema in modo da essere indolore agli utenti.

41 Migration Strategies41 Migration Strategies

42 42 Involve The User System Obiettivo: massimizzare il numero di cambiamenti coinvolgendo l'utente a ogni step

43 Migration Strategies43 Involve The User System Problematiche: I sistemi sono vecchi. Gli utenti vogliono sapere come funziona e come aggirare i problemi. La gente odia il dover imparare qualcosa di nuovo a meno che non sia qualcosa di semplice La percezione dell'utente di ciò che è necessario per migliorare un sistema. Gli utenti possono avere difficoltà a valutare un documento di progettazione. E difficile essere entusiasti di un nuovo sistema che non è pronto per l'uso.

44 Migration Strategies44 Involve The User System Soluzione: Coinvolgere direttamente gli utenti e tenerli aggiornati sul sistema. Passi: chiedere agli utenti le priorità. dividere le priorità in fasi. utenti e sviluppatori si devono tenere in contatto. avere dei feedback sulle versioni intermedie.

45 Migration Strategies45 Involve The User System Vantaggi: I requisiti devono essere aggiornati e validati spesso, per andare verso il risultato sperato Se gli utenti hanno la sensazione d'essere utile per ottenere i risultati saranno invogliati a lasciare feedback positivi Gli utenti saranno coinvolti durante lo svolgimento del progetto, eliminando il successivo periodo di formazione

46 Migration Strategies46 Involve The User System Svantaggi: Gli sviluppatori possono avvertire gli utenti che il loro coinvolgimento può distrarre dal lavoro di reingegnerizzazione del sistema. Aumento delle aspettative e mettere pressione supplementare sul vostro team. Può essere difficile coinvolgere gli utenti Non è possibile coinvolgere tutti, e gli utenti che sono lasciati fuori potrebbero sentirsi trascurati

47 Migration Strategies47 Involve The User System Conclusioni: Si utilizzano i feedback per assicurare che si stanno affrontando le reali esigenze del cliente.

48 Migration Strategies48 Build confidence Obiettivo: aumentare le chances di avere successo attraverso risultati dimostrativi a ogni fase.

49 Migration Strategies49 Build confidence Problematiche Alcuni progetti vogliono dei requisiti e devono rientrare in un badget. Gli utenti raramente dicono ciò che realmente vogliono Difficoltà nel convincere gli utenti sui legacy system

50 Migration Strategies50 Build confidence Soluzione: creare un atmosfera positiva per dimostrare che molti risultati positivi sono ottenibili grazie a questo clima Fasi: Suddividere il lavoro in piccoli step per avere il più presto possibile un nuovo risultato

51 Migration Strategies51 Build confidence Vantaggi Utenti e sviluppatori possono vedere i reali progressi Facilità nella stima dei costi

52 Migration Strategies52 Build confidence Svantaggi sincronizzazione avere successo aumenta le aspettative lavoro extra Alcuni requisiti sono difficili da dividere. Re-ingegnerizzazione difficile Difficoltà nel convincere gli utenti e gli sviluppatori

53 Migration Strategies53 Build confidence Conclusioni lavorando a piccoli step si riducono i rischi, aumentano la confidenza e si tiene sempre traccia sul progresso del lavoro

54 Migration Strategies54 Migrate Systems Incrementally Obiettivo: Evitare la complessità e il rischio di big-bang reengineering causati dai frequenti implementazioni.

55 Migration Strategies55 Migrate Systems Incrementally Problematiche I progetti spesso sono sviluppati guardando avanti, ma questo può portare a nuove richieste Le reali richieste vengono fuori sempre dopo. Più tardi si distribuisce il sistema e più tardi arrivano i feedback Impossibile distribuire un sistema incompleto

56 Migration Strategies56 Migrate Systems Incrementally Soluzione Implementare un primo aggiornamento del sistema legacy non appena è possibile e migrazione incrementale. Passi Decomposizione del sistema legacy. Scegliere una parte da analizzare. Mettere in atto i test per la parte e le parti che dipendono da essa. Prendere le misure opportune per il wrap, la reengineer o la sostituituzione la componente. Distribuire i componenti aggiornati e ottenere un feedback.

57 Migration Strategies57 Migrate Systems Incrementally Vantaggi È possibile ottenere subito il feedback degli utenti. Si vede quello che il sistema fa alla fine di ogni fase. Gli utenti imparano questo nuovo sistema durante la sua costruzione. Il sistema è sempre implementato. Il sistema è in fase di sperimentazione, non è possibile saltare i test.

58 Migration Strategies58 Migrate Systems Incrementally Svantaggi Si dovranno impiegare risorse per mantenere il sistema in esecuzione Difficoltà nella migrazione verso una nuova architettura Rischioso cambiare un sistema che si sta ancora utilizzando

59 Migration Strategies59 Migrate Systems Incrementally Conclusioni Ottenere i feedback positivi Utenti invogliati se utilizzano molto frequentemente il sistema e non hanno problemi

60 Migration Strategies60 Prototype the Target Solution Obiettivo: valutare il rischio di migrazione verso una nuova soluzione mediante la costruzione di un prototipo.

61 Migration Strategies61 Prototype the Target Solution Problematiche: – E rischioso effettuare cambiamenti radicali su un sistema funzionante. – Difficoltà nellanalizzare limpatto dei cambiamenti del sistema con le funzionalità esistenti. Soluzione: – Sviluppare un prototipo della nuova soluzione e valutare con riguardo i nuovi requisiti.

62 Migration Strategies62 Prototype the Target Solution Suggerimenti: – Identificazione dei più grossi rischi tecnici del progetto di reengineering: Scelta di una nuova architettura. Migrazione dei dati del legacy al nuovo sistema. Decidere se implementare un prototipo esplorativo o piuttosto un prototipo evolutivo.

63 Migration Strategies63 Prototype the Target Solution – Un prototipo esplorativo sarà utile per valutare la fattibilità di una scelta tecnica. Deve essere progettato per rispondere a domande che possono riguardare: Questioni tecniche, (esempio: se la nuova piattaforma è in grado di soddisfare i limiti di prestazioni fissati dal sistema legacy), Questioni di usabilità che richiedono la partecipazione e la valutazione da parte degli utenti.

64 Migration Strategies64 Prototype the Target Solution -Un prototipo evolutivo, è destinato a, eventualmente, sostituire un componente del sistema legacy. La nuova architettura non può più solo sostenere adeguatamente i servizi del sistema legacy, ma anche superare le gli ostacoli che limitano le soluzioni del sistema. Il prototipo deve essere progettato anche per superare tali limiti.

65 Migration Strategies65 Prototype the Target Solution Vantaggi: – Un prototipo può essere costruito velocemente in quanto non deve implementare tutte le funzionalità del sistema. – E possibile tagliare parti del sistema legacy per rendere avviabile il prototipo. – Aiuta a capire se la nuova soluzione può funzionare. Svantaggi: – Gli sviluppatori non sono motivati a spendere tempo per sviluppare i prototipi.

66 Migration Strategies66 Always Have a Running Version Obiettivo: Aumentare la fiducia nei cambiamenti grazie a un regolare rebuild del sistema.

67 Migration Strategies67 Always Have a Running Version Problematiche: – Può essere difficile fare la demo di un sistema software in fase di sviluppo, o di discutere i problemi con gli utenti, poiché spesso la demo non è stabile. – LIntegrazione delle modifiche di più versioni del sistema può risultare molto complessa e lenta. Soluzione: – Instituire un processo di integrazione dei nuovi cambiamenti e sviluppi quotidianamente.

68 Migration Strategies68 Always Have a Running Version Suggerimenti: – Avere a disposizione sia un sw di gestione delle versioni che di gestione delle configurazioni. (SVN) – Assicurarsi di avere i regression test delle parti su cui si sta lavorando. – Creare un processo per controllare le componenti del sistema e che esegua i regression Test. Le iterazioni del processo devono essere più brevi possibili in modo da consentire cambiamenti che dovranno essere integrati nel sistema funzionante.

69 Migration Strategies69 Always Have a Running Version Vantaggi: – Si ha sempre una versione funzionante che può essere usata come demo. – Si ha sempre una versione funzionante su cui avviare i regression test. – Si possono validare velocemente le modifiche al sistema. Svantaggi: – Bisogna integrare sempre e continuamente le modifiche.

70 Migration Strategies70 Regression Test After Every Change Obiettivo: Aumentare la confidenza essendo sicuri che quello che funzionava prima funzioni ancora.

71 Migration Strategies71 Regression Test After Every Change Problematiche: – In un sistema complesso, anche piccoli cambiamenti possono avere effetti collaterali, imprevisti. Un cambiamento apparentemente innocuo può creare enormi bug, senza che essi vengano immediatamente scoperti. Soluzione: – Eseguire il test suite ogni volta si pensi di aver raggiunto uno stato stabile del sistema

72 Migration Strategies72 Regression Test After Every Change Vantaggi: – E più facile che costruirsi ogni volta una versione funzionante. Svantaggi: – E necessario scrivere i test. – I sistemi legacy non dispongono di adeguati regression test. Ci si dovrà aiutare con Grow Your Test Base Incrementally

73 Migration Strategies73 Regression Test After Every Change Conclusioni: – Regression Test After Every Change garantisce che quello che funzionava prima funziona ancora. – Se si costruiscono costantemente i test, oltre che scoprire i vari difetti del software, si otterrà una suite test riusabile che aumenterà la fiducia nelle modifiche fatte.

74 Migration Strategies74 Make a Bridge to the New Town OBIETTIVO: Migrare i dati dal legacy system al nuovo sistema, in parallelo mentre sono entrambi in esecuzione con un bridge tra i due. PROBLEMA: Come migrare in modo incrementale i dati dal legacy system al nuovo sistema mentre entrambi sono in funzione ? Problema difficile perché: Alcune componenti del legacy system potrebbero essere in fase di sostituzione; La sostituzione di componenti critiche è molto rischiosa; Durante la migrazione, i dati utilizzati da un legacy devono essere disponibili;

75 Migration Strategies75 Soluzione: costruire un data bridge per trasferire incrementalmente i dati dal legacy system al nuovo sistema, in modo automatico quando le nuove componenti richiedono i dati dalle rispettive componenti del legacy. Come costruire la soluzione: Identificare le componenti del legacy system e del nuovo sistema che gestiscono gli stessi dati; Implementare un data bridge: – Invisibile al nuovo sistema; – Responsabile per qualunque conversione di dati; – Ridireziona le richieste di lettura dal nuovo componente al legacy, se i dati non sono già migrati. Modificare la componente del legacy per ridirezionare le richieste di scrittura alla nuova componente in modo che i nuovi dati siano aggiornati; Quando tutti i dati sono stati trasferiti rimuovere il bridge e il componente legacy. Make a Bridge to the New Town

76 Migration Strategies76 Make a Bridge to the New Town Data Store New System Component Data Bridge Legacy System Component 1: read Richiesta di scrittura dallesterno (utente o altro sistema). Richiesta di lettura dal nuovo componente. 1.1: read 1.2: write 3: external write 3.1: external write 3.2: external write

77 Migration Strategies77 Vantaggi: Iniziare ad utilizzare il nuovo sistema senza aver terminato la fase di migrazione dei legacy data. Svantaggi: Senza lesistenza di un mapping chiaro tra i legacy data e i dati del nuovo sistema, è difficile implementare un bridge Una volta che il trasferimento è avvenuto è difficile tornare indietro Aumento del overhead generale causato dal bridge Conclusione Un bridge tra il vecchio e il nuovo sistema permette agli utenti di iniziare ad utilizzare il nuovo sistema prima che sia completo; il bridge isola i due sistemi architettura del nuovo sistema non è influenzata dal legacy system. Relazioni con altri pattern: Migrate your system incrementally Make a Bridge to the New Town

78 Migration Strategies78 Present the Right Interface PROBLEMA Durante il processo di migrazione, il nuovo sistema come accederà ai servizi del legacy system ? Problema difficile perché: Il nuovo sistema non è ancora completo deve utilizzare i servizi del legacy; Il legacy non ha le giuste interfacce necessarie al nuovo sistema. Problema risolvibile Non bisogna accedere ai servizi del legacy direttamente.

79 Migration Strategies79 Soluzione Identificare le astrazioni (interfacce) per il nuovo sistema e usare dei wrapper per il vecchio sistema in modo da emulare le nuove astrazioni. Esempio: libreria grafica in linguaggio procedurale da utilizzare in un sistema object-oriented. – Troppo costoso reimplementarla nellottica object-oriented. – Soluzione 1: libreria come una classe utility (static) – Soluzione 2: creare un modulo wrapper che presenta la giusta interfaccia object-oriented. Vantaggi Separare il nuovo sistema dai servizi del legacy system fin dallinizio usando le giuste astrazioni; Ridurre il rischio che la nuova architettura venga influenzata dalla vecchia. Present the Right Interface

80 Migration Strategies80 Svantaggi: Le nuove interfacce potrebbero non essere stabili. Sbagliare nel creare le giuste astrazioni (wrappare codice procedurale come utility class) Conclusione Introduce un nuova e più adatta interfaccia per le componenti del legacy system. Scegliere la giusta interfaccia non costringe a pensare in termini di design del legacy system e permette di considerare approcci alternativi. Relazioni con altri pattern Deprecate Obsolete Interfaces Distinguish Public from Published Interface Present the Right Interface

81 Migration Strategies81 Distinguish Public from Published Interface OBIETTIVO Facilitare lo sviluppo parallelo, distinguendo interfacce published instabili da interfacce public stabili. PROBLEMA Come permettere la migrazione da interfacce del legacy a interfacce del nuovo sistema mentre queste ultime sono ancora in fase di sviluppo ? Problema difficile perché Migrazione al nuovo sistema il più presto possibile; Non congelare le interfacce delle componenti del nuovo sistema troppo presto; Cambiare le interfacce a un componente che è largamente usato può rallentare lo sviluppo; Problema risolvibile Lo stato delle interfacce può essere controllato.

82 Migration Strategies82 Soluzione Fare una distinzione tra le interfacce – Public: identificano componenti pronte per essere utilizzate dal resto del sistema; – Published: identificano componenti che sono ancora instabili per essere utilizzati in modo definitivo dallintero sistema, ma posso essere utilizzabili da un sottosistema. Come costruire la soluzione Le interfacce published non sono supportate dai linguaggi di programmazione utilizzare strategie alternative (convenzione sui nomi): – JAVA: dichiararle come protected public quando diventano stabili; – C++: dichiarale public o protected e inoltre dichiarare friends le componenti che possono utilizzarle public quando diventano stabili e rimuovere la dichiarazione friends. Distinguish Public from Published Interface

83 Migration Strategies83 Vantaggi: I client che utilizzano interfacce published sono consapevoli che saranno modificate. Svantaggi: Trasformare uninterfaccia da published a public comporta un overhead per i client che dovrebbero aggiornarsi alla nuova interfaccia; Dubbio: un client dovrebbe usare interfacce non stabili o i servizi del legacy system ? Conclusioni Quando si crea una nuova interfaccia (Present the right interface), questa potrebbe non essere stabile, allora bisogna distinguere tra interfacce published e public. Quando le interfacce diventano stabili vengono definite public e quelle obsolete eliminate. Distinguish Public from Published Interface

84 Migration Strategies84 Deprecate Obsolete Interfaces OBIETTIVO: Lasciare agli utenti il tempo di reagire ai cambiamenti delle public interface etichettando quelle obsolete come deprecate. PROBLEMA – Come modificare uninterfaccia evitando di spiazzare tutti gli utenti? Problema Difficoltoso : - potrebbe provocare perdita di utenti (DA UN LATO); - lasciare uninterfaccia obsoleta causa problemi di manutenzione futura (DALLALTRO LATO); - non tutti i cambiamenti sono proficui.

85 Migration Strategies85 Deprecate Obsolete Interfaces LA SOLUZIONE E FATTIBILE: - Linterfaccia vecchia e quella che la deve sostituire possono coesistere per un periodo di tempo. QUINDI… Etichettare la vecchia ed obsoleta interfaccia come deprecata così da segnalare allutente che verrà certamente rimossa e sostituita da una migliore nella prossima release.

86 Migration Strategies86 Deprecate Obsolete Interfaces SOLUZIONE: - Implementare la nuova interfaccia e deprecare quella vecchia; - Deprecare = informare i clienti che linterfaccia subirà modifiche atte al miglioramento; - Valutare per quanto la vecchia interfaccia debba essere usata e se si possa già eliminare in una prossima release. NOTA: In Java, il meccanismo di deprecazione è una funzionalità: aggiungendo @deprecate nel javadoc si effettua loperazione citata, inoltre anche il compilatore genera warning se il codice è compilato con lopzione -deprecate.

87 Migration Strategies87 Deprecate Obsolete Interfaces ALTRO APPROCCIO: - Informare gli utenti della deprecazione di interfacce inserendo ciò nella documentazione; - Spostare o rinominare il componente deprecato. I clienti possono continuare ad utilizzare tale componente ma devono adattarsi a compilarlo ogni volta; - Rimpiazzare i componenti deprecati con componenti identici ma che in più generano warning.

88 Migration Strategies88 Deprecate Obsolete Interfaces PRO: Gli utenti non devono abituarsi istantaneamente ai cambiamenti; Cè il tempo di adattare la mente ai cambiamenti. CONS: Gli utenti sono liberi di ignorare la deprecazione. DIFFICOLTA: E difficile rintracciare tutti gli utenti che utilizzano un determinato componente deprecato; E difficile capire quando deprecare un componente. BENEFICI: La deprecazione impone ai progettisti di effettuare una valutazione sullimpatto dei cambiamenti che si vogliono introdurre.

89 Migration Strategies89 Conserve Familiarity OBIETTIVO: Evitare cambiamenti radicali che potrebbero alienare lutente. PROBLEMA – Come effettuare una revisione accurata di un sistema legacy senza interrompere il modo di operare degli utenti che lo utilizzano per compiere il loro lavoro? Problema Difficoltoso : - I sistemi legacy prevedono cambiamenti importanti; - Gli utenti non sono soddisfatti dei sistemi legacy ma li capiscono bene.

90 Migration Strategies90 Conserve Familiarity LA SOLUZIONE E FATTIBILE: - E possibile effettuare una migrazione incrementale verso una nuova e migliore soluzione. QUINDI… Introdurre solo una costante, cioè un basso numero di cambiamenti tra una release e la successiva.

91 Migration Strategies91 Conserve Familiarity PRO: Ogni release non impone dei cambiamenti significativi e drastici dei modi di lavoro degli utenti (è tutto graduale). DIFFICOLTA: Qualche volta sono necessari dei drastici e radicali cambiamenti. CONCETTO CHIAVE: Troppi cambiamenti tra le release incrementano il rischio di difetti e decrementano la capacità di adattarsi degli utenti.

92 Migration Strategies92 Use Profiler Before Optimizing OBIETTIVO: Evitare sforzi di reengineering relativi allottimizzazione ed alla verifica della presenza di colli di bottiglia. PROBLEMA – Quando di deve effettivamente riscrivere una porzione di codice che è evidentemente inefficiente? Problema Difficoltoso : - nella reingegnerizzazione del software si possono trovare molti algoritmi semplici ed ingenui nel codice legacy; - può essere difficile prevederne limpatto sulle performance e si può perdere tanto tempo nel fare supposizioni; - il codice ottimizzato è sempre più complicato.

93 Migration Strategies93 Use Profiler Before Optimizing LA SOLUZIONE E FATTIBILE: - Esistono tool che individuano dove potrebbero esserci dei problemi di performance. SOLUZIONE: Prima di ottimizzare una parte di sistema che è chiaramente inefficiente si deve utilizzare un profiler che esprime se essa è un potenziale collo di bottiglia. Non ottimizzare nulla fino ad un riscontro (positivo) da parte del profiler. Qualora si decidesse di proseguire, creare dei banchmark che dimostrano i guadagni di prestazione.

94 Migration Strategies94 Use Profiler Before Optimizing PRO: Nessuno spreco di tempo nellottimizzazione delle parti che non producono significativi miglioramenti di performance. CONS: Gli algoritmi ingenui sopravvivono comunque a lungo nel sistema. NOTAZIONI: Il miglioramento delle performance di una porzione di codice dipende da quanto tempo il programma rimane in run su quella porzione (questa informazione è data dal profiler).