La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

KABA Refactoring di una gerarchia di classi Prof. Cortesi Agostino Università Ca Foscari – Venezia Facoltà di Scienze Matematiche, Fisiche e Naturali Corso.

Presentazioni simili


Presentazione sul tema: "KABA Refactoring di una gerarchia di classi Prof. Cortesi Agostino Università Ca Foscari – Venezia Facoltà di Scienze Matematiche, Fisiche e Naturali Corso."— Transcript della presentazione:

1 KABA Refactoring di una gerarchia di classi Prof. Cortesi Agostino Università Ca Foscari – Venezia Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea in Informatica Specialistica Analisi e Verifica dei Programmi Vettorel Roberta - Zanetti Giorgia Mestre (Venezia), 5 Maggio 2005

2 Contenuti Introduzione Introduzione KABA System (Class Analysis by Concept Analysis) KABA System (Class Analysis by Concept Analysis) Extreme Programming: un nuovo metodo di sviluppare software Extreme Programming: un nuovo metodo di sviluppare software Refactoring Refactoring Snelting/Tip: un algoritmo per il refactoring Snelting/Tip: un algoritmo per il refactoring Concept Analysis e Concept Lattices Concept Analysis e Concept Lattices Fasi principali e proprietà Fasi principali e proprietà KABA System KABA System Analisi di programmi: statica e dinamica Analisi di programmi: statica e dinamica Editor per il refactoring Editor per il refactoring Generazione di nuovo byte code Generazione di nuovo byte code Risultati ottenuti Risultati ottenuti 1/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti

3 Introduzione [1] Presentazione di KABA System KABA - KlassenAnalyse mit BegriffsAnalyse – Sistema automatico per il Refactoring di una gerarchia di classi Java (Java Class Hierarchy) rispetto al reale utilizzo di un insieme di specifici programmi (Client Programs). Utilizza per il refactoring lalgoritmo di Snelting/Tip [2000] concept lattices Applicazione più complessa/potente basata su concept lattices 4 componenti Costituito da 4 componenti: analisi statica, analisi dinamica, editor per il refactoring, tool per la trasformazione del bytecode originario Vari Client accedono a diversi aspetti della gerarchia di classi Tutte le classi contengono solo i metodi e campi che necessitano in base allo specifico funzionamento dei client 2/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti

4 Introduzione [2] Extreme Programming (XP) An agile software development methodology characterized by face- to face collaboration between developers and an on-site customer representative, limited documentation of requirements in form of user stories and rapid and frequent delivery of small increments of useful functionality. Cambiamento di mentalità nello sviluppo del software Kent Beck nel 1999 Coniato da Kent Beck nel 1999 in Daimler Chrysle è un nuovo approccio al problema dello sviluppo del software che: Affronta in maniera efficace i rapidi cambiamenti dei requisiti Codice è continuamente rivisto Test sono eseguiti in ogni momento Si lavora a stretto contatto con i membri del team e il committente Metodologia AGILE che non sacrifica la QUALITA del prodotto sviluppato e del processo utilizzato 3/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti

5 Introduzione [3] Che cosa richiede effettivamente XP? 4/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti Planning game Pianificazione dei rilasci e delle iterazioni dello sviluppo di qualsiasi progetto Software insieme con il cliente. Raccolta ed analisi di User story utili per i test di accettazione. Rilasci piccoli e progettazione Semplice Sistema va in produzione al massimo pochi mesi prima che sia completamente finito. Progettare in ogni momento per la necessità del presente. Programmazione in coppia Una persona scrive il codice e il collega farà lo stesso dal punto di vista strategico.

6 Introduzione [4] Extreme Programming (XP) Testing Pietra miliare su cui è costruito XP. Qualunque caratteristica di un programma per la quale non cè un test automatico semplicemente non esiste Scrivere i test ancora prima che la classe sia terminata Utilizzo di framework automatici (es. JUnit) Refactoring Proprietà collettiva del codice Non è un problema grazie alluso dei test e degli standard di codifica Integrazione continua Ogni poche ore o verso la fine di ogni giorno di programmazione il sistema completo deve essere integrato e verificarne il funzionamento 40 ore alla settimana di lavoro e Cliente sul posto Nessuno è capace di produrre lavoro di qualità in 60 ore alla settimana e almeno un cliente reale dovrebbe essere permanente disponibile al gruppo di progetto per rispondere a qualunque domanda dei programmatori 5/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti Lasciare il codice esistente nel più semplice stato possibile

