Provides the internal frames and standard panels for handling the CRUD operations on the database objects, for the Access Road desktop. It manages the main window. It is used by the Gui2 package which is responsible for handling GraphicViews and Trees.

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 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.

According to a classical Model-View-Controller pattern, Model is implemented mainly by the gBase package, and the Gui1 package contains View and Controller classes. Indeed, it is more true to say that there are 2 levels of Models, 5 levels of Views and 3 levels of Controllers. Even if they are sometimes in the same class, this set offers a complex but powerful platform to manage the first level of GUI objects. It implements the framework for the internal frames in the desktop, and it is also based on the BeanInfoPattern framework form the Pattern package. The implied classes in the Gui1 package are listed hereinafter:

InternalFrame is responsible to built up and manage all the internal frames in the desktop. It works on the explorer frame, the ACS frames, the view frames, the diagram frames, the text frames, the 'All Views' frames and the structure frame.

DialogBox is responsible to built up the short dialog boxes in the desktop. According to the Model-View-Controller pattern, it is a View used by BeamerManager, CommonPropertyEditor and its subclasses, BaseObjectHandler, and numerous gDMak.Action classes. The typical methods allows to display a message, a list for the user choice, or check boxes and fields. It is possible to select simple or complex typed objects in the explorer. Tip: to understand the executing paths from the DialogBox to the property editors and the gBase objects, it is easy to produce an error on the allowed value of an editing method, so that the sequence of called methods is displayed in the console.

BeamerManager in the Gui1 package is a complex class which displays and edits the properties of an object in some matched tabbed panes, following the BeanInfoPattern framework. It is responsible for managing the property editors for all the ARoad0.gBaseInterface.BaseObjects, with their layouts in the tabbed panes. It does this work both for the beamer frame, the ACSFactoryImpl frame, the structure frame, and the Gui2.GraphicViewPropertyEditor for the 'All full views' and 'All NoThan views' frames. The varied ARoad0.Gui2.PropertyEditors are responsible to display varied types of properties, like a string field, a checked box, a list or a map with strings or more complex objects. A title and some buttons may be included in the displaying, and there is a common look-and-feel for all. Gui2.GraphicViewPropertyEditor is a special case that handles a GraphicView and a JtextPane.

As an application of the BeanInfoPettern framework, BeamerManager integrates all the property editors of this Gui1 package. The editors are presented hereinafter:

BaseObjectHandler in the Gui1 package is responsible for creating or copying a BaseObject instance, excepting for an ACS or a ViewInBase. In the MVC pattern, this is the controller that handles all the user dialogs to define the parameters before the operation. The BaseObject class methods to use in the operation are declared in the BeanInfo class which is associated to the gBase class of the object to handle, in the gBaseBeanInfo package.

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 structured, numerous controls check in the method arguments, and the classes may be easily derived to extend the functions; some methods are quite complex. The interactions gBase/gBaseBeanInfo/PropertyEditor/BaseObjectHandler are complex.

Reliability: medium-high. The execution paths have been well tested in the GUI.