HQED

Introduction

The Extended Tabular Trees editor is the tool which supports the XTT design phase.
The goal of the system is to move the RBS design phase on the more abstract level, where the model of RBS is presented as visual model. The visualisation introduces more intuitive and transparent designing, what is important during the design phase of the complex systems.
One of the requirements for the editor, is an open architecture that allows developing the application by creating a plugins, changing the interfaces, etc.
Originally, Extended Tabular Trees editor had been called XTTed (XTT EDitor), but later the name has been changed to HQed (Hekate Qt EDitor).

The list of requirements for the editor can be divided into three categories:

Requirements of design support, quality is the group that contains the specification of the requirements introduced by the XTT design method.
Requirements of functionality is the group that contains the specification of the requirements for the application. In other words this group defines the abilities of the application.
System requirements is the group that contains the list of the minimal system requirements and dependencies. The group gives the answer to the question: what is needed to execute the application (libraries, packages, etc).

The support for ND (not defined) and ANY operators.
Defining attribute groups (Defining group name, description; Defining group parent, or as root ).
Defining attributes (Defining attribute’s name, acronym, type, domain; Defining default value for attribute; Defining attribute’s relation, description, group)
Defining tables (Choosing attribute from the list; Selecting condition attributes, conclusion attributes, attribute context; Defining the table’s title, description, type)

Defining connections between tables (Defining the input and output parameters; Defining the type of the connection; Defining connection’s label, description)
Translating XTT model to executable PROLOG code.
On-line verification of model quality (Finding unused attributes; Showing validation problems)

Visualisation (ARD model; simplified view of tables; connections; Marking selected items; Zoom in and out; Black and White view option; Exporting the model visualisation as SVG or other format; Printing the model visualisation)
Groups (Adding, editing, removing groups of attributes; Editing group; Deleting group; Changing the group parent)
Attributes (Adding new attributes; Editing all features of attribute; Removing attributes; Sorting attributes within group; Showing the list of unused attributes; Exporting/Importing the attributes’ list to/from ATTML file.
Tables (Adding, Editing, Deleting, Selecting table; Table comments; Auto arrangement of tables)

The Extended Tabular Trees editor has been designed with use Model-View-Controller design pattern. Model-View-Controller (MVC for short) is an architectural pattern used in software engineering. The MVC was first described in 1979 by Trygve Reenskaug, then working on Smalltalk at Xerox PARC.
The main assumption of the pattern is the designing of the project on the three independent layers:
- Model – The model is the internal representation of the information on which the application operates. This representation is not available for the user and it can be interpreted as the state of the system.
- View – The view layer provides representation of the model for the user as well as supports the interaction between application and user.
- Controller – The association between system’s events. It provides communication between Model and User.

The architecture of HQed - HQed has been implemented according to MVC design pattern. The architecture of HQed consists of three layers: model, view, controller.

The XTT model and ARD model are part of model layer. All the data relating with model are stored and processed in this layer.
The controller layer, in the sense of MVC, combines the following layers of the architecture: Controller, PROLOG API, PLUGINS API. The Controller layer can be called as a core of the controller, because all the information, between views and model, goes through this layer.
The PROLOG API layer. The task of this layer is making functions and data available to PROLOG engine. As the result, of implementation such a layer, is the possibility to the control of HQed from the PROLOG level. This is a very important issue because there are tools, which are implemented with the help of PROLOG, and support the checking of the logical quality of the model.

The PLUGINS API layer is responsible for communication between HQed and external plugins. The task of this layer is very similar to PROLOG API layer. The difference lies in the fact that this layer making data and functions available to external plugins. The way of communication can be different: (DLL, TCP/IP). The TCP/IP seems to be the best solution because it is supported by the vast majority of the operating systems. What is more, it makes possible to use the plugins through the network.
The view layer in the sense of MVC, combines the following layers of the HQed architecture: User Interface and XML mapping. These layers are responsible for representation of the model.

The User Interface layer is responsible for communication between user and application. The first task of this layer is the representation of the model layer in the graphical way and suitable for the user form. The second task of this layer, is the intercepting all the events, which come from the user, and the dispatching it to the controller layer.
The XML mapping layer allows to map the model as the XML-based language XTTML and vice versa. This is a very important layer, because with the help of it, the designer can save his work and later load it.