UNIVERSITÀ DEGLI STUDI DI MILANO BICOCCA
Corso di Laurea Magistrale in Informatica
Corso di Evoluzione Software e Reverse Engineering
Anno Accademico 2008/2009
Design Pattern Detection Tool
Pinot
Verifica Manuale Istanze di Design
Pattern rilevate e Raffinamento
Carella Carmine
Falco Giuseppe
Faustinoni Fabrizio
Passoni Alberto
Risultati Pinot
2
Risultati verifica manuale e
raffinamento
Tabella di confronto dei risultati:
# Istanze rilevate
Verifica manuale
Raffinamento
Adapter
5
5
4
Composite
4
0
0
Visitor
1
(1)
0
Template Method
2
2
1
NOTE:
•
In verifica manuale il numero rappresenta le istanze che sono effettivamente istanze di quel DP.
•
In raffinamento è indicato il numero di istanze per le quali il raffinamento ha avuto esito positivo.
3
Design Pattern Adapter - Descrizione
Struttura del Pattern – Object Adapter
Requisiti:
1.
La classe Adapter estende
o implementa la classe
Target.
2.
L’Adapter ha al suo interno
un’istanza della classe
Adaptee.
3.
Alcuni metodi dell’Adapter
fanno invocazioni ai metodi
dell’Adaptee attraverso
l’istanza interna
dell’Adapter.
4.
Tali metodi dovranno
essere una ridefinizione dei
metodi di Target. Questi
metodi garantiscono
l’adattamento dell’Adaptee
con la nuova interfaccia.
4
Adapter – Istanza 1
Verifica Manuale (1)
• Risultati Pinot
Target
Adapter
Adaptee
CreationTool
TextAreaTool
FloatingTextArea
AbstractTool
Tool
• CreationTool: tool per creare nuove figure;
• TextAreaTool: crea figure che sono aree di testo (eventi
mouse);
•
FloatingTextArea: editor di testo;
5
Adapter – Istanza 1
Verifica Manuale (2)
• Relazioni tra le classi
6
Adapter – Istanza 1
Verifica Manuale (3)
• Analizziamo il codice delle classi:
–
TextAreaTool, estende CreationTool.
CreationTool estende AbstractTool.
AbstractTool implementa l’interfaccia Tool.
–
TextAreaTool, ha un’istanza della classe Adaptee. Quindi
la soluzione adottata per il pattern è l’Object Adapter.
7
Adapter – Istanza 1
Verifica Manuale (4)
• Analizziamo il codice delle classi:
–
TextAreaTool, ha metodi che fanno invocazioni ai metodi
dell’oggetto fTextField;
•
•
•
protected beginEdit: inizia l’editing di una figura di testo; quindi
istanzia fTextField per creare un nuovo editor e richiama i metodi
createOverlay e setBounds di FloatingTextArea.
protected endEdit: termina l’editing di una figura di testo,
mettendo l’oggetto fTextField=null e richiama il metodo
endOverlay.
public mouseDown e public mouseUp: eventi di pressione del
tasto del mouse e rilascio su un area editabile, quindi richiamano
beginEdit.
8
Adapter – Istanza 1
Verifica Manuale (5)
• Analizziamo il codice delle classi:
–
TextAreaTool, ha metodi che fanno invocazioni ai metodi
dell’oggetto fTextField;
•
public deactivate: disattiva il tool TextAreaTool, chiude l’editor
richiamando endEdit.
– I metodi mouseDown, mouseUp e deactivate
sono una ridefinizione dei metodi di CreationTool
che sono anche metodi dell’interfaccia Tool.
• L’istanza analizzata è effettivamente un
design pattern Adapter.
9
Adapter – Istanza 1
Raffinamento (1)
• Risultato BED Graph Visualizer
Istanza Riconosciuta
10
Adapter – Istanza 2
Verifica Manuale (1)
• Risultati Pinot
Target
Adapter
Adaptee
ResourceDisposabilityStrategy
ETSLADisposalStrategy
DisposalThread
• ResourceDisposabilityStrategy : interfaccia che
definisce le strategie di eliminazione delle risorse;
• ETSLADisposalStrategy : implementa una strategia di
rilascio delle risorse;
• DisposalThread: thread per la strategia
ETSLADisposalStrategy, richiamandola periodicamente. Essa
estende la classe Thread ridefinendo il metodo run.
11
Adapter – Istanza 2
Verifica Manuale (2)
• Relazioni tra le classi
12
Adapter – Istanza 2
Verifica Manuale (3)
• Analizziamo il codice delle classi:
–
–
ETSLADisposalStrategy, implementa la classe indicata
come target, ResourceDisposabilityStrategy, la quale è
l’interfaccia richiesta.
ETSLADisposalStrategy, ha un’istanza della classe
Adaptee. Quindi la soluzione adottata per il pattern è
l’Object Adapter.
13
Adapter – Istanza 2
Verifica Manuale (4)
• Analizziamo il codice delle classi:
–
ETSLADisposalStrategy, ha metodi che fanno invocazioni
ai metodi dell’oggetto disposalThread;
• protected initDisposalThread: inizializza il thread se non è stato
già fatto. Questo metodo è chiamato dal costruttore di
ETSLADisposalStrategy, quindi la creazione dell’adapter implica la
creazione di un oggetto della classe adaptee.
• public startDisposing: attiva la strategia di rilascio delle risorse.
Richiama su disposalThread il metodo start.
• public stopDisposing: disattiva la strategia e ferma il rilascio delle
risorse; richiama su disposalThread il metodo join passando un
parametro che rappresenta i millisecondi di attesa prima che il
thread venga ucciso.
14
Adapter – Istanza 2
Verifica Manuale (5)
• Analizziamo il codice delle classi:
–
ETSLADisposalStrategy, ha metodi che fanno invocazioni
ai metodi dell’oggetto disposalThread;
• public setPeriodicity: setta la periodicità con la quale il thread
(DiposalThread) chiamerà la strategia di rilascio delle risorse
(ETSLADisposalStrategy).
– I metodi startDisposing e stopDisposing sono una
ridefinizione dei metodi di
ResourceDisposabilityStrategy
• L’istanza analizzata è effettivamente un
design pattern Adapter.
15
Adapter – Istanza 2
Verifica Manuale (6)
• Note
– Sia l’adapter che l’adaptee sono definiti come classi all’interno di uno
stesso file ETSLADisposalStrategy.java.
16
Adapter – Istanza 2
Raffinamento (1)
• Risultato BED Graph Visualizer
Istanza Riconosciuta
17
Adapter – Istanza 3
Verifica Manuale
• Risultati Pinot
Target
Adapter
Adaptee
AbstractTool
PolygonTool
PolygonFigure
Tool
•
•
•
•
AbstracTool: classe astratta che implementa Tool.
Tool: Interfaccia che definisce operazioni di disegno.
PolygonTool: classe che rappresenta un poligono.
PolygonFigure: estende AbstracTool, disegna poligoni.
18
Adapter – Istanza 3
RELAZIONE TRA LE CLASSI:
19
Adapter – Istanza 3
Analizziamo il codice delle classi
• ADAPTER CLASS:
1. La classe indicata come adapter, PolygonTool estende la classe
astratta indicata come Target, AbstractTool la quale implementa
l’interfaccia Tool.
20
Adapter – Istanza 3
2. PolygonTool contiene l’attributo fPolygon di tipo PolygonFigure (
classe adaptee)
 Object Adapter.
