Mappa degli OORP Tests: Your Life Insurance Detailed Model Capture Initial Understanding First Contact Setting Direction M...
Detailed Model Capture Tie Code and Questions Refactor to Understand Step through the Execution Look for the Contracts Lea...
Tie Code and Questions <ul><li>Scopo:  Appuntare  domande  e  risposte,  riguardanti le attività di reingegnerizzazione, s...
Tie Code and Questions (1) <ul><li>Due modalità per commentare il codice: </li></ul><ul><li>1. Comment-Based Annotations: ...
Tie Code and Questions (1) <ul><li>ABAP/4 – Migrazione da SAP BI a SAP BI-IP </li></ul>
Tie Code and Questions (2) <ul><li>Note:  </li></ul><ul><li>-   Registrare i  commenti  più  vicino  possibile  al codice ...
Tie Code and Questions (3) <ul><li>Pro: </li></ul><ul><li>Sincronizzazione Naturale </li></ul><ul><li>Migliora la comunica...
Tie Code and Questions (4) <ul><li>Difficoltà: </li></ul><ul><li>Individuare la giusta  granularità  delle  informazioni :...
Tie Code and Questions (5) <ul><li>Utilità:  Questo pattern torna utile in quanto riduce l’effort speso per mantenere sinc...
Refactor to Understand <ul><li>Scopo:  Fare refactoring del sistema in modo iterativo al fine di convalidare e verificare ...
Refactor to Understand (1) <ul><li>Note: </li></ul><ul><li>Tenere sempre in considerazione che l’obiettivo è capire il fun...
Refactor to Understand (2) <ul><li>Azioni di refactoring: </li></ul><ul><li>Rinominare   attributi ,  metodi  e  classi  r...
Refactor to Understand (3) <ul><li>Pro: </li></ul><ul><li>Apprendimento design : non solo si apprende il funzionamento del...
Refactor to Understand (4) <ul><li>Difficoltà: </li></ul><ul><li>Il  refactoring manuale  risulta rischioso e tedioso, per...
Refactor to Understand (5) <ul><li>Patterns Correlati: </li></ul><ul><li>Refactor to Understand lavora bene con  Tie code ...
Step through the Execution <ul><li>Scopo:  Capire come gli oggetti collaborano tra loro; </li></ul><ul><li>Problema:  Come...
Step through the Execution(1) <ul><li>Note:  </li></ul><ul><li>Essendo questa attività time-consuming è indispensabile foc...
Step through the Execution(2) <ul><li>Pro:  </li></ul><ul><li>Vista Realistica: Si ottiene un quadro preciso di come lo sc...
Step through the Execution(3) <ul><li>Difficoltà: </li></ul><ul><li>Dipendenza con i tools:  è necessario utilizzare un bu...
Look for the Contracts <ul><li>Scopo:  </li></ul><ul><li>Dedurre l’uso corretto di una interfaccia studiano il modo in cui...
Look for the Contracts (2) <ul><li>Note: </li></ul><ul><li>Guardare i  metodi chiave ; </li></ul><ul><li>Guardare le  cons...
Look for the Contracts (3) <ul><li>Pro: </li></ul><ul><li>Ci si può fidare più del codice sorgente che della documentazion...
Learn from the Past <ul><li>Scopo:  Confrontare le diverse versione del software per studiare la sua evoluzione </li></ul>...
Learn from the Past (2) <ul><li>Note: </li></ul><ul><li>L’obiettivo è capire  come il sistema è evoluto  e quali parti son...
Learn from the Past (3) <ul><li>Pro:  </li></ul><ul><li>Si concentra su artefatti importanti del design perché i cambiamen...
Learn from the Past (3) <ul><li>Difficoltà: </li></ul><ul><li>Difficoltà nel ricostruire il processo di cambiamento di un ...
Conclusioni <ul><li>Questo cluster di pattern insieme con l’initial Understanding permette di pianificare le attività di R...
Upcoming SlideShare
Loading in …5
×

Detailed Model Capture

