Package ARoad0.Gui2

Provides the classes for displaying the tree frames and the GraphicViews which display the diagrams in the desktop, following the gDMak package requests.

See:
          Description

Interface Summary
BaseListener This interface is responsible for listening the events fired by one main BaseObject (the main source) as ACSRun and ViewInBase -and also the events fired by the main source objects- for updating the unique graphic (tree or diagram) which is associated to this BaseListener and which displays the main source objects.
GraphicViewListener This interface is responsible for signaling the classes able to manage the GraphicViewEvent.
TreeBaseListener This interface is responsible for listening the events fired by one main BaseObject (the main source) as ACSRun and ViewInBase - and also the events fired by the main source objects- for updating the unique JTree which is associated to this TreeBaseListener and which displays the main source objects.
 

Class Summary
ACSTree This class is responsible for creating and for updating viewable trees from an ACS.
ACSTreeBaseListenerImpl This class is responsible for listening the events fired by one ACSRun - and also the events fired by the ACSRun objects - for updating the unique JTree which is associated to this TreeBaseListener, and which displays the ACSRun objects.
ACSTreeUtilities This class is responsible for providing useful methods for updating the ACS trees when a base object changes.
CommonTreeCellRenderer This class is responsible for the look-an-feel setup into the trees.
ExplorerTreeCellRenderer This class is responsible for the look-an-feel setup into the explorer tree.
GraphicAccount This class is responsible for managing the display of an UserID in a GraphicView.0
GraphicActor This class is responsible for managing the display of one Actor in a GraphicView.
GraphicContainer This class is responsible for managing the display of one rectangle in a GraphicView.
GraphicEPRView This class is responsible for displaying an EPRViewInBase and its graphical objects (nodes, links, arrows, rights) in the desktop.
GraphicGroup This class is responsible for managing the display of a GroupID in a GraphicView.
GraphicNode This class is responsible for managing the display of one graphic object in a GraphicView.
GraphicNoThanView This class is responsible for displaying a set of Sources and one access Target, and to show if all the rights of all the sources on this target are above or not a No-More-Than right criterion, and below or not a No-Less-Than right criterion.
GraphicResource This class is responsible for managing the display of one Resource in one GraphicView.
GraphicSketchView This class is responsible for displaying an EPRViewInBase in the sketch view of any BaseObject selected in the desktop, which is named the view center.
GraphicText This class is responsible for managing the displaying of a colored text in a GraphicView, from any BaseObject, a StringRight more specifically, or to display any String.
GraphicView This class is responsible for displaying a view and its graphical objects (nodes, links, arrows, rights) in the desktop.
GraphicViewBaseListenerImpl This important class manages the GraphicView associated in the GUI to a ViewInBase, and it is the main manager of a specialized thread to update the view and its rights at every relevant base changing.
GraphicViewEvent This class is responsible for implementing an event from a GraphicView in the desktop.
GraphicVirtualFolder This class is responsible for managing the display of a VirtualFolder in a GraphicView.
ISTree This utility class is responsible for creating and for updating a viewable tree for the IS structure.
ISTreeBaseListenerImpl This class is responsible for listening the events fired by BaseManagerImpl for updating the JTree which is associated to this TreeBaseListener, managing the tree of the IS Structure.
ISTreeCellRenderer This class is responsible for the look-an-feel setup for the IS structure tree.
TreeManager This class is responsible for managing viewable trees for an ACS or a view, and more precisely the TreeBaseListeners associated to these trees, and for managing the Explorer tree creation.
ViewModel This class is responsible for managing the gWork.RightsMediator instances, the GraphicViewBaseListeners, the closing tab buttons which may be associated to views, and to manage the pool of view worker threads.
ViewModel.SimpleThreadFactory  
ViewTree This class is responsible for constructing viewable trees for a view.
ViewTreeBaseListenerImpl This class manages one tree view in the explorer.
 

Package ARoad0.Gui2 Description

Provides the classes for displaying the tree frames and the GraphicViews which display the diagrams in the desktop, following the gDMak package requests.

Generally speaking, the Access Road software is based on a solid object-oriented design. The best way to provide reliable software at the best cost is to concentrate the efforts on clear and structured data, clear and structured patterns, clear and structured documentation. The Access Road classes are first Plain-Old Java Objects (POJO), because we think that well-structured POJO is the proven way to have great software. Interfaces and methods are stable, and their generic nature provides high-level operations. Some robust coding patterns may then appear through the repeated use of these classes in varied contexts, in an iterative process.

Several coding patterns have so emerged during the Access Road development, even if they are not always fully presented as pattern in the Java class documentation:

As a framework for simulators, Access Road needs to offer all these coding patterns. It provides powerful capacities to simulate a new software, and to integrate it into the GUI and into the other simulations.

It is important that the GUI offers a standard display and standard operations for all the current and future simulations, whatever the characteristics they have. The principle of clear and structured coded concepts is then extended to the GUI. This is a complex requirement, but it will be fulfilled only when the GUI will appear to the user as a simple extension of its proper way of think. The complexity of the concepts and operations is masked by default, in all the possible ways. The GUI displays only the needed windows to operate, and a window works independently from most of the other windows, with its own commands the user may learn gradually. This is why the main menu is so simple, without buttons. This is also why a generic set of operations has been defined for the GUI, as an image of the set of concepts Access Road handles in its generic database. This allows a new user to operate on Access Road with a minimal experience, whatever the software is want to simulate. He has just to understand some generic concepts, to know how to use the explorer and the beamer windows, and how to handle some basic commands in the main menu.

In the Gui2 package, there are 4 class groups listed hereinafter:

The GraphicView processing is the most important part of this package. The main classes are presented hereinafter:

This part describes the view thread management by the Gui2.GraphicViewBaseListenerImpl class. Outside the view handling, there is no thread management. With the view threads, the first aim is to update quickly the access paths of a view when a property has changed in a view node. This is why it is done outside the event dispatch thread and the main thread of the program, in a pool of worker threads managed by ViewModel. On the other hand, the worker threads do not work at the view creation or opening. In all cases, after the paths search, the graphic view updating is done in the event dispatch thread.

The second aim of the thread management is to process the paths search only once, while a database updating may generate more than one property change. A TIMER_DELAY of 150 ms is set by code to not process immediately the first property change. After the TIMER_DELAY, even if several change events have been fired, the access path search reads the actual state of the base. The maximal number of worker threads is set at 3 by Gui2.ViewModel.

The GraphicViewBaseListenerImpl class is running under the event dispatch thread (EVT), and the calling sequence in this class is:

In all cases after the view creation, the worker thread is run to call GraphicView.resetRights() or resetGraphicView(), and there is a call to GraphicView.setWhyText() in the EVT. The task in the worker thread is then ended. Since the worker thread is in a pool which is provided by ViewModel, the same thread is able to process a new task for another GraphicViewBaseListenerImpl instance, or for the same instance.

The classes in the Gui2 package are used mainly by the package gDMak, and they call classes in the packages gWork and gBase.

The performance of the Access Road GUI, in the 0.7.0 version, has some limits. They are presented hereinafter:

Ease-of-use: medium. The package is well documented, but the interactions between GraphicView and its subclasses may be quite complex, and there is a specific layout manager.

Reliability: high. The hierarchy of classes from GraphicView provides an efficient set of methods, and the execution paths have been well tested.