Università Ca’ Foscari – Venezia
Facoltà di Scienze Matematiche, Fisiche e Naturali
Corso di Laurea in Informatica Specialistica
Analisi e Verifica dei Programmi
Prof. Cortesi Agostino
KABA
Refactoring di una gerarchia di classi
Vettorel Roberta - Zanetti Giorgia
Mestre (Venezia), 5 Maggio 2005
Contenuti




Introduzione

KABA System (Class Analysis by Concept Analysis)

Extreme Programming: un nuovo metodo di sviluppare software

Refactoring
Snelting/Tip: un algoritmo per il refactoring

Concept Analysis e Concept Lattices

Fasi principali e proprietà
KABA System

Analisi di programmi: statica e dinamica

Editor per il refactoring

Generazione di nuovo byte code
Risultati ottenuti
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
1/37
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).
 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

Utilizza per il refactoring l’algoritmo di Snelting/Tip [2000]


Applicazione più complessa/potente basata su concept lattices
Costituito da 4 componenti: analisi statica, analisi dinamica, editor
per il refactoring, tool per la trasformazione del bytecode originario
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
2/37
Introduzione
[2]
Extreme Programming (XP)
“An “agile” software development methodology characterized by faceto 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

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
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
3/37
Introduzione
[3]
Che cosa richiede effettivamente XP?
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.
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
4/37
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
Lasciare il codice esistente nel più semplice stato possibile
Proprietà collettiva del codice
Non è un problema grazie all’uso 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 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
5/37
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.
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
6/37
Introduzione
[6]
Refactoring: la qualità del software


Obiettivo primario è produrre codice di qualità

Struttura
a che serve questa classe? In che relazione è con quest’altra?

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
L’assenza di vincoli stretti nella programmazione porta ad una flessibilità
che permette un accrescimento delle funzionalità del software anche
dopo la sua messa in opera
…nella pratica
Arrivano nuovi requisiti (“avrei bisogno di….”)
Cose a cui non avevate pensato
Ritardi nella consegna
5 Maggio 2005
Si modifica il codice al volo
Design decade
Vettorel Roberta - Giorgia Zanetti
7/37
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)
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
8/37
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à dell’algoritmo









Analisi del reale utilizzo di una gerarchia di classi
Algoritmo di refactoring basato sulla Concept Analisys
Genera una proposta di refactoring in modo automatico (Concept Lattices)
Trasformazione Preserva il comportamento iniziale (semantic-preserving)
Trasforma la gerarchia rispetto al reale utilizzo di un insieme dato di client
Con numero ristretto di client, specializza il codice
Presenta un’ottima soluzione per la distribuzione dei membri alle classi
Identifica metodi e campi “morti”
Presenta due livelli di granularità: Concept Lattice originario e semplificato
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
9/37
Algoritmo Snelting/Tip
[2]
Concept Analysis: definizione

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)

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]
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
10/37
Algoritmo Snelting/Tip
[3]
Concept Analysis: formalizzazione

Formal Concept Analysis è formata da:





Insieme di oggetti
Insieme di attributi
Relazione o tabella booleana dove
(O,A,T) si definisce contesto (context)
Per ogni insieme di oggetti
si definisce:
attributi comuni

Per ogni insieme di attributi
si definisce:
oggetti comuni

Una coppia (O,A) si definisce concept se :
Massimo rettangolo (O,A) nella tabella T
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
11/37
Algoritmo Snelting/Tip
[4]
Concept Analysis: formalizzazione

Un concept c1=(O1,A1) è un sub-concept (o è dominato) da un concept
c2=(O2,A2) se
Insieme di concept è un
insieme parzialmente
ordinato

Birkhoff ha dimostrato che un insieme di concept forma un reticolo di
concetti (concept lattice)
Teorema fondamentale sui concept lattice [Wille]
Ogni reticolo di concetti è completo.

Per ogni coppia di elementi (O1,A1) e (O2,A2) è definito un unico estremo
inferiore (infimum) e superiore(supremum):
GLB or meet
LUB or join
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
12/37
Algoritmo Snelting/Tip
[5]
Concept Analysis: formalizzazione

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
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
13/37
Algoritmo Snelting/Tip
[6]
Concept Analysis: formalizzazione

Esistono differenti viste per poter rappresentare l’informazione:

Tabella, Reticolo e Implicazioni
Una implicazione A  B può essere tradotta nella tabella copiando
l’intersezione 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
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
14/37
Algoritmo Snelting/Tip
[7]
Concept Analysis: esempi
Tabella
Reticolo
LUB di tutti
gli elementi
che hanno far
come intent
FarMoon o A planet which far away has a moon
Implicazione
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
15/37
Algoritmo Snelting/Tip
[8]
Concept Analysis: algoritmo di Ganter

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
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
16/37
Algoritmo Snelting/Tip
[9]
Fasi principali

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 dell’oggetto
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
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
17/37
Algoritmo Snelting/Tip
[10]
Esempio utilizzato in ogni fase dell’algoritmo
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--;
}
}
5 Maggio 2005
Class Client {
public static
main(String[]
A a1 = new
A a2 = new
B b1 = new
B b2 = new
void
args) {
A();
A();
B();
B();
a1.x = 17;
a2.x = 42;
if (...) { a2 = b2; }
a2.f();
b1.g();
b2.h();
}
}
Vettorel Roberta - Giorgia Zanetti
18/37
Algoritmo Snelting/Tip
[11]
FASE 1 - Collection of member accesses