7 Introduzione [5] Refactoring: un po di storia Il refactoring è una pratica che permette di migliorare un sistema software In generale si nota che la cosa più importante in un sistema è il DESIGN ANALISI: che cosa deve fare il sistema DESIGN: si occupa di come il sistema deve essere strutturato Chiari sintomi di cattivo design sono: RIGIDITA: le varie parti del sistema sono fortemente correlate tra loro FRAGILITA: effettuare un cambiamento porta alla rottura inattesa di parti non correlate del sistema IMMOBILITA: non e' possibile estrarre parti, e' difficile riutilizzarne dei moduli Teoricamente le fasi di un processo di sviluppo software (ANALISI, DESIGN, CODIFICA) avvengono in successione. 6/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti

8 Introduzione [6] Refactoring: la qualità del software Obiettivo primario è produrre codice di qualità Struttura a che serve questa classe? In che relazione è con questaltra? Robustezza codice che non entra in crisi nel momento in cui viene utilizzato in un contesto differente da quello del collaudo Eleganza stilistica codice deve essere interpretato non solo dalla macchina ma dalle persone che ci lavorano flessibilità Lassenza di vincoli stretti nella programmazione porta ad una flessibilità che permette un accrescimento delle funzionalità del software anche dopo la sua messa in opera Arrivano nuovi requisiti (avrei bisogno di….) Cose a cui non avevate pensato Ritardi nella consegna 7/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti …nella pratica Si modifica il codice al volo Si modifica il codice al volo Design decade Design decade

9 Introduzione [7] Il Refactoring come rimedio al caos Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. "In essence when you refactor you are improving the design of the code after it has been written." [M.Fowler,Refactoring] Insieme di tecniche che permette di invertire il processo entropico che domina la vita di un software Refactoring strutturale è necessario perché si hanno classi troppo generiche (Extract subclass) o troppo specializzate (Collapse Hierarchy). Questo tipo di Refactoring è la colonna portante del metodo di sviluppo software noto con Lightweight Design o Extreme Programming (XP) 8/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti

10 Algoritmo Snelting/Tip [1] Caratteristiche Generali Obiettivo : Refactoring di una gerarchia di classi Java rispetto ad un insieme di programmi client che la utilizzano Proprietà dellalgoritmo Analisi del reale utilizzo di una gerarchia di classi Concept Analisys Algoritmo di refactoring basato sulla Concept Analisys proposta Genera una proposta di refactoring in modo automatico (Concept Lattices) Preserva Trasformazione Preserva il comportamento iniziale (semantic-preserving) Trasforma la gerarchia rispetto al reale utilizzo di un insieme dato di client specializza Con numero ristretto di client, specializza il codice distribuzione dei membri Presenta unottima soluzione per la distribuzione dei membri alle classi Identifica Identifica metodi e campi morti Presenta due livelli di granularità: Concept Lattice originario e semplificato 9/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti

11 Algoritmo Snelting/Tip [2] Concept Analysis: definizione 10/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti Applicata in psicologia, sociologia, antropologia, medicina, biologia, linguistica, informatica, matematica e ingegneria industriale. Tecnica matematica per identificare insiemi di oggetti che hanno in comune degli attributi (Concept) organizzandoli in un reticolo di concetti (Concept Lattices) BirkhoffGanterWille Fondata da Birkhoff nel 1940 ed arricchita con Ganter e Wille nel 1982 che la trasformarono in un metodo di data analysis. Applicazioni di software engineering sono: Configuration management G. Snelting. Reengineering of configurations based on mathematical concept analysis. [1996] Debugging G. Ammons, D. Mandelin, R. Bodik, and J. R. Larus. Debugging temporal specifications with concept analysis [2003] Construction of class hierarchies G. Snelting and F. Tip. Understanding class hierarchies using concept analysis [2000]

12 Algoritmo Snelting/Tip [3] Concept Analysis: formalizzazione 11/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti Formal Concept Analysis è formata da: Insieme di oggetti Insieme di attributi Relazione o tabella booleana dove (O,A,T) (O,A,T) si definisce contesto (context) Per ogni insieme di oggetti si definisce: Per ogni insieme di attributi si definisce: Una coppia (O,A) si definisce concept se : attributi comuni oggetti comuni Massimo rettangolo (O,A) nella tabella T

