Provides special purpose building blocks for 2D/3D visualization of generic data structures, such as graphs.


Interface Summary
AspectModelListener Interface for listeners of aspect model events.
DataModelListener Interface for listeners of data model events.
DataViewFactory An interface for a factory that creates data views and their graphic implementations.
GraphicView A graphic serving as a proxy for a concrete implementation of an abstract data view.

Class Summary
AbstractDataViewFactory An abstract data view factory for non-nested whole models.
AspectModel A data model representing a special data relationship amongst client models beyond the conventional relationship of a whole model and its constituent parts.
AspectModelFlag A select flag identifying an interactor as a member of an aspect model (such as a graph path element).
AspectModelMonitor Singleton (global) monitor for aspect models.
AspectModels Deprecated.  
DataFeedback Constants and utilities intended for use by data visualization interactors in providing interaction feedback presentations.
DataModel Data Model
DataModelMonitor Singleton (global) monitor for data models.
DataUtils Constants and utilities related to data visualization.
DataView Abstract base class for the role of "view" in an MVC-based visualization of client data.
DataViewMonitor Singleton (global) monitor for data view.
EdgeModel A part model representing a data relationship between two or more (possibly identical) vertex models in a whole model (a hyper-edge).
ElementModel A part model representing a data element in a whole model that has no data relationships (no internal topology).
GraphModel A whole model whose data elements have data relationships (has an internal topology, such as a graph, tree, or list).
GraphModels Constants and utilities related to graph-like models and their topology.
GroupModel A whole model whose data elements have no data relationships (has no internal topology, such as an unordered bag and set).
ListModel A graph model representing a list of entries.
NullGraphicView A graphic view without a graphic presentation.
PartModel An abstract data model representing a portion of client data comprising a whole model, and which has a distinct presence in the whole view.
PartView A data view representing a view of a part model.
PortModel A part model representing a connection point for edge models, such as on a vertex model.
SuperModel A whole model that contains none or more whole models.
TestAspectApp Test app for aspect model display.
TestAspectInput Interaction inputs for test apps.
TestClientApp Test client for displaying various views of graph models.
TestClientWindow Destiny workstation root window.
TestGraphApp Test app for list model display.
TestGraphModels Utilities for building test data models.
TestGraphWindow Window for list display.
TestGraphWindow.Extended Graph window with a button to open a sub-window and create new graph models.
TestListApp Test app for list model display.
TestListWindow Window for list display.
TestListWindow.Extended List window with a button to open a sub-window and create new list models.
TestNetApp Runs TestClientApp and TestServerApp on the same host.
TestParityApp Test app for parity model display.
TestServerApp Test server that creates and updates graph models on a client (see TestGraphClient).
TestTreeApp Test app for tree model display.
TestTreeWindow Window for tree display.
TestTreeWindow.Extended List window with a button to open a sub-window and create new list models.
TestViewInput Interaction inputs for test apps.
TestViewWindow Base class for data model view windows.
VertexModel A part model representing a data element in a whole model that has data relationships (has an internal topology), which are represented by edge models.
WholeModel An abstract data model representing a meaningful and self-consistent set of client data suitable for viewing as a whole.
WholeModel.GlobalWholeTree Global tree used for all whole model tree nodes.
WholeView A data view representing a view of a whole model.

Package Description

Provides special purpose building blocks for 2D/3D visualization of generic data structures, such as graphs.


This package supports data visualization through using the model-view-control (MVC) paradigm.  Focus is on abstract model and abstract view support, with control being left mostly to the gumbo.interact package, and graphic implementation being left to the gumbo.graphic package and others.  A data model in this package is an abstract representation of some client data, and a data view is an abstract representation of a graphic implementation (a concrete or graphic view) displaying the data.

The models and views in this package serve as proxies for the client data and graphic views they represent.  As such, they are implemented as classes and not as interface-class combinations.  Furthermore, the classes do not implement Delegatable, since they are not intended as delegatable services.

To maintain model-view independence, a data model should never reference a data view.  Instead, a data view should reference one data model, and a graphic view should reference one data view, with the graphic view pulling client, model, and view information through the data view and its data relationships.  To minimize the coupling between the graphic view and the client data, the scope of access to the client data should be as limited and generic as possible, such as through proxies of or adapters to the client data.

This package assumes that client data may exist in a JVM or network box separate from the display (client data on the server box, data display on the client box).  This package is intended for use on the display side of the system, with high bandwidth coupling between the graphic views and their corresponding abstract models and views.  If any client data is required by the graphics, it must be included (in whole or in proxy form) with the data models (and hence the need for a client ID to assess the freshness of the proxy data and to associate it with the actual client data).

