OSMIS Technical Specification

Architecture Overview

2.3 MVC and UI Overview

The GUI system used in this system follows the MVC paradigm. Before delving into the operation of the system, a brief overview of MVC is given.

MVC stands for Model View Controller. The MVC paradigm suggests a method of partitioning code which allows for quick changes in frontends (by changing views), business logic (by modifying the controller), and the underlying data model (by changing the model), with minimal impact on the rest of the system.

Views represent the forms displayed to the user. Controllers are responsible for modifying the view based on user actions. Controllers also change the model in response to user requests. The controller classes thus consist of lots of methods to handle business logic tasks, while the model mostly consists of static data.

Further information regarding the MVC paradigm can be obtained from the GUI track of the Java tutorial.

The OSMIS GUI consists of a number of distinct components:

1. The menu, sitting at the top of the frame;
2. The module list, sitting on the left hand side of the window;
3. A tabbed pane, with each tab presenting the user with a form. Each tab also contains buttons with which actions can be performed on the form.

The module list implements its own model and controller (and obviously view), while a number of forms within the tabbed pane may share models and controllers.

Groups of forms displayed within the same tabbed pane are grouped into modules. Modules may also contain other modules (at the moment to depth 1). Thus, if a user selects a module or a submodule in the module list, the tabbed pane on the right hand side of the screen changes. The ModuleTreeModel class implements the model for the module tree. Note that modules (as well as tabs) have names so as to interact with the security model. The ModuleTreeController is responsible for handling events on the model tree.

The tabbed pane section of the GUI is represented by a set of OssmsPanel objects, which are extensions of the standard JPanel. An OssmsPanel object requires controllers to handle a standard set of button presses. Furthermore, a OssmsPanelController is responsible for handling non-button events of interest, while a OssmsButtonController should be extended to handle various button presses. A OssmsButtonModel class provides the model for the various buttons. Button models and controllers are provided as it is anticipated that many tabbed panes will share similar (or identical) button behaviour.

Please note that classes have not been specified for the various GUI forms. It is expected that the implementor will use the GUI mockup screenshots to implement the various forms.