13 Algoritmo Snelting/Tip [4] Concept Analysis: formalizzazione 12/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti Un concept c1=(O1,A1) è un sub-concept (o è dominato) da un concept c2=(O2,A2) se Birkhoff ha dimostrato che un insieme di concept forma un reticolo di concetti (concept lattice) Teorema fondamentale sui concept lattice Teorema fondamentale sui concept lattice [Wille] Ogni reticolo di concetti è completo. Per ogni coppia di elementi (O 1,A 1 ) e (O 2,A 2 ) è definito un unico estremo inferiore (infimum) e superiore(supremum): GLB or meet LUB or join Insieme di concept è un insieme parzialmente ordinato

14 Algoritmo Snelting/Tip [5] Concept Analysis: formalizzazione 13/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti Un elemento del reticolo c=(O,A) ha ext(c)=O e int(c)=A ed è etichettato: Connessione tra tabella e reticolo Un sub-concept contiene meno oggetti e più attributi

15 Algoritmo Snelting/Tip [6] Concept Analysis: formalizzazione 14/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti Esistono differenti viste per poter rappresentare linformazione: Tabella, Reticolo e Implicazioni Una implicazione A B può essere tradotta nella tabella copiando lintersezione delle entry delle possibili colonne in A in tutte le colonne B Per la realizzazione di un reticolo dato un contesto serve: Un algoritmo che calcola tutti i concetti Generalmente un contesto definisce un numero esponenziale di concetti Algoritmo che calcola la struttura fra i vari concetti (realizzazione del reticolo) Soluzione Algoritmo Next Concept o di Ganter

16 Algoritmo Snelting/Tip [7] Concept Analysis: esempi 15/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti Far Moon o A planet which far away has a moon intent LUB di tutti gli elementi che hanno far come intent Tabella Reticolo Implicazione

17 Algoritmo Snelting/Tip [8] Concept Analysis: algoritmo di Ganter 16/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti Migliore algoritmo formulato per la costruzione del concept lattice: Generazione di tutti i possibili concept dato un contesto finito Concept generati in modo incrementale e ordinato Funzione NEIGHBOURS per trovare i concept adiacenti successivi La complessità totale: Lattice ( (G,M,T) ) ::= c (Ø,Ø) //bottom insert (c,L) //L è un albero di ricerca loop foreach x in NEIGHBOURS (c,(G,M,T)) try x lookup(x,L) with NotFound insert(x,L) update_lower_x update_upper_c try c next_concept with NotFound exit return L

18 Algoritmo Snelting/Tip [9] Fasi principali 17/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti Raccolta di accessi ai membri Creazione di una relazione binaria (tabella) tra: Oggetti = variabili attraverso le quali si accede alle classi (riferimenti ad oggetti, oggetti reali creati a run-time, this-pointer o riferimenti a metodi delloggetto corrente) Attributi = membri della classe (metodo o campi) Applicazione dei vincoli di tipo Estrazione dal codice di vincoli di tipo per preservare il comportamento Creazione del reticolo di concetti Generazione di un reticolo (struttura gerarchica) equivalente alla relazione binaria rappresentata dalla tabella Semplificazione del reticolo di concetti Trasformazione del reticolo di concetti per renderlo effettivamente usabile