The attributes of this package are...

Model/View Creation

Several factors drive the manner of model and view creation in this package.  In general, before layout of a whole view can commence, all model parts in the corresponding whole model must be accurately rendered by the part views. And, before a view can accurately render itself it must have a graphic implementation and, possibly, access to the client data it represents. As such, a view cannot exist without its graphic implementation and model, and a part (view or model) cannot exist without its whole (view or model).  To satisfy these constraints factory methods and severe constraints on adding new parts are used throughout this package to assure that a part always has a whole ancestor, and that views always have a model and a graphic implementation. In order to allow the use of data model subclasses, the client is allowed to extend and instantiate data models; but, a data model can only be added to a part model tree if it not already in a tree (no parent or children).

To simplify package implementation and client use, data model and data view sharing is not allowed.  If the same client data is needed in two different ancestor models, two different data models must be created.  For example, if the same client data, a data vertex, is used in a graph model and in a model of a path through the graph, then separate models must be used for the data vertex in the graph and path whole models.  To accommodate situations where the same client data is represented by two or more abstract data models, data models are allowed to share client IDs.

Model/View Destruction

Data model and view classes implement the Disposable interface.  Calling the dispose() method immediately removes a model or view object from active use.  This involves disconnecting the object from any data dependences (links, trees, associations), removing the object from any global maps, and marking the object as being disposed.  Note that Object.finalize() cannot be used for this since the time of its execution is undefined. Once a data model or view has been disposed, subsequent use will throw an exception.

Data Models

Abstract data models serve as generic proxies for the pieces of client data they represent.  Specialization in the data model class hierarchies is motivated almost exclusively by what is significant for presentation layout and rendering.

A data model, which derives from the abstract base class DataModel, includes a client ID and client data.  The client ID uniquely associates the data model with the client data it represents.  It can be used by the system or client to assess the freshness of the data model, and to provide tracability to the original client data should a proxy for the client data be used in the model.

Client data is included in the data model for use by the graphic implementations viewing the model. Typically, graphic views need no client data or, if they do, only a small subset of the actual client data.  In the latter case a proxy for or adapter to the client data can be provided to the data model (e.g. a string with a label, or a constant defining a data state).  The client data provided to a data model should be considered as attributes of the data model that affect its visual presentation.  Other aspects of the client data can be left out.  In fact, the data models and views do not use the client data, only the graphic views, if at all.  Furthermore, the type of the client data provided to a data model must match that expected by any graphic view that may use it.  

The DataModel class maintains a global map that associates client IDs with all active data models.  To allow for the possibility that multiple models may represent the same client data, and therefore share the same client ID, the mapping returns a set containing the associated model or models, if any.

Data models are divided into whole models and part models.  Whole models represent meaningful collections of client data that can be viewed as a whole.  This also means that all of the parts in a whole model must be known and laid out together.  Part models represent components in a whole model that have a distinct presence in the view presentation and, as such, are significant for view layout and rendering.

Whole and part models live in separate trees that implement the composition pattern.  These trees are implemented through service delegation provided by classes from gumbo.util.  These services are exposed indirectly to the client, through type-safe methods.  The abstract model base classes, WholeModel and PartModel, provide only public read access to the model, with concrete subclasses providing any write access.  This allows subclasses to control the structure of the whole and part model trees.

Data Views

Data views serve as generic views of data models.  Associated with each data view is a data model and a graphic view, which is the graphic implementation (concrete view) of the abstract view. Graphic views are implemented via the gumbo.graphic package, which insulates this package from graphics technology dependencies.  Depending on its needs, a graphic view may require a reference to its abstract data view, with access from there to the view and model data structures and the client data.

Like data models, data views are divided into whole views and part views.  Unlike data models, data views are not specialized and are not nested.  Instead, their associated data models provide whatever specialization is needed for view layout and display.

Data Associations

As part of data modeling and viewing, logical associations may exist between part models in different whole models, and part views in different whole views. For example, the model vertices in a list of source code lines may be associated with the model vertices in a call graph of the source code.  And, different views of the same part should appear with the same interaction state (mouse over, selected, etc.).

The client forms model associations directly on the data models, not the views, since views of the models may not exist yet.  Graphic views of the models are responsible for resolving any model associations and creating their visual presentation, perhaps with additional graphic views (e.g. text callouts).  Typically, the system establishes view associations on graphic views automatically, as the graphic views are created.

To Do