364 views
276 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
364
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Detailed Model Capture

  1. 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. 2. Detailed Model Capture Tie Code and Questions Refactor to Understand Step through the Execution Look for the Contracts Learn from the Past
  3. 3. Tie Code and Questions <ul><li>Scopo: Appuntare domande e risposte, riguardanti le attività di reingegnerizzazione, sincronizzate con il codice memorizzandole direttamente nel file di origine. </li></ul><ul><li>Problema: Come tenere traccia delle informazioni apprese del sistema? </li></ul><ul><li>Soluzione: commentare il codice in modo diretto e immediato </li></ul>
  4. 4. Tie Code and Questions (1) <ul><li>Due modalità per commentare il codice: </li></ul><ul><li>1. Comment-Based Annotations: </li></ul><ul><li>2. Method-Based Annotations: </li></ul><ul><li>Dichiarando un metodo globale che ha come argomento una stringa e il corpo vuoto. </li></ul>
  5. 5. Tie Code and Questions (1) <ul><li>ABAP/4 – Migrazione da SAP BI a SAP BI-IP </li></ul>
  6. 6. Tie Code and Questions (2) <ul><li>Note: </li></ul><ul><li>- Registrare i commenti più vicino possibile al codice a cui si riferiscono; </li></ul><ul><li>- Le annotazioni possono essere domande, ipotesi, liste todo, elenchi o semplici osservazioni ; </li></ul><ul><li>- Utilizzare convenzioni per le annotazioni, specificando “ chi” (#by:) ha scritto il commento, “ per chi ”(#to:) e “ quando” (#on:); </li></ul><ul><li>- Se si conosce la risposta ad una domanda posta tramite annotazione è indispesabile aggiornare immediatamente i commenti fornendo una risposta corretta </li></ul><ul><li>- Per migliorare la leggibilità è buona pratica utilizzare sempre la stessa lingua per i commenti. </li></ul>
  7. 7. Tie Code and Questions (3) <ul><li>Pro: </li></ul><ul><li>Sincronizzazione Naturale </li></ul><ul><li>Migliora la comunicazione del Team </li></ul><ul><li>Minimizza Descrizione di Contesto </li></ul><ul><li>Contro: </li></ul><ul><li>Non esiste una notifica automatica </li></ul><ul><li>Va contro i principi dei team gerarchici </li></ul>
  8. 8. Tie Code and Questions (4) <ul><li>Difficoltà: </li></ul><ul><li>Individuare la giusta granularità delle informazioni : non bisogna essere troppo concisi o troppo prolissi; </li></ul><ul><li>Motivare il programmatore a scrivere commenti : il programmatore non ama scrivere commenti e/o documentazione; </li></ul><ul><li>Fornire risposte di qualità ai commenti; </li></ul><ul><li>Eliminare le annotazioni : per farlo si possono utilizzare tools che filtrano i commenti. </li></ul>
  9. 9. Tie Code and Questions (5) <ul><li>Utilità: Questo pattern torna utile in quanto riduce l’effort speso per mantenere sincronizzati documentazione e codice sorgente. </li></ul><ul><li>Patterns Correlati: </li></ul><ul><li>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 </li></ul>Tie Code and Questions Refactor to Understand
  10. 10. Refactor to Understand <ul><li>Scopo: Fare refactoring del sistema in modo iterativo al fine di convalidare e verificare la conoscenza che abbiamo del sistema. </li></ul><ul><li>Problema: Come faccio a decifrare codice criptato? </li></ul><ul><li>Soluzione: Facendo refactoring fino a quando non ha più senso </li></ul>
  11. 11. Refactor to Understand (1) <ul><li>Note: </li></ul><ul><li>Tenere sempre in considerazione che l’obiettivo è capire il funzionamento del sistema e non migliorare il codice; </li></ul><ul><li>Lavorare su una copia del codice; </li></ul><ul><li>Compilare spesso il codice dopo il refactoring o se disponibile eseguire i test per verificarne la correttezza dopo le modifiche. </li></ul>Tie Code and Questions Refactor to Understand Write Tests to Understand
  12. 12. Refactor to Understand (2) <ul><li>Azioni di refactoring: </li></ul><ul><li>Rinominare attributi , metodi e classi rendendo le etichette pienamente significative; </li></ul><ul><li>Rimuovere codice duplicato ; </li></ul><ul><li>Modificare il corpo di metodi in modo da ottenere un consistente livello di astrazione . </li></ul>
  13. 13. Refactor to Understand (3) <ul><li>Pro: </li></ul><ul><li>Apprendimento design : non solo si apprende il funzionamento del sistema ma anche la struttura del codice </li></ul><ul><li>Validazione Incrementale : un refactoring iterativo aiuta a validare il sistema in modo incrementale </li></ul><ul><li>Contro: </li></ul><ul><li>Rischio di introdurre errori nel codice </li></ul>
  14. 14. Refactor to Understand (4) <ul><li>Difficoltà: </li></ul><ul><li>Il refactoring manuale risulta rischioso e tedioso, per questo è indispensabile il supporto di un tool per il refactoring; automatizzato ad esempio Refactoring Browser ; </li></ul><ul><li>Accettare i cambiamenti : non sempre le organizzazioni accettano i cambiamenti individuati per il refactoring. </li></ul><ul><li>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. </li></ul>
  15. 15. Refactor to Understand (5) <ul><li>Patterns Correlati: </li></ul><ul><li>Refactor to Understand lavora bene con Tie code and Questions perché le annotazioni possono suggerire azioni di refactoring. </li></ul><ul><li>Altro pattern correlato è Write Test to Understand ; infatti risulta indispensabile una convalida frequente del codice modificato </li></ul>
  16. 16. Step through the Execution <ul><li>Scopo: Capire come gli oggetti collaborano tra loro; </li></ul><ul><li>Problema: Come capire quali oggetti sono istanziati al run-time e come questi collaborano? </li></ul><ul><li>Soluzione: Eseguire scenari d’uso noti utilizzando il debbuger in modo tale da osservare quali oggetti vengono istanziati e come essi collaborano tra loro. </li></ul>
  17. 17. Step through the Execution(1) <ul><li>Note: </li></ul><ul><li>Essendo questa attività time-consuming è indispensabile focalizzare l’analisi su uno specifico aspetto del sistema che risulta difficile da comprendere; </li></ul><ul><li>Inserire Breackpoints per interrompere l’esecuzione nei punti di interesse; </li></ul><ul><li>Modificare lo stato interno di un oggetto per vedere come sono attivati percorsi di esecuzioni alternativi. </li></ul>
  18. 18. Step through the Execution(2) <ul><li>Pro: </li></ul><ul><li>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 </li></ul><ul><li>Gestisce complessità: Su piccola scala è possibile dedurre le collaborazioni, ma su grande scala l’unico modo è studiare l’execution trace. </li></ul><ul><li>Contro: </li></ul><ul><li>Scenario-Based: non è possibile applicare questo pattern all’intero sistema ma solo a singoli scenari in quanto è un’attività time-consuming </li></ul><ul><li>Ristretta applicabilità: molte volte per motivi di concorrenza non si ha il tempo per poter effettuare quest’attività </li></ul>
  19. 19. Step through the Execution(3) <ul><li>Difficoltà: </li></ul><ul><li>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 </li></ul>
  20. 20. Look for the Contracts <ul><li>Scopo: </li></ul><ul><li>Dedurre l’uso corretto di una interfaccia studiano il modo in cui i client la utilizzano </li></ul><ul><li>Soluzione: Analizzare tutti i metodi, chiamate di metodi, costruttori, etc. </li></ul>
  21. 21. Look for the Contracts (2) <ul><li>Note: </li></ul><ul><li>Guardare i metodi chiave ; </li></ul><ul><li>Guardare le constructor calls : per capire come e quando vengono istanziati oggetti di una particolare classe (prestando attenzione ai parametri passati al costruttore) </li></ul><ul><li>Guardare i t emplate o hook method : per capire come è specializzata una classe; </li></ul><ul><li>Guardare metodi protected che sono sovrascritti da sottoclassi </li></ul><ul><li>Guardare le Super Calls </li></ul>
  22. 22. Look for the Contracts (3) <ul><li>Pro: </li></ul><ul><li>Ci si può fidare più del codice sorgente che della documentazione (molte volte non c’è allineamento tra codice e documentazione) </li></ul><ul><li>Contro: </li></ul><ul><li>Risulta difficile identificare tutte le classi che implementano una determinata interfaccia </li></ul>
  23. 23. Learn from the Past <ul><li>Scopo: Confrontare le diverse versione del software per studiare la sua evoluzione </li></ul><ul><li>Problema: Come è evoluto il sistema? E qual è la sua stabilità? </li></ul><ul><li>Soluzione: Confrontare le diverse versioni rilasciate, individuano eventuali funzionalità rimosse o aggiunte </li></ul>
  24. 24. Learn from the Past (2) <ul><li>Note: </li></ul><ul><li>L’obiettivo è capire come il sistema è evoluto e quali parti sono stabili o meno; </li></ul><ul><li>La rimozione di porzioni di software è indice di un design alterato del sistema; </li></ul><ul><li>Frequenti azioni di refactoring indicano l’instabilità del design ; </li></ul><ul><li>Azioni di refactoring seguite da un periodo di stabilità indicano stabilità del design . </li></ul>
  25. 25. Learn from the Past (3) <ul><li>Pro: </li></ul><ul><li>Si concentra su artefatti importanti del design perché i cambiamenti significativi permettono di comprendere meglio il design stesso </li></ul><ul><li>Fornisce una visione obiettiva del sistema </li></ul><ul><li>Contro: </li></ul><ul><li>Richiede notevole esperienza </li></ul><ul><li>Richiede il supporto di tool </li></ul><ul><ul><li>Strumenti per il calcolo di metriche </li></ul></ul><ul><ul><li>Strumenti di Configuration Management System </li></ul></ul><ul><ul><li>Un browser per risalire al codice </li></ul></ul>
  26. 26. Learn from the Past (3) <ul><li>Difficoltà: </li></ul><ul><li>Difficoltà nel ricostruire il processo di cambiamento di un pezzo di codice modificato molte volte; </li></ul>
  27. 27. Conclusioni <ul><li>Questo cluster di pattern insieme con l’initial Understanding permette di pianificare le attività di Reverse Engineering </li></ul>

×