Raffinamento

Raffinamento di Design Pattern

Gruppo:Allievi Andrea

Amer YeserCapra Pietro

Università degli Studi Milano BicoccaCorso di Reverse Engineering 2008

Pattern: SingletonIl pattern creazionale Singleton si può applicare ogni volta che nell’applicazione che si sta sviluppando ci si trova di fronte ad una classe che modella un oggetto il cui ruolo è unico, ha delle responsabilità speciali. In questo caso si fa in modo che la classe abbia una sola istanza e l’applicazione fornisca un punto di accesso globale ad essa.

DPD Tool ha rilevato nel sistema JHotDraw, 8 istanze del template Singleton

Pattern: Singleton

Metodologia applicata per riconoscere il pattern manualmente:

• Presenza di un unico costruttore privato (in fig il costruttore Singleton() );

• Presenza di una variabile che tenga traccia dello stato dell’unica istanza permessa (in fig la variabile singleton di tipo Singleton);

• Presenza di un metodo pubblico (in fig il metodo getIstance()).

Istanza 1: Analisi ManualeIstanza 1Classe analizzata: org.jhotdraw.contrib.html.ContentProducerRegistry

Istanza 1: Analisi ManualeIstanza 1Classe analizzata: org.jhotdraw.contrib.html.ContentProducerRegistry

Dall’analisi manuale del codice si nota immediatamente che il costruttore è pubblico; questo permette di fatto la incontrollata creazione di multiple istanze. Inoltre non è presente nessuna altra caratteristica del pattern Singleton. Si conclude che questa istanza non implementa il pattern Singleton.

Conclusione Analisi Manuale: La classe non implementa il pattern Singleton.

Istanza 1: RaffinamentoRegole di raffinamento utilizzate per riconoscere il pattern Singleton

Single self instance: il Singleton dichiara un’unica istanza di se stesso

Istanza 1: RaffinamentoIstanza 1Classe analizzata: org.jhotdraw.contrib.html.ContentProducerRegistry

Anche il raffinamento conferma i risultati ottenuti con l’analisi manuale, in quanto non c’è traccia della presenza del clue “Single Self Istance”

Conclusione Raffinamento: La classe non implementa il pattern Singleton.

Istanza 2: Analisi ManualeIstanza 2Classe analizzata: org.jhotdraw.framework.FigureAttributeConstant

Istanza 2: Analisi ManualeIstanza 2Classe analizzata: org.jhotdraw.framework.FigureAttributeConstant

La classe in analisi presenta due costruttori, uno pubblico ed uno privato. Vista la presenza del primo, anche in questo caso è possibile l’incontrollata creazione di istanze multiple. Probabilmente il tool viene ingannato dalla presenza del costruttore privato. Inoltre non è presente nessuna altra caratteristica del pattern Singleton. Si conclude che questa istanza non implementa il pattern Singleton.


Istanza 2: RaffinamentoIstanza 2Classe analizzata: org.jhotdraw.framework.FigureAttributeConstant

Anche il raffinamento conferma i risultati ottenuti con l’analisi manuale, in quanto non c’è traccia della presenza del clue “Single Self Istance”


Istanza 3: Analisi ManualeIstanza 3Classe analizzata: org.jhotdraw.standard.AlignCommand$Alignment

……

Istanza 3: Analisi ManualeIstanza 3Classe analizzata: org.jhotdraw.standard.AlignCommand$Alignment

Premessa: la classe AlignCommand ha al suo interno la sottoclasse Alignment.Effettivamente la sottoclasse Alignment contiene un unico costruttore privato, ma solo per permettere esclusivamente l’accesso alla classe AlignCommand. Tra l’altro quest’ultima ha la possibilità di chiamare più volte la creazione della sottoclasse Alignment. Probabilmente anche qui il tool viene ingannato dalla presenza del costruttore privato. Inoltre non è presente nessuna altra caratteristica del pattern Singleton. Si conclude che questa istanza non implementa il pattern Singleton.