Si raccolgono le informazioni sugli accessi ai membri delle classi:
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

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))
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).
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
19/37
Algoritmo Snelting/Tip
[12]
FASE 1 - Collection of member accesses: un esempio
Class A {
int x, y, z;
void f() {
y = x;
}
}
Class Client {
public static
main(String[]
A a1 = new
A a2 = new
B b1 = new
B b2 = new
Class B extends A {
void f() {
y++;
}
void g() {
x++;
f();
}
void h() {
}
f();
x--;
}
}
void
args) {
A(); //
A(); //
B(); //
B(); //
A1
A2
B1
B2
a1.x = 17;
a2.x = 42;
if (...) { a2 = b2; }
a2.f();
b1.g();
b2.h();
}
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
20/37
Algoritmo Snelting/Tip
[13]
FASE 2 - Incorporation of Type Constraint

Obiettivo: garantire che nella nuova gerarchia (dopo il refactoring) si
preservi il comportamento (semantica)
Streckenbach and Gregor Snelting – Behaviour preserving refactoring with Kaba
…IN JAVA
Se C è una classe che implementa una interfaccia I diciamo che C è sottotipo di I

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=<exp> 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

5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
21/37
Algoritmo Snelting/Tip
[14]
FASE 2 - Incorporation of Type Constraint

ASSIGNMENT
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
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).

Vincoli sono descritti da implicazioni e devono essere registrati nella
tabella di partenza.
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
22/37
Algoritmo Snelting/Tip
[15]
2) Incorporation of Type Constraint: un esempio
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
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)
Si ripetono le operazioni di

a1A1, a2A2
applicazione dei vincoli sino al
raggiungimento del punto fisso
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
23/37
Algoritmo Snelting/Tip
[16]
FASE 3 - Generation of Concept Lattice


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
I campi e i metodi sopra un elemento rappresentano i membri della classe
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)
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
24/37
Algoritmo Snelting/Tip
[17]
FASE 3 - Generation of Concept Lattice: un esempio
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
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
25/37
Algoritmo Snelting/Tip
[18]
FASE 4 - Lattice Semplification


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 l’ereditarietà
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 quest’ultime 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
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
26/37
Algoritmo Snelting/Tip
[19]
FASE 4 - Lattice Semplification: un esempio
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
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
27/37
KABA
[1]
Caratteristiche generali

KABA System (Class Analysis by Concept Analysis)

Implementazione dell’algoritmo 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:


L’analisi statica (approccio statico: garantisce la preservazione del comportamento
per tutti i client considerati)
L’analisi dinamica (approccio dinamico: garantisce la preservazione del
comportamento per tutte le esecuzioni dei client dato un insieme di test)

L’editor per il refactoring

Lo strumento di trasformazione di byte-code (KRS)
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
28/37
KABA
[2]
Analisi statica

Kaba dal bytecode costruisce un control-flow graph (CFG)

Java bytecode è stack-oriented, ma l’analisi necessita di tutti i riferimenti alle
variabili  si effettua una backward analysis per ricostruire i contenuti

Versione che compie un’analisi completa dei puntatori(POINTS-TO)

Utilizza il metodo di Andersen
Shapiro, M. and Horwitz, S. 1997. Fast and accurate flow-insensitive points-to analysis.
Streckenbach, M. and Snelting, G. 2000. Points-to analysis for object-oriented languages.




Per ogni riferimento ad oggetto o, si determina l’insieme degli oggetti a cui
potrebbe puntare a run-time:
pt(o) = {O1, O2, …,On}
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 l’entry (O,
def(C.f()))
Approssimazione di tipo conservativo  le entry della tabella generata da analisi
dinamica sono un sotto-insieme di quelle dell’analisi statica
Limitazione: l’analisi di un programma come javac richiede 2 GB di memoria
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
29/37
KABA
[3]
Analisi dinamica

Utilizza JVM Kaffe, il cui interprete byte-code è modificato per tracciare tutti gli
accessi ai membri delle classi durante l’esecuzione 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
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
30/37
KABA
[4]
Editor

Elabora il reticolo di concetti e lo mostra graficamente
Membri (campi e metodi)
Nome della nuova classe
Variabili
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
31/37
KABA
[5]
Editor

Fa vedere le vecchie classi con le relativa modifiche

Fa vedere per ogni nuova classe i suoi membri, quelli ereditati e il codice
sorgente

L’utente 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!
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
32/37
KABA
[7]
KRS

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 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
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
33/37
KABA
[8]
Risultati

È 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: l’iniziale analisi dei puntatori impiega fino all’80% del tempo totale
di analisi

La variante statica può gestire fino a 30.000 LOC, mentre la variante dinamica non
ha limitazioni

Parecchie ore di calcolo per 20.000 LOC su una workstation; con un garbage
collector migliore ci si aspetta un tempo ragionevole per 50.000 LOC

Non è stata considerata l’idea di raggruppare le classi in package (utili le classi di
congruenza e congruenza debole nella Concept Analysis)
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
34/37
KABA
[9]
Risultati

KABA ha un’opzione sperimentale per l’eliminazione 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
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 12.000 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
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
35/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
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
36/37
Riferimenti
[2]
EXTREME PROGRAMMING


F. Acebal, M. Cueva Lovelle
Un nuovo metodo di sviluppo software: extreme programming
http://www.extremeprogramming.org
REFACTORING




M.Fowler,K.Beck,J.Brant (1999)
Refactoring: Improving the Design of Existing Code
http://www.refactoring.com
Andrea Gini
Refactoring:la qualità del software (www.mokabyte.it)
Bruno Bossola (Java Users Group Torino)
Introduzione al refactoring
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti
37/37
Fine
Grazie per l’attenzione
5 Maggio 2005
Vettorel Roberta - Giorgia Zanetti