3. I metodi deactivate, mouseDown, mouseMove, sono ridefinizione dei
metodi della Classe Target i quali richiamo i metodi della classe
adaptee (addPoint, smoothPoints, size, setPointAt).
Conclusione: Pattern verificato.
21
Adapter – Istanza 3
• Raffinamento:
Cocnlusione: Istanza riconosciuta.
22
Adapter – Istanza 4
Verifica Manuale
• Risultati Pinot
Target
Adapter
Adaptee
MDI_DrawApplication
JavaDrawApp
Animator
DrawApplication
• MDI_DrawApplication: classe che facilita la
comunicazione tra gli oggetti window.
• DrawApplication: Definisce metodi standard per
disegnare editors ( implementa DrawingEditor).
• JavaDrawApp: Classe che estende MDI_DrawApplication.
• Animator: Implementa un Thread.
23
Adapter – Istanza 4
RELAZIONE TRA LE CLASSI:
24
Adapter – Istanza 4
Analizziamo il codice delle classi
• ADAPTER CLASS:
1. La classe indicata come adapter, JavaDrawApp estende la classe astratta
indicata come Target, MDI_DrawApplication la quale estende la classe
DrawApplication che a sua volta implementa una serie di interfacce.
25
Adapter – Istanza 4
2. JavaDrawApp contiene l’attributo fAnimator di tipo Animator ( classe
adaptee)
 Object Adapter.
