You get a bonus - 1 coin for daily activity. Now you have 1 coin

11.4. Maintenance of the cryptanalysis system

Lecture



Extending the functional capabilities

In this section we will attempt to improve the capabilities of the system being designed and to assess its flexibility.

In intelligent systems it is very important, along with solving the problem, to obtain information about the process of searching for the solution itself. For this the system must be given the capability of introspection: to record the course of activation of the knowledge sources, the reasons for and the nature of the assumptions put forward, and so on, so as to be able to ask the system why a particular assumption was made and what results it leads to.

To implement such a property two things must be done. First, a mechanism must be introduced for tracing the actions of the controller and the knowledge sources, and second, certain methods must be modified so that they record the corresponding information. The idea is that the actions of the knowledge sources and the controller are recorded in some common central repository.

Let us see which classes we will need. First of all, let us introduce a class Action that records the actions of the knowledge sources and the controller:

class Action {
public:

Action(KnowledgeSource* who, BlackboardObject* what, char* why);
Action(Controller* who, KnowledgeSource* what, char* why);

};

An instance of this class is created, for example, when the controller activates some knowledge source. In this case a pointer to the controller is placed in the argument who (who), the active knowledge source in the argument what (what), and some explanation (for example, the priority of the assumption) in the argument why (why).

The first part of our new mechanism has been created; the second is also not very complicated. Let us look at where the main events occur in our system. We will see that the main ones are the following five operations:

  • methods that put forward assumptions;
  • methods that back out assumptions;
  • methods that activate knowledge sources;
  • methods that carry out rules;
  • methods that record hints from the knowledge sources.

All these events are concentrated in two places: in the finite state machine of the controller and in the mechanism for putting forward assumptions. We will not have to change the architecture of the system substantially in order to accommodate the requirements indicated above.

For completeness it only remains for us to create an object that answers the questions of the system's user: who? what? when? why?. Designing such an object is not difficult, since all the information needed for its work can be obtained from instances of the class Actions.

Changes in the requirements

If the design decisions taken have been implemented correctly, then new requirements on the system can be satisfied with minimal changes to the design. Suppose that three new requirements have been placed on this system:

  • the ability to decipher from foreign languages;
  • the ability to decipher a transposition cipher and a simple substitution cipher using (one) substitution and transposition;
  • the capacity for self-learning.

The first requirement is the simplest, since the connection of our system with the English language is not essential. It is reflected only in the rules of the knowledge sources. Even the class Alphabet has been made independent of any particular national alphabet.

The second requirement is substantially more complicated, but is solvable within the framework of the blackboard mechanism. It will require the introduction of new knowledge sources concerning transposition ciphers. The key mechanisms and abstractions will also be fully preserved in this case, but the introduction of new classes will be required, which will operate within the framework of the existing mechanisms for putting forward assumptions and for inference.

Hardest of all is fulfilling the last requirement, since machine learning belongs to the domain of artificial intelligence. One could, for example, propose that the controller, in dead-end situations, turn to the user of the system for help with a request to put forward an assumption. Such assumptions (together with the sequence of actions that led into the dead end) can be recorded by the system and will make it possible to avoid similar dead ends in the future. Such a very simple learning mechanism can be introduced into our system without a substantial change to the class structure and within the framework of the existing mechanisms.

Comments

To leave a comment

If you have any suggestion, idea, thanks or comment, feel free to write. We really value feedback and are glad to hear your opinion.
To reply

Lectures and tutorial on "Object Oriented Analysis and Design"

Terms: Object Oriented Analysis and Design