Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Re-architecting visualisations in Java Swing

900 Aufrufe

Veröffentlicht am

hallelujah moment as I realise coding everything from scratch is a waste of time. So I decide to code a toolkit from scratch instead.... well, almost, i extend various Java Swing widgets

Veröffentlicht in: Bildung, Technologie
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Re-architecting visualisations in Java Swing

  1. 1. R E - ARCHITECTING V ISUALIZATIONSTO J AVA S WING
  2. 2. H ISTORY Napier has been developing visualisations for 15 years Perspective Tunnel OO Database Vis (1994) (1997) Rapley & Kennedy Mitchell & Kennedy
  3. 3. H ISTORYMultiple Tree Graph Matrix Vis (2004)(2000) Parallel Coordinates Multiple Tree DAG (2003) (2007)
  4. 4. S PECIFIC TOOLS But each visualisation in turn has been built specifically for a given context (databases, taxonomy, microarray data)  Reusability hasn’t been one of the criteria our projects have been concerned with – build a demo to show the principles for the problem at hand and leave it at that  Which makes it hard when other data comes along… Those are variable depth phylogenetic trees mate, you ain’t getting in.
  5. 5. DRIVER We wanted to reuse our work to compete for small projects that last perhaps weeks or months That sort of timescale doesn’t leave much scope for development from scratch A set of general components could be specialised more easily than trying to fit some specialised visualisation into a differently-shaped hole
  6. 6. U SE A VIS TOOLKIT ? Plenty of visualisation toolkits to use out there  User level suites allow given types of data sets to be visualised  Programmer level toolkits allow visualisations to form part of larger applications The user level toolkits tend to be stand- alone, more difficult to integrate with other programs The programmer level toolkits tend to have their own new models and syntaxes to learn
  7. 7. S WING Most of our visualisations were built in Java Swing but with custom models, components and UIs Swing itself is a concrete architecture; a fully- coded implementation of an MVC-patterned GUI Re-architect our visualisations for Swing – not just built in Swing but composed on top of Swing’s existing classes for modelling/viewing Table and Tree data Our visualisations can be re-built in a reusable and general form by extending the existing Swing UI and Model classes and building necessary new classes in the Swing style
  8. 8. C ASE S TUDY: PARALLEL C OORDINATES A Parallel Coordinate display is essentially a table where data in each column is ordered independently, so ‘rows’ zig-zag across rather than read horizontally By coupling a new UI class with an extended JTable class (plus a couple of additional sorting classes) we have a Parallel Coordinates Model Interface Controller View (+Controller) implementation. TableMod JTable TableUI el Extended by JParCoor ParCoord d UI
  9. 9. C ASE S TUDY: PARALLEL C OORDINATES LOC: 3,645  2,664 Reusability: Custom App Model  Generic Model
  10. 10. C ASE S TUDY: PARALLEL C OORDINATES By extending the Parallel Coordinate classes, we can also build a Scatter-plot Matrix
  11. 11. C ASE S TUDY: PARALLEL C OORDINATES Easy to adapt Swing-based GUIs to use our components: replace instantiations of JTable(…)with JParCoord(…)  Re: Bederson’s FishEye drop-in replacement for JList (2000) We now have access to default JTable functionality such as Row filtering, Column drag’n’drop interaction, direct value editing etc, which we haven’t had to implement ourselves Two or more JTables or JParCoords can share the same TableModel  A standard JTable in synch with a parallel coordinate plot provides a convenient way to edit data  ! Selection models had to be processed differently as
  12. 12. C ASE S TUDY: PARALLEL C OORDINATES …extends JParCoord and uses a JScatterPlot as a cell renderer in it’s associated UI class Model Interface Controller View (+Controller) TableMode l JTable TableUI JParCoor ParCoord d UI Extended JScatte by rPlot JScatterPl ScatterPlot otMatrix Matrix UI
  13. 13. C ASE S TUDY: G RAPHS /N ETWORKS Re-architecture of previous visualisations of social network and taxonomy data
  14. 14. C ASE S TUDY: G RAPHS /N ETWORKS Swing doesn’t have classes that handle general graph data… So here we have to build our own graph model  But Swing provides conventions, an architecture, of Models, Views & Listeners etc that can be followed For the views, we have two existing views that show graph data  A node-link graph  A matrix
  15. 15. C ASE S TUDY: G RAPHS /N ETWORKS For the node-link view we built a JGraph class, some associated classes, and a GraphUI class  Fair amount of work
  16. 16. C ASE S TUDY: G RAPHS /N ETWORKS For the matrix though… what’s a graph matrix?  It’s a table, with nodes along axes, edges in the middle  We build a TableModel instance that sits as a wrapper around a GraphModel instance  Plug this into a JTable and we have a JMatrix (extended with extras we’ve put in such as row headers & sorting)
  17. 17. C ASE S TUDY: G RAPHS /N ETWORKS The graph and table models for the matrix are context-free, they just hold objects and associated renderers decide how to display them
  18. 18. C ASE S TUDY: G RAPHS /N ETWORKS  Graph and matrix views can thus share models  + Shared selection models for highlighting / filtering etcView (+C) Controller Model Controller View (+C) GraphUI JGraph GraphModel Wrapped by instance of TableMod JTable TableUI el JMatrix MatrixUI
  19. 19. I N PROGRESS : M ULTIPLE T REES Re-architecting Multiple Trees to work on top of multiple JTree components
  20. 20. A DVANTAGES OF R E - ARCH Java Swing’s model framework is very flexible  Table, Tree and ListModels as interfaces with any implementation you like underneath that fits  Pluggable Selection models  Pluggable sets of Renderers that display whatever objects you choose Access to functionality built in to standard Swing tree and table widgets  The default Swing widgets include editing functionality, visualisation components are usually poor at editing data
  21. 21. ! A DVANTAGES OF R E - ARCH Swing’s UI classes are pretty monolithic and inextensible  Mix of private / protected methods that would have been useful to extend, copy/pasting done at some point.  They often reference helper classes with restricted access Default selection models are limited, mostly yes/no Have to understand the Swing classes clearly to incorporate new visualisation effects  i.e. programmatically expanding a column header
  22. 22. C URRENTLY Talks with a couple of firms/existing projects about visualising their data with the Parallel Coordinate component Integrated Parallel Coordinates into an existing Java-based estate agency prototype Developed the Scatterplot matrix component with a health informatics firm in prep for a project bid
  23. 23. C ONCLUSION From our viewpoint, developing this suite of visualisations components that are pluggable directly into Java Swing eases a lot of development headaches We can adapt existing Java Swing GUIs with our components, for the most part it’s one or two lines of code substitution or an init() method We can quickly adapt the components themselves for given contexts/data domains This kind of piggybacking on a commonly-used GUI technology makes it more likely people will incorporate visualisations – and then more people will use them
  24. 24. E ND Thanks Questions / Insults?

×