System Architecture

A Kahina-based debugger is started by creating a KahinaInstance? object, which mainly consists of a KahinaState? and a KahinaController?, and communicates with a KahinaGUI. The KahinaState? administers a step database containing the step data as well as one or more data structures to model the relations between steps (such as call trees and charts), caching step data into temporary files if they become too large. The KahinaGUI includes a window manager coordinating various GUI elements, and it provides functionality for creating and manipulating windows. The KahinaController? is responsible for message exchange between the various components of the system.

Kahina can straightforwardly be adapted to a specific application by specifying step types and their relevant content. A bridge is then implemented to encapsulate all the traffic between the client application and Kahina. This includes transmitting the step detail information as well as handing back control instructions, such as tracing commands, to the client process. On the client side, the communication with Kahina is usually implemented by adding code for transmitting step data to the bridge, and a control loop that interleaves with the execution process and prompts Kahina for a user command telling it how to proceed.

When creating debuggers for systems implemented in Prolog, Kahina's libraries are often sufficient to make client-side adaptations unnecessary, shifting the main focus in creating an advanced debugger to specializing the LogicProgrammingBridge? for the respective client program.

As the second step in creating a customized debugger, custom data types and specialized views can be added to Kahina's modular data and view models.