Raffinamento
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Raffinamento

on

  • 694 views

 

Statistics

Views

Total Views
694
Views on SlideShare
671
Embed Views
23

Actions

Likes
0
Downloads
1
Comments
0

2 Embeds 23

http://yesrema.wordpress.com 20
http://www.slideshare.net 3

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Raffinamento Presentation Transcript

  • 1. Raffinamento di Design Pattern
    Università degli Studi Milano Bicocca
    Corso di Reverse Engineering 2008
    Gruppo:
    Allievi Andrea
    AmerYeser
    Capra Pietro
  • 2. Pattern: Singleton
    Il 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
  • 3. Pattern: Singleton
    Metodologia applicata per riconoscere il pattern manualmente:
    • Presenza di un unico costruttore privato (in fig il costruttore Singleton() );
    • 4. Presenza di una variabile che tenga traccia dello stato dell’unica istanza permessa (in fig la variabile singleton di tipo Singleton);
    • 5. Presenza di un metodo pubblico (in fig il metodo getIstance()).
  • Istanza 1: Analisi Manuale
    Istanza 1
    Classe analizzata: org.jhotdraw.contrib.html.ContentProducerRegistry
  • 6. Istanza 1: Analisi Manuale
    Istanza 1
    Classe 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.
  • 7. Istanza 1: Raffinamento
    Regole di raffinamento utilizzate per riconoscere il pattern Singleton
    Single self instance: il Singleton dichiara un’unica istanza di se stesso
  • 8. Istanza 1: Raffinamento
    Istanza 1
    Classe 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 SelfIstance”
    Conclusione Raffinamento: La classe non implementa il pattern Singleton.
  • 9. Istanza 2: Analisi Manuale
    Istanza 2
    Classe analizzata: org.jhotdraw.framework.FigureAttributeConstant
  • 10. Istanza 2: Analisi Manuale
    Istanza 2
    Classe 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.
    Conclusione Analisi Manuale: La classe non implementa il pattern Singleton.
  • 11. Istanza 2: Raffinamento
    Istanza 2
    Classe 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 SelfIstance”
    Conclusione Raffinamento: La classe non implementa il pattern Singleton.
  • 12. Istanza 3: Analisi Manuale
    Istanza 3
    Classe analizzata: org.jhotdraw.standard.AlignCommand$Alignment
    ……
  • 13. Istanza 3: Analisi Manuale
    Istanza 3
    Classe 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.
    Conclusione Analisi Manuale: La classe non implementa il pattern Singleton.
  • 14. Istanza 3: Raffinamento
    Istanza 3
    Classe 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 SelfIstance”
    Conclusione Raffinamento: La classe non implementa il pattern Singleton.
  • 15. Istanza 4: Analisi Manuale
    Istanza 4
    Classe analizzata: org.jhotdraw.standard.FigureEnumerator
  • 16. Istanza 4: Analisi Manuale
    Istanza 4
    Classe 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.
    Conclusione Analisi Manuale: La classe non implementa il pattern Singleton.
  • 17. Istanza 4: Raffinamento
    Istanza 4
    Classe 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.
  • 18. Istanza 5: Analisi Manuale
    Istanza 5
    Classe analizzata: org.jhotdraw.standard.HandleEnumerator
  • 19. Istanza 5: Analisi Manuale
    Istanza 5
    Classe 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.
    Conclusione Analisi Manuale: La classe non implementa il pattern Singleton.
  • 20. Istanza 5: Raffinamento
    Istanza 5
    Classe analizzata: org.jhotdraw.standard.HandleEnumerator
    Anche per la parte di raffinamento è similare a quella trattata alla istanza 4.
    Conclusione Raffinamento: La classe (non) implementa il pattern Singleton.
  • 21. Singleton 6: Analisi Manuale
    Istanza 6
    Classe analizzata: org.jhotdraw.util.Clipboard
  • 22. Singleton 6: Analisi Manuale
    Istanza 6
    Classe 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 SelfInstance”.
    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.
    */
  • 23. Singleton 6: Raffinamento
    Istanza 6
    Classe analizzata: org.jhotdraw.util.Clipboard
    Il raffinamento conferma l’analisi manuale: essendo presente il clue necessario “Single self istance” e il clue “Protectedinstantiation” (non necessario, ma sicuramente utile) si conclude che il pattern viene effettivamente rilevato.
    Conclusione Raffinamento: La classe implementa il pattern Singleton.
  • 24. Singleton 7: Analisi Manuale
    Istanza 7
    Classe analizzata: org.jhotdraw.util.CollectionsFactory
  • 25. Singleton 7: Analisi Manuale
    Istanza 7
    Classe 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 SelfInstance”. 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 CollectionsFactoryimplementa il pattern Singleton
  • 26. Singleton 7: Raffinamento
    Istanza 7
    Classe 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.
  • 27. Singleton 8: Analisi Manuale
    Istanza 8
    Classe 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 toolDpdTool 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 Iconkitnonimplementa il pattern Singleton
  • 28. Singleton 8: Raffinamento
    Istanza 8
    Classe 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.
    Conclusione Raffinamento: La classe (non) implementa il pattern Singleton.
  • 29. Singleton: Conclusioni
    Concludendo, 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.
  • 30. Pattern: Visitor
    Il 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.
  • 31. Pattern: Visitor
    Metodologia applicata per riconoscere il pattern manualmente:
    • Dopo aver identificato un’interfaccia Visitor, è necessario che nei suoi metodi ci sia un riferimento alla classe Concrete Elemente viceversa (ClassRelationship). I metodi dell’interfaccia Visitor sono implementati nella classe Concrete Visitor perché agiscano come desiderato sulle rispettive classi.
    • 32. Almeno un metodo (di solito chiamato accept) della classe Concrete Elementdeve accettare come parametro un oggetto Visitor (VisitableClass)
    • 33. Di solito la classe Concrete Elementfa parte di una gerarchia di classi collegate o meno tra loro (ObjectStructureChild)
    - Un metodo della classe Concrete Element riceve come parametro un’istanza dell’oggetto chiamante (Inheritancethisparameter)
  • 34. Visitor: Analisi Manuale
    Classi analizzate: org.jhotdraw.util.StorableOutput,
    org.jhotdraw.util.Storable,
    org.jhotdraw.figures.PolyLineFigure, …
    Analisi Manuale
    Il 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 ConcreteElementin 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 “Inheritancethisparameter”.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 ConcreteVisitordel pattern.
  • 35. Visitor: Analisi Manuale
    Classi analizzate: org.jhotdraw.util.StorableOutput,
    org.jhotdraw.util.Storable,
    org.jhotdraw.figures.PolyLineFigure, …
    Analisi Manuale
    PolyLineFigureimplementa 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, Storablee PolyLineFigure.
  • 36. Visitor: Raffinamento
    Classi analizzate: org.jhotdraw.util.StorableOutput,
    org.jhotdraw.util.Storable,
    org.jhotdraw.figures.PolyLineFigure, …
  • 37. Visitor: Raffinamento
    Classi 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: ObjectStructureChild e VisitableClass.
    E’ possibile però che i due clue non siano inseriti nel catalogo interno che usa BedGraph, 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 ClassRelationship.
    Conclusione Raffinamento: Secondo il raffinamento le classi in esame NON implementano il pattern Visitor.
  • 38. Visitor: Conclusioni
    Il 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 BedGraph 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.
  • 39. 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 oggetti
    composti.
  • 40. Composite: Analisi manuale
    Istanza 1
    Classi analizzata: org.jhotdraw.standard.AbstractFigure Composite
    org.jhotdraw.framework.FigureComponent
    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.
  • 41. Composite: Raffinamento
    Istanza 1
    Classi analizzata: org.jhotdraw.standard.AbstractFigure Composite
    org.jhotdraw.framework.FigureComponent
  • 42. Composite: Analisi manuale
    Istanza 2
    Classi analizzata: org.jhotdraw.standard.CompositeFigure Composite
    org.jhotdraw.framework.FigureComponent
    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.
  • 43. Composite: Raffinamento
    Istanza 2
    Classi analizzata: org.jhotdraw.standard.CompositeFigure Composite
    org.jhotdraw.framework.FigureComponent
  • 44. Pattern: TemplateMethod
    Il “TemplateMethod” presenta una classe (AbstractClass) che implementa la logica del processo da
    riutilizzare (tramite il metodotemplateMethod() ), in funzione di certe operazioni
    (PrimitiveOperation) dichiarate in questa classe, la cui implementazione è di responsabilità delle
    sottoclassi (ConcreteClass).
  • 45. TemplateMethod: Analisi manuale
    Istanza 1
    Classe 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 AutoScrollHelperimplementa il pattern TemplateMethod
  • 46. TemplateMethod: Raffinamento
    Istanza 1
    Classe analizzata: org.jhotdraw.contrib.AutoScrollHelper
  • 47. TemplateMethod: Analisi manuale
    Istanza 2
    Classe 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 TemplateMethod
  • 48. TemplateMethod: Raffinamento
    Istanza 2
    Classe analizzata: org.jhotdraw.contrib.dnd.DNDHelper
  • 49. Conclusioni