detailed model capture
TRANSCRIPT
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