Component-Oriented Programming

The idea of component-oriented programming is that in the course of implementation of various software projects a programmer (or a programmers team) accumulates a library of reused software fragments that are used in different projects. The reused fragments of the programs are called components and programming with the use of these components is called component-oriented programming.

Creation and supporting in operational status of a component library requires certain additional efforts but as a result leads to significant economy of time and funds at creation of new programs. In the course of development of Internet agents the support of component-oriented programming is especially important because the manner of access to some Web resources changes from time to time; and one need rapidly modify all the programs that use these resources. For instance, at every regular change of the user interface of a public retrieval system one should remember what agents use it and make correspondent modifications in these programs. To solve such problems there are some special syntax means in Actor Prolog that support component-oriented programming. These means are so-called packages and automatic connection of components from the SADT diagrams.

1. The Packages

A package in Actor Prolog is a set of classes linked by implication. All the classes of the package must be collected in one source file of a special structure:

  1. In the beginning of the file one writes the heading of the package that consists of the package keyword, the name of the package, and the ":" colon. The package name is a text string in quotes. Usually the name consists of identifiers separated by a slash. One can use both the "/" direct slash and the "\\" back slash; the translator understands both the cases. In aggregate the identifiers constitute the name of the file (without the extension) that holds the content of the package, for instance: "Morozov/Web/Scanning/Analyzer". Thus, in the heading of the package one must indicate a precise path to the file containing this package.
  2. After that one records the names of classes that are imported from other packages together with the names of these packages. Every import command consists of the import keyword, a class name, the from keyword, a package name, and the ";" semicolon. Actor Prolog supports import with renaming; that is one can use the imported class in the program under the name that differs form the name that this class has in the package where it was defined. In this case one adds the as keyword in the import command, after that a new name of the class is recorded. This feature is very important for implementation of visual component-oriented programming that will be considered later.
  3. Further one writes the classes that are members of the package. One can define here the goal statement of the program (the project) as well.

The main source module must be written in accordance with the same rules with the exception that one can not write "the heading of the package" element. The packages can freely import classes defined in other packages. Therefore in the course of translation the source files indicated in the import commands are loaded automatically. In addition, the translator automatically loads the dialog boxes definition files that are situated in the same directories as loaded packages and have the same names as these packages but with the DLG extension.

Example 1. An example of package.

Let us consider the Google4.A example in the Web directory.

----------------------------------------------------
-- An example of Actor Prolog program.            --
-- (c) 2002, Alexei A. Morozov, IRE RAS.          --
-- Retrieving Web information with the help       --
-- of Google search engine.                       --
----------------------------------------------------
import 'Google'  as 'Engine'
                 from "Morozov/Web/Engines/Google";
import 'Request' from "Morozov/Web/Engines/Request";
import 'List'    from "Morozov/Web/Browsing/List";
----------------------------------------------------
project: (('Main'))
----------------------------------------------------
class 'Main' specializing 'Report':
--
control = ('Request',
                engine=self);
--
engine  = ('Engine',
                engine_output=self,
                debug_output=self);
--
demo    = (('Demonstrator',
                suspending:results));
--
protecting:
results = engine ?? get_resource;
--
[
goal:-!,
        control ? show.
--
search(Keywords):-!,
        engine << search(Keywords),
        demo << show.
--
found_reference(URL):-!,
        writeln("Retrieved link: ",URL).
--
next_page(N,URL):-!,
        writeln("Next page (",N,"): ",URL).
]
----------------------------------------------------
class 'Demonstrator':
--
results;
--
dialog  = ('List',
                list_of_resources=results);
--
con     = ('Console');
--
[
goal:-!.
--
show:-!,
        dialog ? show.
]
----------------------------------------------------

This program receives data form the Google retrieval system. The program sends a request with target keywords indicated by user.



Fig. 1.1. Input of target keywords.

The request is send to the retrieval system. Then the agent analyses answers returned by the retrieval system and sends additional requests if it is necessary. Collected data are output in the form of a list:



Fig. 1.2. Results acquired by retrieval system.

The user can select any resource in the list and examine it using the "Show resource" button. The program will call an Internet browser that is used by default.



Fig. 1.3. A view of found Web resource.

All these functions are implemented in a component library that is supplied together with the examples. Examine how various import commands are defined in the program.

We will not consider the organization of separate components in detail. The point of this example is only a general schema of the program implementation:



Fig. 1.4. A schema of the program.

The dialog box where the user enters keywords to be found is describes as a special process that sends the start direct message to the main process. The main process implements interaction with the Google retrieval system. It sends a request to the retrieval system, analyses the answer, and if the retrieval system informs it that there are additional pages sends the inspect_page direct message to itself that causes a new interaction with the Google retrieval system. Retrieved data are saved in a temporary database. The records inserted to the temporary database are collected into a list by a resident and send to the process 'Demonstrator'. The process 'Demonstrator' outputs the list of results to the screen and calls the Internet browser by the user request.

Note that the inspect_page direct message is not a switching one but an informational one. In accordance with the semantics of Actor Prolog the informational messages have the smaller priority than residents. Thanks to this the program begins to output acquired data to the screen even until Google has transmitted a total list of founded Web resources.

2. Automatic Connection of Components in the SADT Diagrams

Actor Prolog supports visual component-oriented programming. In other words it is enough to draw an SADT diagram and indicate in the comments of every block what component must be used for its implementation to create a ready to use program. For that one should simply write the #package command with the package name as the argument in the comment of the block.



Fig. 2.1. Indication of the component that implements a block.

The SADT diagram will be translated into an Actor Prolog program that uses given components. At that the translator uses import with renaming to eliminate possible conflicts between the names of the classes defined in different components.

Example 2. Visual programming of Internet agent on the base of ready components.

Let us consider the Complex.A example in the Web directory.

This program collects data with the help of two retrieval systems at the same time: the Google system and the Rambler system. The resources found by these retrieval systems are preliminary checked to decrease the number of irrelevant answers.



Fig. 2.2. An example of interaction with two retrieval systems.

A general scheme of the program is similar to previous one. A user enters a key phrase (several words). The program interacts with the retrieval systems. Results are output to the screen as a list and can be examined with the help of an Internet browser.



Fig. 2.3. A general scheme of the program.

The lists of Web addresses collected by the retrieval systems are merged and filtered.



Fig. 2.4. Merging and filtering of results.

The program makes it possible to control the maximal number of pages that are received form the retrieval systems, as well as the parameters of preliminary check. The preliminary check can be switched off. One can control what is the maximal size of files that is allowed for preliminary check. If the size of a file exceeds the limit, the preliminary check is not performed.



Fig. 2.5. Assignment of parameters of search and filtering.

After the parameters of search and filtering are assigned, enter a key phrase to be found.



Fig. 2.6. Input of key phrase.

To eliminate irrelevant references the program performs a preliminary check of acquired Web resources. It deletes from the list the resources that do not contain key phrase indicated by the user. The resources that are temporary inaccessible and the resources that are too big for preliminary check are included into the result list without the preliminary check. The program makes detailed comments on the solutions concerning the preliminary check procedure execution.



Fig. 2.7. Preliminary check of the Internet resources.

Collected information is output to the screen in a dialog box.



Fig. 2.8. Output of found resources list.

The same way as in the previous example, a found resource can be examined by an external Internet browser.



Fig. 2.9. Examination of found Internet resource.

Considered example was completely assembled from beforehand prepared components. In fact, the programming process was reduced to drawing of the SADT model of the Internet agent.

Table of content