Istanza 3: RaffinamentoIstanza 3Classe analizzata: org.jhotdraw.standard.AlignCommand$Alignment

Anche il raffinamento conferma i risultati ottenuti con l’analisi manuale, in quanto non c’è traccia della presenza del clue“Single Self Istance”


Istanza 4: Analisi ManualeIstanza 4Classe analizzata: org.jhotdraw.standard.FigureEnumerator

Istanza 4: Analisi ManualeIstanza 4Classe analizzata: org.jhotdraw.standard.FigureEnumerator

Come per la prima istanza, dall’analisi manuale del codice si nota immediatamente che il costruttore è pubblico; questo permette di fatto la incontrollata creazione di multiple istanze. Probabilmente il tool viene ingannato dalla presenza della variabile singletonEmptyEnumerator, che singolarmente crea un’unica istanza della classe in considerazione proprio come un singleton. Si conclude che questa istanza non implementa il pattern Singleton.


Istanza 4: RaffinamentoIstanza 4Classe analizzata: org.jhotdraw.standard.FigureEnumerator

Anche il BED Graph sembra farsi ingannare dalla presenza della variabile singletonEmptyEnumerator, segnalando la presenza del clue necessario “Single self Istance”; necessaria ma non sufficiente evidentemente.

Conclusione Raffinamento: La classe (non) implementa il pattern Singleton.

Istanza 5: Analisi ManualeIstanza 5Classe analizzata: org.jhotdraw.standard.HandleEnumerator

Istanza 5: Analisi ManualeIstanza 5Classe analizzata: org.jhotdraw.standard.HandleEnumerator

La classe è costruita in modo speculare alla classe precedente. L’analisi effettuata per l’istanza 4 è valida anche per l’istanza 5.


Istanza 5: RaffinamentoIstanza 5Classe analizzata: org.jhotdraw.standard.HandleEnumerator

Anche per la parte di raffinamento è similare a quella trattata alla istanza 4.


Singleton 6: Analisi ManualeIstanza 6Classe analizzata: org.jhotdraw.util.Clipboard

Singleton 6: Analisi ManualeIstanza 6Classe analizzata: org.jhotdraw.util.Clipboard

Dall’analisi manuale del codice si nota immediatamente che il costruttore è privato e di fatto non fa nulla; il codice messo così impedisce la creazione di istanze della classe Clipboard dall’esterno. Inoltre si vede subito un oggetto (fgClipboard) statico di tipo Clipboard. Proseguendo con l’analisi si nota un metodo statico pubblico getClipboard che non fa altro che restituire l’oggetto fgClipboard. Questo conferma la regola “Private Self Instance”.Tra l’altro nel codice è presente un commento che dice:

Conclusione Analisi Manuale: La classe implementa il pattern Singleton.

/** * A temporary replacement for a global clipboard. * It is a singleton that can be used to store and * get the contents of the clipboard. */

Singleton 6: RaffinamentoIstanza 6Classe analizzata: org.jhotdraw.util.Clipboard

Il raffinamento conferma l’analisi manuale: essendo presente il clue necessario “Single self istance” e il clue “Protected instantiation” (non necessario, ma sicuramente utile) si conclude che il pattern viene effettivamente rilevato.

Conclusione Raffinamento: La classe implementa il pattern Singleton.

Singleton 7: Analisi ManualeIstanza 7Classe analizzata: org.jhotdraw.util.CollectionsFactory

Singleton 7: Analisi ManualeIstanza 7Classe analizzata: org.jhotdraw.util.CollectionsFactory

L’analisi manuale del codice in questo caso è stata complessa. La classe è astratta, segue la regola “Single self instance”, che è la regola più importante per una classe Singleton. Il metodo pubblico “current” restituisce al chiamante la variabile statica e privata “factory”, la quale memorizza l’unica istanza della classe CollectionsFactory. La classe segue quindi anche la regola “Static e Private Self Instance”. Il problema principale è che la classe non ha il costruttore privato, fondamentale per il pattern “Singleton”, ma in questo caso non è necessario in quanto la classe è astratta e un costruttore privato impedirebbe l’ereditarietà.

