Mappa degli OORPMappa 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

Detailed Model CaptureDetailed Model Capture

Tie Code and Questions

Refactor to Understand

Step through the Execution

Look for the Contracts

Learn from the Past

Tie Code and QuestionsTie Code and QuestionsScopo: 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

Tie Code and Questions (1)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.

Tie Code and Questions (1)Tie Code and Questions (1)

ABAP/4 – Migrazione da SAP BI a SAP BI-IP

Tie Code and Questions (2)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.

Tie Code and Questions (3)Tie Code and Questions (3)Pro:1.Sincronizzazione Naturale2.Migliora la comunicazione del Team3.Minimizza Descrizione di Contesto

Contro:1.Non esiste una notifica automatica 2.Va contro i principi dei team

gerarchici

Tie Code and Questions (4)Tie Code and Questions (4)Difficoltà:

1. Individuare la giusta granularità delle informazioni: non bisogna essere troppo concisi o troppo prolissi;

2.Motivare il programmatore a scrivere commenti: il programmatore non ama scrivere commenti e/o documentazione;

3.Fornire risposte di qualità ai commenti;

4.Eliminare le annotazioni: per farlo si possono utilizzare tools che filtrano i commenti.

Tie Code and Questions (5)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

Refactor to UnderstandRefactor to UnderstandScopo: 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

Refactor to Understand (1)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 Teststo Understand

Refactor to Understand (2)Refactor to Understand (2)Azioni di refactoring:

1.Rinominare attributi, metodi e classi rendendo le etichette pienamente significative;

2.Rimuovere codice duplicato;

3.Modificare il corpo di metodi in modo da ottenere un consistente livello di astrazione.

Refactor to Understand (3)Refactor to Understand (3)Pro:1.Apprendimento design: non solo si

apprende il funzionamento del sistema ma anche la struttura del codice

2.Validazione Incrementale: un refactoring iterativo aiuta a validare il sistema in modo incrementale

Contro:1.Rischio di introdurre errori nel codice

Refactor to Understand (4)Refactor to Understand (4) Difficoltà:

1. Il refactoring manuale risulta rischioso e tedioso, per questo è indispensabile il supporto di un tool per il refactoring; automatizzato ad esempio Refactoring Browser;

2. Accettare i cambiamenti: non sempre le organizzazioni accettano i cambiamenti individuati per il refactoring.

3. 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.

Refactor to Understand (5)Refactor to Understand (5)Patterns Correlati:1.Refactor to Understand lavora

bene con Tie code and Questions perché le annotazioni possono suggerire azioni di refactoring.

2.Altro pattern correlato è Write Test to Understand; infatti risulta indispensabile una convalida frequente del codice modificato

Step through the ExecutionStep through the ExecutionScopo: 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.

Step through the Execution(1)Step through the Execution(1)Note: 1.Essendo questa attività time-consuming è

indispensabile focalizzare l’analisi su uno specifico aspetto del sistema che risulta difficile da comprendere;

2. Inserire Breackpoints per interrompere l’esecuzione nei punti di interesse;

3.Modificare lo stato interno di un oggetto per vedere come sono attivati percorsi di esecuzioni alternativi.

Step through the Execution(2)Step through the Execution(2) Pro:

1. 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

2. Gestisce complessità: Su piccola scala è possibile dedurre le collaborazioni, ma su grande scala l’unico modo è studiare l’execution trace.

Contro:

1. Scenario-Based: non è possibile applicare questo pattern all’intero sistema ma solo a singoli scenari in quanto è un’attività time-consuming

2. Ristretta applicabilità: molte volte per motivi di concorrenza non si ha il tempo per poter effettuare quest’attività

Step through the Execution(3)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

Look for the ContractsLook 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.

Look for the Contracts (2)Look for the Contracts (2)Note:1.Guardare i metodi chiave;2.Guardare le constructor calls: per capire

come e quando vengono istanziati oggetti di una particolare classe (prestando attenzione ai parametri passati al costruttore)

3.Guardare i template o hook method: per capire come è specializzata una classe;

4.Guardare metodi protected che sono sovrascritti da sottoclassi

5.Guardare le Super Calls

Look for the Contracts (3)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

Learn from the PastLearn from the PastScopo: 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

Learn from the Past (2)Learn from the Past (2)Note:1.L’obiettivo è capire come il sistema è

evoluto e quali parti sono stabili o meno;

2.La rimozione di porzioni di software è indice di un design alterato del sistema;

3.Frequenti azioni di refactoring indicano l’instabilità del design;

4.Azioni di refactoring seguite da un periodo di stabilità indicano stabilità del design.

Learn from the Past (3)Learn from the Past (3)Pro: 1.Si concentra su artefatti importanti del design

perché i cambiamenti significativi permettono di comprendere meglio il design stesso

2.Fornisce una visione obiettiva del sistema Contro: 1.Richiede notevole esperienza2.Richiede il supporto di tool

a) Strumenti per il calcolo di metricheb) Strumenti di Configuration Management

Systemc) Un browser per risalire al codice

Learn from the Past (3)Learn from the Past (3)Difficoltà:Difficoltà nel ricostruire il processo di

cambiamento di un pezzo di codice modificato molte volte;

ConclusioniConclusioniQuesto cluster di pattern insieme

con l’initial Understanding permette di pianificare le attività di Reverse Engineering