An Overview of the implementation

In Fig. 5.1 an implementation diagram is shown. The user is able to communicate with the Osiris system via the GTK library, which provides a graphical user interface (the same library is used by the gKheops).

Figure 5.1: Implementation of Osiris - DFD.

The main module: Controller gets information about valid filenames: a project filename which contains structured logic, created using the Editor and a Kheops source filename which would be generated by the Generator. Furthermore the Controller provides both internal and external communications. It allows the user to communicate with other modules and launch the Editor, the Generator, the Validator and the gKheops as well.

Both the Controller and the Editor modules have been joined together in one executable to provide more flexibility and to reduce data flow. It is because they both use a graphical interface. This solution is less memory consuming and simplifies the communication process between the Controller and the Editor. However they are still separate modules.

The Generator and the Validator are still separate modules and separate executables. They use similar compilers technology to produce a Kheops source code (Generator) or to validate the logic (Validator).

The data representation for storing created logic is chosen. It is the XML, which stands for the Extensible Mark-up Language.

Patches for the gKheops are implemented to provide external communication methods.

To expand flexibility of the Osiris, the Launcher has been defined. It is a module which is responsible for execution of the generated code. As the Launcher the gKheops is chosen but the Osiris could be configured in such a way that any kind of expert systems can be used. The only requirement is that the Launcher have to use communication methods described in Section 5.8.

If any other code generator is created it should take the same arguments and should reacts in the same way as the patched gKheops do. See Section 5.15 for details.