Il documento descrive una serie di pattern per la reingegnerizzazione del software, con focus su come migliorare la comprensione e la documentazione del codice attraverso annotazioni, refactoring e analisi delle esecuzioni. Viene enfatizzata l'importanza di mantenere le annotazioni vicine al codice e di utilizzare strumenti adeguati per facilitare il processo di refactoring. Infine, si discute sull'analisi dell'evoluzione del software confrontando versioni diverse per comprendere la stabilità e le modifiche nel design.

1. Mappa degli OORP Tests: Your Life Insurance Detailed Model Capture Initial Understanding First Contact Setting Direction Migration Strategies Detecting Duplicated Code Redistribute Responsibilities Transform Conditionals to Polymorphism

2. Detailed Model Capture Tie Code and Questions Refactor to Understand Step through the Execution Look for the Contracts Learn from the Past

3. Tie Code and Questions Scopo: Appuntare domande e risposte, riguardanti le attività di reingegnerizzazione, sincronizzate con il codice memorizzandole direttamente nel file di origine. Problema: Come tenere traccia delle informazioni apprese del sistema? Soluzione: commentare il codice in modo diretto e immediato

4. Tie Code and Questions (1) Due modalità per commentare il codice: 1. Comment-Based Annotations: 2. Method-Based Annotations: Dichiarando un metodo globale che ha come argomento una stringa e il corpo vuoto.

5. Tie Code and Questions (1) ABAP/4 – Migrazione da SAP BI a SAP BI-IP