19 Algoritmo Snelting/Tip [10] Esempio utilizzato in ogni fase dellalgoritmo 18/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti Class A { int x, y, z; void f() { y = x; } Class B extends A { void f() { y++; } void g() { x++; f(); } void h() { f(); x--; } Class Client { public static void main(String[] args) { A a1 = new A(); A a2 = new A(); B b1 = new B(); B b2 = new B(); a1.x = 17; a2.x = 42; if (...) { a2 = b2; } a2.f(); b1.g(); b2.h(); }

20 Algoritmo Snelting/Tip [11] FASE 1 - Collection of member accesses 19/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti accessi ai membri Si raccolgono le informazioni sugli accessi ai membri delle classi: o mC Per tutti gli oggetti o i riferimenti ad oggetti o, si determina se o effettua un accesso ad un membro (campo o metodo) m della classe C (o, C.m) Viene generata una tabella in cui vengono registrate tutte le coppie (o, C.m) Per i metodi esiste la distinzione tra: Definizione o implementazione del metodo (def(C.m)) Dichiarazione o firma del metodo (dcl(C.m)) staticamentedinamicamente Analisi PointsTo Può essere fatto staticamente o dinamicamente: la versione statica, più costosa in termini di tempo e spazio, tiene conto di tutti i possibili oggetti a cui può puntare un riferimento a run-time (Analisi PointsTo).

21 Algoritmo Snelting/Tip [12] FASE 1 - Collection of member accesses: un esempio 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti Class A { int x, y, z; void f() { y = x; } Class B extends A { void f() { y++; } void g() { x++; f(); } void h() { f(); x--; } Class Client { public static void main(String[] args) { A a1 = new A(); // A1 A a2 = new A(); // A2 B b1 = new B(); // B1 B b2 = new B(); // B2 a1.x = 17; a2.x = 42; if (...) { a2 = b2; } a2.f(); b1.g(); b2.h(); } 20/37

22 Algoritmo Snelting/Tip [13] FASE 2 - Incorporation of Type Constraint 21/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti Obiettivo: garantire che nella nuova gerarchia (dopo il refactoring) si preservi il comportamento (semantica) …IN JAVA Se C è una classe che implementa una interfaccia I diciamo che C è sottotipo di I S<:T (PRINCIPIO DI SOSTITUTIVITA) Dati due tipi S e T con S<:T, in ogni contesto in cui sia atteso un riferimento di tipo T, possiamo usare (sostituire) un valore di tipo S. (PRINCIPIO DI SOSTITUTIVITA) Regole di type checking ASSEGNAMENTO T t= se exp ha tipo T o S con S<:T Se p è un parametro di tipo T, posso passare parametri di tipo S Se un metodo dichiara T come tipo risultato, può restituire qualunque valore di tipo S<:T Streckenbach and Gregor Snelting – Behaviour preserving refactoring with Kaba

23 Algoritmo Snelting/Tip [14] FASE 2 - Incorporation of Type Constraint 22/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti ASSIGNMENT ASSIGNMENT type(w)<:type(v) Assegnamento v=w è considerato valido se e solo se type(w)<:type(v). Parametri di una chiamata a procedura, valori di return e puntatori this relativi a metodi (assegnamento implicito) DOMINANCE/HIDE DOMINANCE/HIDE Sono necessari quando un metodo m è definito sia nella classe A che nella sottoclasse B (B<:A). Se uno o più oggetti x accedono sia al metodo in A che in B: def(B.m) < def(A.m) e dcl(B.m)< dcl(A.m). Per tutti i metodi C.m di una gerarchia si richiede che: def(C.m)< dcl(C.m) def(C.m)< dcl(C.m). Vincoli sono descritti da implicazioni e devono essere registrati nella tabella di partenza.

24 Algoritmo Snelting/Tip [15] 2) Incorporation of Type Constraint: un esempio 23/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti Esempio: def(A.f) dcl(A.f), def(B.f) dcl(B.f), def(B.g) dcl(B.g)m def(B.h) dcl(B.h) dcl(B.f) dcl(A.f) a1 A1, a2 A2 X X X X X X X X X X X X X X X X X X Si ripetono le operazioni di applicazione dei vincoli sino al raggiungimento del punto fisso

25 Algoritmo Snelting/Tip [16] FASE 3 - Generation of Concept Lattice 24/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti Generazione di un reticolo di concetti a partire dalla tabella costruita Utilizzo di metodi della Concept Analysis Caratteristiche del reticolo di concetti Un nuovo tipo (classe) per ogni variabile e una nuova classe home per ogni metodo Può essere interpretato in modo naturale come una struttura di ereditarietà Ogni elemento (NODO) rappresenta una classe sopra I campi e i metodi sopra un elemento rappresentano i membri della classe sotto Gli oggetti ed i riferimenti ad oggetti sotto un elemento avranno quella classe come nuovo tipo I campi e i metodi comuni sono collocati nelle super-classi Le interfacce sono individuate dai nodi contenenti solo firme di metodi, ma non definizioni (ereditate)

26 Algoritmo Snelting/Tip [17] FASE 3 - Generation of Concept Lattice: un esempio 25/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti Come leggere il reticolo: A1 e a1 utilizzano solo A.x a2 in più chiama a.f() (ha bisogno della dichiarazione di f() essendo un riferimento) B2 accede a tutto quello cui accede b2, e in più chiama B.f(): essendo un oggetto richiede la definizione del metodo ereditarietà multipla

27 Algoritmo Snelting/Tip [18] FASE 4 - Lattice Semplification 26/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti Il reticolo ottenuto deve essere semplificato per poter essere utilizzabile In particolare: Vengono eliminati gli elementi vuoti (classi senza membri) Vengono applicate trasformazioni per unire elementi del reticolo (ad esempio una classe con una sua sottoclasse che non contiene membri) Possono essere applicate trasformazioni per eliminare lereditarietà multipla operazione molto costosa perché richiede continui controlli sulla preservazione della semantica REGOLE DI SEMPLIFICAZIONE Se q è la sola sottoclasse di p e non ci sono istanze a q si unisce q con p Se p è la sola superclasse di q e q non contiene member si fonde p con q Se q eredita da p e p e la sola superclasse di p è TOP, p diventa una sottoclasse di p Se q eredita da p e p e questultime non sono in relazione tra loro: r diventa una nuova superclasse per p e r<:p. Se r è la sola superclasse per p si fonde r con p altrimenti si spostano tutti i member di p in r. Se q eredita da p e p (non in relazione) e non ci sono istanze di p, si fonde p con q

28 Algoritmo Snelting/Tip [19] FASE 4 - Lattice Semplification: un esempio 27/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti Ad esempio: A.z eliminato perché non è invocato da nessuno A.y non ha istanze ed è sottoclasse di a2 unione dei nodi a2 e A.y B2 e b2 hanno lo stesso membro della classe originale (metodo B.h) unione di b2 e B2

29 KABA [1] Caratteristiche generali 28/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti KABA System (Class Analysis by Concept Analysis) Implementazione dellalgoritmo Snelting/Tip Scritto in Java e analizza bytecode di gerarchie di classi Java Sistema per il refactoring di gerarchie di classi Java È stato testato solo con classi generate da javac, ma dovrebbe funzionare con tutti i compilatori (Java e non) È formato da quattro componenti: Lanalisi statica (approccio statico: garantisce la preservazione del comportamento per tutti i client considerati) Lanalisi dinamica (approccio dinamico: garantisce la preservazione del comportamento per tutte le esecuzioni dei client dato un insieme di test) Leditor per il refactoring Lo strumento di trasformazione di byte-code (KRS)

30 KABA [2] Analisi statica 29/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti Kaba dal bytecode costruisce un control-flow graph (CFG) Java bytecode è stack-oriented, ma lanalisi necessita di tutti i riferimenti alle variabili si effettua una backward analysis per ricostruire i contenuti Versione che compie unanalisi completa dei puntatori(POINTS-TO) Utilizza il metodo di Andersen Shapiro, M. and Horwitz, S Fast and accurate flow-insensitive points-to analysis. Streckenbach, M. and Snelting, G Points-to analysis for object-oriented languages. pt(o) = {O 1, O 2, …,O n } Per ogni riferimento ad oggetto o, si determina linsieme degli oggetti a cui potrebbe puntare a run-time: pt(o) = {O 1, O 2, …,O n } Se Type(o) = C e vengono acceduti i membri o.m e o.f() nella tabella vengono aggiunte le entry (o, C.m), (o, dcl(C.f())) Per ogni O di pt(o) (tale che C = StaticLookup(Type(O), f) si aggiunge lentry (O, def(C.f())) Approssimazione di tipo conservativo le entry della tabella generata da analisi dinamica sono un sotto-insieme di quelle dellanalisi statica Limitazione: lanalisi di un programma come javac richiede 2 GB di memoria

31 KABA [3] Analisi dinamica 30/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti JVM Kaffe Utilizza JVM Kaffe, il cui interprete byte-code è modificato per tracciare tutti gli accessi ai membri delle classi durante lesecuzione dei client Analizza gli accessi ai membri delle classi per un dato insieme di esecuzione di programmi (test run) Se un oggetto O accede ai membri m e f() vengono aggiunte alla tabella le entry (O, C.m) per il campo m, e per il metodo f direttamente (0,def(C.f)) Non vengono generate entry per i riferimenti Ball è stato il primo ad utilizzare il concept lattices per dynamic analysis

32 KABA [4] Editor 31/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti Elabora il reticolo di concetti e lo mostra graficamente Membri (campi e metodi) Variabili Nome della nuova classe

33 KABA [5] Editor 32/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti Fa vedere le vecchie classi con le relativa modifiche Fa vedere per ogni nuova classe i suoi membri, quelli ereditati e il codice sorgente Lutente può modificare direttamente la gerarchia; le operazioni che si possono effettuare sono: Gli attributi e gli oggetti possono essere mossi con un copia e incolla Una classe può essere divisa in due Due classi possono essere unite Possono essere automaticamente marchiate le classi che generano ereditarietà multipla Sono consentite solo le operazioni che non intaccano il comportamento!

34 KABA [7] KRS 33/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti Strumento per la trasformazione di byte-code: trasforma la versione originale in una che rispetta la nuova gerarchia Con un decompilatore, si può ottenere il nuovo codice sorgente Java La generazione di codice è compiuta nei seguenti passi: Tutti i campi ed i metodi vengono riordinati secondo la nuova gerarchia di classi Tutti i campi ed i metodi vengono riordinati secondo la nuova gerarchia di classi Tutti i nomi delle classi vengono sostituiti con i nuovi nomi (e il codice morto viene eliminato) Tutti i nomi delle classi vengono sostituiti con i nuovi nomi (e il codice morto viene eliminato) Vengono analizzati ed eventualmente modificati : i tipi delle variabili locali, i parametri dei metodi, i campi, gli operatori istanceof e new, i cast di tipo e i gestori delle eccezioni Vengono analizzati ed eventualmente modificati : i tipi delle variabili locali, i parametri dei metodi, i campi, gli operatori istanceof e new, i cast di tipo e i gestori delle eccezioni

35 KABA [8] Risultati 34/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti È utile sia per il refactoring automatico che manuale Può essere utilizzato come metrica di design: una gerarchia è stata progettata bene se il refactoring KABA non stravolge la versione originale (es. javac) Utile per scoprire member ridonanti o che possono essere spostati in classi derivate. Limiti: Collo di bottiglia: liniziale analisi dei puntatori impiega fino all80% del tempo totale di analisi La variante statica può gestire fino a LOC, mentre la variante dinamica non ha limitazioni Parecchie ore di calcolo per LOC su una workstation; con un garbage collector migliore ci si aspetta un tempo ragionevole per LOC raggruppare le classi in package Non è stata considerata lidea di raggruppare le classi in package (utili le classi di congruenza e congruenza debole nella Concept Analysis)

36 KABA [9] Risultati 35/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti KABA ha unopzione sperimentale per leliminazione del codice morto a priori: Reticolo ridotto Eliminazione di codice morto potenzialmente utile in futuro: scelta contestabile! Scopo per i prossimi due anni: produrre un tool simile per C++ Tecnica che può essere incorporata in un ambiente di sviluppo Java Tecnica che può essere incorporata in un ambiente di sviluppo Java Molti sono stati gli esempi di applicazioni Java in cui è stato utile il refactoring tramite il tool KABA: Jedit (editor di testo), 80 classi e LOC JAS (assembler di bytecode), 50 classi 5400 LOC Antlr (generatore di parser): sono stati eseguiti 84 test. I risultati della variante statica sono più grossolani della variante dinamica

37 Riferimenti [1] [1]Mirko Streckenbach, Gregor Snelting (2004) Refactoring Class Hierarchies with KABA [2] Gregor Snelting, Frank Tip Understanding Class Hierarchies using Concept Lattices [3] Gregor Snelting Concept Lattice in Software analysis [4] Karl Erich Wolff (1993) A first course in formal concept analysis [5] Christian Lindig (2002) Fast Concept Analysis [6]Thomas Ball The concept of Dynamic Analysis 36/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti

38 Riferimenti [2] EXTREME PROGRAMMING F. Acebal, M. Cueva Lovelle Un nuovo metodo di sviluppo software: extreme programming REFACTORING M.Fowler,K.Beck,J.Brant (1999) Refactoring: Improving the Design of Existing Code Andrea Gini Refactoring:la qualità del software (www.mokabyte.it)www.mokabyte.it Bruno Bossola (Java Users Group Torino) Introduzione al refactoring 37/37 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti

39 Fine 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti 5 Maggio 2005 Vettorel Roberta - Giorgia Zanetti Grazie per lattenzione


Scaricare ppt "KABA Refactoring di una gerarchia di classi Prof. Cortesi Agostino Università Ca Foscari – Venezia Facoltà di Scienze Matematiche, Fisiche e Naturali Corso."

Presentazioni simili


Annunci Google