3. I metodi: startAnimation e endAnimation richiamano i metodi (start,
end) della classe adaptee attraverso l’oggetto fAnimator .
Conclusione: Pattern verificato.
26
Adapter – Istanza 4
• Raffinamento:
Conclusione: Istanza riconosciuta.
27
Adapter – Istanza 5
Risultati Pinot:
Target
Adapter
Adaptee
DrawApplet
JavaDrawApplet
Animator
• DrawApplet:
creare l’applet di presentazione (menù,
button, font ecc…);
• JavaDrawApplet:
estende DrawApplet e ridefinisce
metodi di DrawApplet e di Animator;
• Animator:
start-stop del thread di creazione e
visualizzazione interfaccia (estende Thread).
28
Adapter – Istanza 5
Verifica Manuale(1)
• Target - DrawApplet
29
Adapter – Istanza 5
Verifica Manuale(2)
• Adapter - JavaDrawApplet
30
Adapter – Istanza 5
Verifica Manuale(3)
• Adapter – JavaDrawApplet
adaptee.SpecificRequest()
31
Adapter – Istanza 5
Verifica Manuale(4)
• Adaptee - Animator
Conclusione:
IDENTIFICATO DESIGN PATTERN ADAPTER
MEDIANTE VERIFICA MANUALE
32
Adapter – Istanza 5
Raffinamento
• Risultato prodotto dal tool:
ADAPTER METHOD NON IDENTIFICATO: istanza non identificata
33
Design Pattern Composite Descrizione
Struttura del Pattern
34
Composite – Istanza 1 e 2
Verifica Manuale (1)
• Risultati Pinot
Component
Composite
Leaf
Istanza Composite
CompositeFigure
PertFigure
/
fPreTasks (istanza 1)
fPostTasks (istanza 2)
35
Composite – Istanza 1 e 2
Verifica Manuale (2)
• Relazioni tra le classi
36
Composite – Istanza 1 e 2
Verifica Manuale (3)
• CompositeFigure è una classe astratta che è
estesa da PertFigure.
• PertFigure ha al suo interno una lista di nome
fPreTasks (fPostTasks): contenitore di
componenti .
37
Composite – Istanza 1 e 2
Verifica Manuale (4)
• PertFigure, ha 4 metodi di gestione degli
oggetti composti: addPreTask/addPostTask e
removePreTask/removePostTask che
lavorano sulle liste fPreTasks e fPostTasks.
38
Composite – Istanza 1 e 2
Verifica Manuale (5)
•
CompositeFigure definisce alcuni metodi che vengono ridefiniti da PertFigure, MA tali metodi
non sono quelli relativi alla gestione degli oggetti composti.
39
Composite – Istanza 1 e 2
Verifica Manuale (6)
• L'istanza analizzata è un composite pattern
non al 100%, la sua implementazione non
riflette la struttura tipica del pattern per i
seguenti motivi:
– non sono state rilevate classi foglia;
– la relazione tra component e composite è ambigua: i metodi di
gestione dell'oggetto composto (addPreTask/addPostTask e
removePreTask/removePostTask) non prendono in input un
component ma il composite stesso ed inoltre tali metodi non hanno lo
stesso naming dei metodi del component, quindi non vengono
ridefiniti e sono quindi diversi dai metodi add e remove di
CompositeFigure.
40
Composite – Istanza 1 e 2
Raffinamento (1)
• Risultato BED Graph Visualizer
Istanze NON Riconosciute
41
Composite – Istanza 3
Verifica Manuale
• Risultati Pinot
Component
Composite
Storable
NodeFigure
Leaf
/
• Storable: Interfaccia candidata come Component Class.
• NodeFigure: classe che estende TextFigure e viene
identificata come la composite class del pattern.
• fConnectors: Lista di oggetti di tipo LocalConnector
presente in NodeFigure.
42
Composite – Istanza 3
RELAZIONE TRA LE CLASSI:
43
Composite – Istanza 3
Analizziamo il codice delle classi
• COMPONENT CLASS:
– Storable, espone due metodi read e write i quali, stando alla
definizione del pattern, dovrebbero essere richiamati per aggiungere,
rimuovere le componenti e quindi avere come parametro la
componente stessa ( requisito non soddisfatto ).
• COMPOSITE CLASS:
– Implementa indirettamente i metodi dell’interfaccia component.
– Presenta una lista (fConnectors), la quale contiene le componenti che
verranno aggiunte:
44
Composite – Istanza 3
- Gli elementi che vengono aggiunti alla lista,
implementano indirettamente l’interfaccia Component.
- I metodi che permettono l’aggiunta o la rimozione di una
componente dovrebbero essere i metodi (read e
write)che espone l’interfaccia component (Storable).
( requisito non soddisfatto ).
Conclusione: Pattern non verificato.
45
Composite – Istanza 3
• Raffinamento:
Conclusione: Istanza non riconosciuta.
46
Composite – Istanza 4
• Risultati Pinot :
Component
Composite
Storable
ContentProducerRegistry
Leaf
-
• Storable: la classe è un’interfaccia
• ContentProducerRegistry: la classe funge da
repository per i ContentProducer in modo gerarchico
per facilitare la ricerca
• fContentProducers: lista che contiene oggetti di
tipo ContentProducer
47
Composite – Istanza 4
• Verifica manuale
• La classe Storable è il Component e contiene i
seguenti metodi i quali devono avere in input
un oggetto di tipo Component
48
Composite – Istanza 4
• La classe ContentProducerRegistry
implementa i metodi read() e write(), ma
come nel component non ricevono in input
degli oggetti di tipo component.
• Come Leaf è stata individuata la classe
Layouter che non implementa i metodi read()
e write()
49
Composite – Istanza 4
Conclusioni : istanza non verificata
L’istanza non può essere considerata un Design Pattern
Composite perché sia il component che il composite nei
metodi read e write non hanno come input un oggetto di tipo
Storable, ma oggetti di tipo diverso.
50
Composite – Istanza 4
• Raffinamento:
Conclusioni: istanza non verificata
51
Design Pattern Visitor - Descrizione
Requisiti:
1.
La classe Visitor specifica le operazioni
di visita del Concrete Element
2.
Il Concrete Visitor implementa le
operazioni di visita
3.
La classe Element dichiara il metodo
accept
4.
La classe Concrete Element
implementa la classe Element
52
Visitor – Istanza 1
• Risultati Pinot
Visitor
Concrete Element
Storable
StorableOutput
Concrete Visitor
-
Element
-
• Storable: la classe è un’interfaccia
• StorableOutput: la classe viene usata per stampare
oggetti di tipo Storable
53
Visitor – Istanza 1
• Validazione Manuale
• Storable: la classe essendo il Visitor deve contenere
il metodo Visit
54
Visitor – Istanza 1
• Validazione Manuale
• Storable: la classe essendo il Visitor deve contenere
il metodo Visit
55
Visitor – Istanza 1
• StorableOutput: la classe deve implementare
l’Accept
56
Visitor – Istanza 1
• Pinot non ha rilevato né l’Element né il
Concrete Visitor, per cui si è dovuto andarli a
trovare nel codice
• Come Concrete Visitor è stata scelta la classe
ContentProducerRegistry, che re-implementa il
metodo write()
• Mentre per l’Element si è scelta la classe Object da
cui deriva StorableOutput
Conclusioni: istanza verificata al 70%
57
Visitor – Istanza 1
• Raffinamento:
Regola di raffinamento
Conclusione: istanza non verificata
58
Design Pattern Template Method Descrizione
Requisiti:
1.
La classe AbstractClass deve contenere
il template Method, il quale deve
invocare al suo interno i metodi primitivi.
2.
La Concrete Class deve implementare i
metodi primitivi dell’Abstract Class
59
Template Method – Istanza 1
• Risultati Pinot
Abstract Class
Concrete Class
ChangeConnectionHandle
ChangeConnectionStartHandle
• ChangeConnectionHandle: la classe viene usata
per cambiare i parametri delle connessioni
• ChangeStartConnectionHandle: la classe viene
usata per far ripartire le connessioni
60
Template Method – Istanza 1
• Validazione Manuale:
L’Abstract Class deve contenere Template e Primitive method
61
Template Method – Istanza 1
• La Concrete Class deve implementare i metodi primitivi:
Conclusione: istanza verificata
62
Template Method – Istanza 1
• Raffinamento:
Regola di raffinamento
Conclusione: istanza verificata
63
Template – Istanza 2
Risultati Pinot:
Template class
Template method
Primitive method
UndoActivity
swapConnectors
replaceConnectors
• UndoActivity: classe astratta che estende UndoableAdapter
(capire se un’attività può essere rifatta oppure no);
• swapConnectors: metodo che si occupa di dichiarare un
oggetto FigureEnumerator e creare le connessioni tra le varie
figure;
• replaceConnectors: metodo astratto di UndoActivity
implementato nella ChangeConnectionEndHendle (concrete
class)
64
Template – Istanza 2
Verifica Manuale(1)
• Template class - UndoActivity
SPECIFICA OPERAZIONI PRIMITIVE ASTRATTE
IMPLEMENTA IL TEMPLATE METHOD (invocazione delle operazioni
primitive dichiarate nell’abstract class)
65
Template – Istanza 2
Verifica Manuale(1)
• Concrete class - UndoActivity
IMPLEMENTA LE OPERAZIONI PRIMITIVE
Conclusione:
IDENTIFICATO DESIGN PATTERN TEMPLATE
METHOD MEDIANTE VERIFICA MANUALE
66
Template – Istanza 2
Raffinamento
• Risultato prodotto dal tool:
Abstract class NON rilevata (è una sottoclasse di
ChangeConnectionHendle): istanza non identificata
67