Conclusione Analisi Manuale: La classe CollectionsFactory implementa il pattern Singleton

Singleton 7: RaffinamentoIstanza 7Classe analizzata: org.jhotdraw.util.CollectionsFactory

Il raffinamento conferma l’analisi manuale: essendo presente il clue necessario “Single self istance”, il pattern viene effettivamente rilevato.

Conclusione Raffinamento: La classe implementa il pattern Singleton.

Singleton 8: Analisi ManualeIstanza 8Classe analizzata: org.jhotdraw.util.Iconkit

La classe Iconkit implementa un costruttore pubblico. In questo modo da qualsiasi altra classe è possibile creare oggetti del tipo “Iconkit”. Questo fatto è in contrasto con la definizione del pattern Singleton, Il tool DpdTool riconosce erroneamente il pattern a causa della regola “Single self instance”, infatti la varibile statica “fgIconkit” contiene un riferimento ad un istanza di classe Iconkit.Il problema principale è che dal codice si legge come commento “The Iconkit is a singleton”

Non è chiaro il motivo di un commento del genere in quanto la classe non implementa il pattern Singleton a causa del costruttore pubblico.

Conclusione Analisi Manuale: La classe Iconkit non implementa il pattern Singleton

Singleton 8: RaffinamentoIstanza 8Classe analizzata: org.jhotdraw.util.Iconkit

Anche il BED Graph sembra farsi ingannare , segnalando la presenza del clue necessario “Single self Istance”; necessaria ma non sufficiente evidentemente.


Singleton: ConclusioniConcludendo, su 8 istanze di Singleton rilevate da DPD Tool, solamente 2 risultano effettivamente verificate. Il fattore di Precision di DPD Tool sul pattern Singleton risulta quindi essere:

P = tp / (tp + fp) = 2 / (2+6) = 2/8 = ¼ = 25%

Il Raffinamento automatico effettuato da BED Graph ha aiutato solo in parte a migliorare i risultati; senza basarsi sull’analisi manuale ma solo con i risultati del tool di raffinamento, avremmo confermato 5 delle 8 istanze rilevate da DPD Tool.

Nonostante sia uno dei pattern più semplici, il Singleton rappresenta un pattern difficile da ricercare con i tool automatici; proprio a causa della sua semplicità, è possibile implementarlo in molti modi (es. Enum in Java); Il problema delle varianti è quindi molto accentuato in questo pattern.

Pattern: VisitorIl pattern comportamentale Visitor permette di separare un algoritmo dalla struttura di oggetti composti a cui è applicato, in modo da poter aggiungere nuove operazioni e comportamenti senza dover modificare la struttura stessa.

Di solito il Visitor si usa quando una struttura di oggetti è costituita da molte classi con interfacce diverse ed è necessario che l'algoritmo esegua su ogni oggetto un'operazione differente a seconda dalla classe concreta dell'oggetto stesso.

Una prima analisi manuale ha confermato l’unica istanza rilevata dal tool.

Pattern: VisitorMetodologia applicata per riconoscere il pattern manualmente:

- Dopo aver identificato un’interfaccia Visitor, è necessario che nei suoi metodi ci sia un riferimento alla classe Concrete Element e viceversa (Class Relationship). I metodi dell’interfaccia Visitor sono implementati nella classe Concrete Visitor perché agiscano come desiderato sulle rispettive classi.

- Almeno un metodo (di solito chiamato accept) della classe Concrete Element deve accettare come parametro un oggetto Visitor (Visitable Class)

- Di solito la classe Concrete Element fa parte di una gerarchia di classi collegate o meno tra loro (Object Structure Child)

