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:
The little decision maker pattern in the gDMak package is responsible to manage the basic operations from the events of the menu.
The little internal frame pattern in the Gui1 package is responsible to handle the internal frames in the Access Road desktop.
The gBaseBeanInfo package applies an extended JavaBean pattern called the BeanInfoPattern, to set the handling of gBase objects in the GUI. This pattern covers the display of each property of the base object in the right GUI editor, and the policy to create, edit and delete the property. It is applied mainly by the gBaseBeanInfo and the Gui1 packages.
The embedded class pattern provides a form of multiple class inheritance for the classes in the gBase packages.
The event management pattern for the views is responsible to update a displayed view when a relevant property is changing, from a view node or an intermediate node in any access path of the view. It is described in the documentation of Gui2.GraphicViewBaseListener.
The thread management pattern for the views is responsible to provide a dedicated thread to each displayed view, for processing its own access path searches.
The access path search pattern is the most complex one. It includes mainly the generic gWork package and the AcsAddon gWork packages which contain the search algorithms. There is also the Gui2 package with the GraphicViews, and the CNot package which contains the notification interfaces and classes used for the data flow between the gWork packages and the GUI-oriented packages.
The pattern for the AcsAddons is explicit and well documented, covering the coding for each of the classes and methods which belong to it. It is mainly implemented in the gBase and the gWork packages. This pattern allows to add more easily some Java classes to do specific gBase and gWork functions.
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:
'ACSTree' classes about the display of access control systems (ACS) in graphic trees, both in the explorer frame and in the main ACS frames,
'View' classes about the display of open views in the explorer, and the management of the relevant threads,
'ISTree' classes about the display of IS structure tree,
'Graphic' classes about the display of views as diagrams.
The GraphicView processing is the most important part of this package. The main classes are presented hereinafter:
GraphicView is a subclass of JPanel that is directly used only for the 'Architecture' view, to display the open ACS and the links between them. Most of the GraphicView method are used by its subclasses, then it is recommended to study this class carefully.
GraphicEPRView is a subclass of GraphicView for displaying the gBase.EPRViewInBase.
GraphicNoThanView is a subclass of the GraphicView class, for displaying the gBase.NoThanViewInBase.
GraphicSketchView is a subclass of the GraphicEPRView class, for displaying the gBase.SketchViewInBase in the Sketcher frame.
When a GraphicView has some dedicated frames, these frames are managed by Gui1.InternalFrame and the near classes.
Generally speaking, each GraphicView is associated to one instance from each of the classes Gui2.GraphicViewBaseListenerImpl, gWork.RightsMediatorImpl, and also, if the view is displayed in a JTabbedPane, Gui1.GraphicViewPropertyEditor.
ViewModel is responsible for managing the gWork.RightsMediator instances, the GraphicViewBaseListeners, the closing tab buttons which may be associated to views, and the pool of view worker threads.
Gui2.GraphicViewBaseListenerImpl handles the specialized thread for updating the graphic view, and it detects all the events that require this updating.
gWork.RightsMediatorImpl handles the associated instances of the classes to use in the access path searches; it detects the most complex events that require a view updating, and fires an event to Gui2.GraphicViewBaseListenerImpl.
Gui1.GraphicViewPropertyEditor works as any PropertyEditor in Gui1.BeamerManager, to display the GraphicView and the 'SeeWhy' text in the tab of a JTabbedPane.
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:
call to propertyChange() one or several times, by one or several objects in gBase or gWork, and update the relevant listeners in the base for each base change
propertyChange() updates the 2 inner booleans toChange_ and toUpdated_, starts a timer at the first firing, and restarts it at each firing,
the timer calls actionPerformed() when the TIMER_DELAY is expired, after 50 milliseconds,
actionPerformed() reads toChange_ and toUpdate_, and it chooses to call changeFrameView(), changeTabView() or updateFrameViewRights(), since the view may be in a dedicated InternalFrame or in the JTabbedPane of an 'All Views' frame; then it stops the timer,
changeTabView() and sometimes actionPerformed() calls GraphicViewPropertyEditor.PropertyChangeEvent() if the view is in a JTabbedPane, which uses a worker thread to update the view, then run a task in the EVT to terminate the GUI updating through a call to repaint(),
changeFrameView() and updateFrameViewRights() use also a worker thread to update the view, then to run a task in the EVT; this task terminates the GUI updating by the way of a call to GraphicView.repaint(),
actionPerformed() resets the GraphicViewBaseListenerImpl instance for the next firings on propertyChange().
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:
The AcsAddon pattern allow to strenghten the facilities of the packages gBase and gWork to simulate complex software, but it is not possible to define specific GUI features for a given ACS addon, like new views for instance.
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.