6. Tie Code and Questions (2) Note: - Registrare i commenti più vicino possibile al codice a cui si riferiscono; - Le annotazioni possono essere domande, ipotesi, liste todo, elenchi o semplici osservazioni ; - Utilizzare convenzioni per le annotazioni, specificando “ chi” (#by:) ha scritto il commento, “ per chi ”(#to:) e “ quando” (#on:); - Se si conosce la risposta ad una domanda posta tramite annotazione è indispesabile aggiornare immediatamente i commenti fornendo una risposta corretta - Per migliorare la leggibilità è buona pratica utilizzare sempre la stessa lingua per i commenti.

7. Tie Code and Questions (3) Pro: Sincronizzazione Naturale Migliora la comunicazione del Team Minimizza Descrizione di Contesto Contro: Non esiste una notifica automatica Va contro i principi dei team gerarchici

8. Tie Code and Questions (4) Difficoltà: Individuare la giusta granularità delle informazioni : non bisogna essere troppo concisi o troppo prolissi; Motivare il programmatore a scrivere commenti : il programmatore non ama scrivere commenti e/o documentazione; Fornire risposte di qualità ai commenti; Eliminare le annotazioni : per farlo si possono utilizzare tools che filtrano i commenti.

9. Tie Code and Questions (5) Utilità: Questo pattern torna utile in quanto riduce l’effort speso per mantenere sincronizzati documentazione e codice sorgente. Patterns Correlati: Le annotazioni spesso portano al refactoring del codice per questo motivo Tie Code and Questions lavora bene con il pattern Refactor to Understand . Ovviamente il refactoring può portare all’inserimento di nuove annotazioni Tie Code and Questions Refactor to Understand

10. Refactor to Understand Scopo: Fare refactoring del sistema in modo iterativo al fine di convalidare e verificare la conoscenza che abbiamo del sistema. Problema: Come faccio a decifrare codice criptato? Soluzione: Facendo refactoring fino a quando non ha più senso

11. Refactor to Understand (1) Note: Tenere sempre in considerazione che l’obiettivo è capire il funzionamento del sistema e non migliorare il codice; Lavorare su una copia del codice; Compilare spesso il codice dopo il refactoring o se disponibile eseguire i test per verificarne la correttezza dopo le modifiche. Tie Code and Questions Refactor to Understand Write Tests to Understand

12. Refactor to Understand (2) Azioni di refactoring: Rinominare attributi , metodi e classi rendendo le etichette pienamente significative; Rimuovere codice duplicato ; Modificare il corpo di metodi in modo da ottenere un consistente livello di astrazione .

13. Refactor to Understand (3) Pro: Apprendimento design : non solo si apprende il funzionamento del sistema ma anche la struttura del codice Validazione Incrementale : un refactoring iterativo aiuta a validare il sistema in modo incrementale Contro: Rischio di introdurre errori nel codice

14. Refactor to Understand (4) Difficoltà: Il refactoring manuale risulta rischioso e tedioso, per questo è indispensabile il supporto di un tool per il refactoring; automatizzato ad esempio Refactoring Browser ; Accettare i cambiamenti : non sempre le organizzazioni accettano i cambiamenti individuati per il refactoring. Quando fermarsi : bisogna essere consapevoli che lo scopo è apprendere il sistema e non migliorare il codice. L’attività finisce quando il sistema è stato compreso in tutte le sue parti.

15. Refactor to Understand (5) Patterns Correlati: Refactor to Understand lavora bene con Tie code and Questions perché le annotazioni possono suggerire azioni di refactoring. Altro pattern correlato è Write Test to Understand ; infatti risulta indispensabile una convalida frequente del codice modificato

16. Step through the Execution Scopo: Capire come gli oggetti collaborano tra loro; Problema: Come capire quali oggetti sono istanziati al run-time e come questi collaborano? Soluzione: Eseguire scenari d’uso noti utilizzando il debbuger in modo tale da osservare quali oggetti vengono istanziati e come essi collaborano tra loro.

17. Step through the Execution(1) Note: Essendo questa attività time-consuming è indispensabile focalizzare l’analisi su uno specifico aspetto del sistema che risulta difficile da comprendere; Inserire Breackpoints per interrompere l’esecuzione nei punti di interesse; Modificare lo stato interno di un oggetto per vedere come sono attivati percorsi di esecuzioni alternativi.

18. Step through the Execution(2) Pro: Vista Realistica: Si ottiene un quadro preciso di come lo scenario si svolge; Si può ispezionare lo stato interno di oggetti coinvolti; Si può verificare come gli oggetti collaborano e in quali circostanze Gestisce complessità: Su piccola scala è possibile dedurre le collaborazioni, ma su grande scala l’unico modo è studiare l’execution trace. Contro: Scenario-Based: non è possibile applicare questo pattern all’intero sistema ma solo a singoli scenari in quanto è un’attività time-consuming Ristretta applicabilità: molte volte per motivi di concorrenza non si ha il tempo per poter effettuare quest’attività

19. Step through the Execution(3) Difficoltà: Dipendenza con i tools: è necessario utilizzare un buon debugger, che consenta di aggiungere e rimuovere breakpoints dinamicamente e di visualizzare lo stato interno di un oggetto

20. Look for the Contracts Scopo: Dedurre l’uso corretto di una interfaccia studiano il modo in cui i client la utilizzano Soluzione: Analizzare tutti i metodi, chiamate di metodi, costruttori, etc.

21. Look for the Contracts (2) Note: Guardare i metodi chiave ; Guardare le constructor calls : per capire come e quando vengono istanziati oggetti di una particolare classe (prestando attenzione ai parametri passati al costruttore) Guardare i t emplate o hook method : per capire come è specializzata una classe; Guardare metodi protected che sono sovrascritti da sottoclassi Guardare le Super Calls

22. Look for the Contracts (3) Pro: Ci si può fidare più del codice sorgente che della documentazione (molte volte non c’è allineamento tra codice e documentazione) Contro: Risulta difficile identificare tutte le classi che implementano una determinata interfaccia

23. Learn from the Past Scopo: Confrontare le diverse versione del software per studiare la sua evoluzione Problema: Come è evoluto il sistema? E qual è la sua stabilità? Soluzione: Confrontare le diverse versioni rilasciate, individuano eventuali funzionalità rimosse o aggiunte

24. Learn from the Past (2) Note: L’obiettivo è capire come il sistema è evoluto e quali parti sono stabili o meno; La rimozione di porzioni di software è indice di un design alterato del sistema; Frequenti azioni di refactoring indicano l’instabilità del design ; Azioni di refactoring seguite da un periodo di stabilità indicano stabilità del design .

25. Learn from the Past (3) Pro: Si concentra su artefatti importanti del design perché i cambiamenti significativi permettono di comprendere meglio il design stesso Fornisce una visione obiettiva del sistema Contro: Richiede notevole esperienza Richiede il supporto di tool Strumenti per il calcolo di metriche Strumenti di Configuration Management System Un browser per risalire al codice

26. Learn from the Past (3) Difficoltà: Difficoltà nel ricostruire il processo di cambiamento di un pezzo di codice modificato molte volte;

27. Conclusioni Questo cluster di pattern insieme con l’initial Understanding permette di pianificare le attività di Reverse Engineering