- Un metodo della classe Concrete Element riceve come parametro un’istanza dell’oggetto chiamante (Inheritance this parameter)

Visitor: Analisi ManualeClassi analizzate: org.jhotdraw.util.StorableOutput, org.jhotdraw.util.Storable, org.jhotdraw.figures.PolyLineFigure, …

Analisi ManualeIl pattern in questione è implementato in svariate classi. Per prima cosa è stata identificata dal DPD Tool l’interfaccia Storable come oggetto Visitor. L’interfaccia in questione segue la regola del “Cross Relationship” in quanto i suoi due metodi accettano come parametro oggetti StorableOutput. La classe StorableOutput corrisponde ad uno degli oggetti ConcreteElement in quanto eredita la classe Object, ha relazioni di dipendenza con classi che implementano l’interfaccia Storable, e accetta oggetti Storable come parametro di alcuni suoi metodi. Inoltre analizzando il metodo “writeStorable” si può notare la chiamata con parametro “this” al metodo “write” dell’interfaccia Storable. Quindi la classe StorableOutput segue anche la regola del “Inheritance this parameter”.Per trovare le classi Concrete Visitor è stata fatta una ricerca nel codice sorgente di classi che implementavano l’interfaccia Storable. Ci sono stati svariati risultati, abbiamo analizzato la classe PolyLineFigure, che fa parte di una gerarchia di classi in quanto eredita la classe AbstractFigure. La AbstractFigure implementa l’interfaccia Storable ed è quindi un oggetto ConcreteVisitor del pattern.

Visitor: Analisi ManualeClassi analizzate: org.jhotdraw.util.StorableOutput, org.jhotdraw.util.Storable, org.jhotdraw.figures.PolyLineFigure, …

Analisi ManualePolyLineFigure implementa le operazioni dichiarate da Visitor in modo che agiscono come desiderato sulle rispettive classi. Inoltre fornisce il contesto dell'algoritmo e ne mantiene in memoria lo stato. In questo caso l’algoritmo si occupa di scrivere su un file una figura formata da più linee. Analizzando il codice si può anche vedere che il programma JHotDraw potrebbe implementare un’altra istanza di visitor, in quanto la AbstractFigure implementa un metodo visit che accetta un oggetto “FigureVisitor”. L’altra istanza è implementata e non riconosciuto dal DPD Tool?

Conclusione Analisi Manuale: Un’istanza del pattern visitor è stata rilevata nelle classi StorableOutput, Storable e PolyLineFigure.

Visitor: RaffinamentoClassi analizzate: org.jhotdraw.util.StorableOutput, org.jhotdraw.util.Storable, org.jhotdraw.figures.PolyLineFigure, …

Visitor: RaffinamentoClassi analizzate: org.jhotdraw.util.StorableOutput, org.jhotdraw.util.Storable, org.jhotdraw.figures.PolyLineFigure, …

Il BED Graph ha prodotto risultati alquanto contrastanti con l’analisi manuale. Infatti non ha riconosciuto due clue necessari affinchè il codice sorgente implementi il pattern Visitor: Object Structure Child e Visitable Class.E’ possibile però che i due clue non siano inseriti nel catalogo interno che usa Bed Graph, in quanto nel file xml del catalogo non c’è traccia di essi, e l’analisi manuale ha confermato la presenza di entrambi. In questo caso il programma non è stato in grado di identificarli perché non conosce l’esistenza di essi.Sono state riconosciute molte Delegate, che sono regole molto simili in significato alla Class Relationship.

Conclusione Raffinamento: Secondo il raffinamento le classi in esame NON implementano il pattern Visitor.

Visitor: ConclusioniIl pattern visitor si è dimostrato molto difficile da rilevare e da analizzare.Infatti le specifiche del pattern (tratte dal libro di Erich Gamma) sono molto vaghe, la sua implementazione può essere molto diversa da un caso all’altro.

I risultati sono contrastanti: il DPD Tool e l’analisi manuale hanno confermato la presenza dell’unica istanza analizzata, mentre il raffinamento con il Bed Graph ha smentito la presenza del pattern. Inoltre nel codice sorgente sono presenti commenti che identificano un’altra istanza del pattern in questione nella classe FigureVisitor . La verifica manuale non è stata effettuata, ma a detta degli sviluppatori e con una prima analisi manuale la classe FigureVisitor (insieme ad altre ovviamente, come la AbstractFigure) implementa un’altra istanza del pattern NON rilevata dal DPD Tool.

Concludendo si può affermare che i tool per la ricerca e il raffinamento del pattern Vistor devono essere migliorati (anche se è alquanto difficile a causa delle specifiche non molto precise del pattern), in quanto i due strumenti utilizzati producono entrambi risultati contrastanti.

Pattern: Composite

Consente la costruzione di gerarchie di oggetti composti. Gli oggetti composti possono essere formati da oggetti singoli, oppure da altri oggetti composti. Questo pattern è utile nei casi in cui si vuole:- Rappresentare gerarchie di oggetti tutto-parte.- Essere in grado di ignorare le differenze tra oggetti singoli e oggetticomposti.

Composite: Analisi manuale

Istanza 1Classi analizzata: org.jhotdraw.standard.AbstractFigure Composite

org.jhotdraw.framework.Figure Component

Analizzando il codice manualmente è stato rilevato che la classe AbstractFigure, come supponibile, è una classe astratta e quindi mal si presta al ruolo di Composite che nel pattern dovrebbe rappresentare un effettivo oggetto composto. Risalendo nell’albero si rileva la classe CompositeFigure che invece sembra essere un Composite, probabilmente è quella che trae in inganno il tool che comunque ce la propone come prossima istanza.

Conclusione Analisi Manuale: Questa instanza non è una implementazione del pattern Composite.

Composite: Raffinamento

Istanza 1Classi analizzata: org.jhotdraw.standard.AbstractFigure Composite


Composite: Analisi manuale

Istanza 2Classi analizzata: org.jhotdraw.standard.CompositeFigure Composite


Come detto prima questa istanza presenta tutte le caratteristiche di un Composite, e contiene tutti i metodo opportuni per gestire più figure, come da esempio.

Conclusione Analisi Manuale: Questa instanza è una implementazione del pattern Composite.

Composite: Raffinamento

Istanza 2Classi analizzata: org.jhotdraw.standard.CompositeFigure Composite


Pattern: Template Method

Il “Template Method” presenta una classe (AbstractClass) che implementa la logica del processo dariutilizzare (tramite il metodo templateMethod() ), in funzione di certe operazioni(PrimitiveOperation) dichiarate in questa classe, la cui implementazione è di responsabilità dellesottoclassi (ConcreteClass).

Template Method: Analisi manuale

Istanza 1Classe analizzata: org.jhotdraw.contrib.AutoScrollHelper

La classe in questione ha il suo interno un costruttore pubblico da cui creare l’oggetto. Al suo interno vi sono una serie di metodi la cui implementazione viene demandata alle classi concrete che la estenderanno

Conclusione Analisi Manuale: La classe AutoScrollHelper implementa il pattern Template Method

Template Method: Raffinamento

Istanza 1Classe analizzata: org.jhotdraw.contrib.AutoScrollHelper

Template Method: Analisi manuale

Istanza 2Classe analizzata: org.jhotdraw.contrib.dnd.DNDHelper

La classe in questione ha il suo interno un costruttore pubblico da cui creare l’oggetto, non contiene nessun altra caratteristica di questo pattern, infatti non mette a disposizione funzioni implementabili dalle concrete class

Conclusione Analisi Manuale: La classe DNDHelper non implementa il pattern Template Method

Template Method: Raffinamento

Istanza 2Classe analizzata: org.jhotdraw.contrib.dnd.DNDHelper

Conclusioni

Raffinamento

Education

Transcript of Raffinamento