On Microcontext Representation of Knowledge and Programs

Vladimir V. Prokhorov

Abstract. We discuss in this paper the problem of "the best language" for domain-oriented knowledge representation. We devote the main attention to the example of human-computer interaction languages, including programming ones. The problem is discussed from viewpoint of contradiction between wealth of a language and its compactness, flexibility, and universality. To solve this problem, we propose so named "micro-context multilanguage approach" that combines the object-oriented design concept with ideas of knowledge representation and human-computer interaction. Multilanguage media PYTHAGORAS implements some items of the approach.



On Static Microlanguage Structures

The Microcontext Approach


Application of the Approach




In this paper, we consider a language and a class of informational models as the closest indissoluble ideas: we view a language as a mean to describe elements of some class of models.

We consider computer-programming languages as a particular case of human-computer interaction (CHI) ones, and the latter - as a particular case of general knowledge representation (KR) languages. So, wherever we discuss computer languages, we mean general KR in fact.

On General Knowledge Representation

It is not a simple problem to choose appropriate KR language (KRL) for a complex domain. To describe objects and tasks there are required adequate languages.

First, the problem of "the best language" is related to contradiction between its wealth and compactness. A language should own high descriptive power, and not should create too many troubles for computer processing.

Another difficulty is related with severance between a language being natural for specialist in a particular applied field on the one hand, and both internal essence and external form of special KRL on the other hand. It is important to use in work not specially introduced new terms for description in a subject area, but the same terms and ideas, which are used traditionally in the field, if possible. Realization of such feature could save and transpose semantics of the world in a KR model. Unfortunately, many KRLs are intended exclusively for specialists in knowledge usage; it is a common imperfection of those languages.

Complexity and variety of knowledge structures involve variety of different KR formalisms. However, practice shows that main formalisms (for example, semantic networks, frame models, production systems, logic models, etc.) possess various imperfections being used separately. The majority of these formalisms could be successfully applied to example problems, but are not quite effective being applied to real tasks: every way of representation have a propensity to special structure of knowledge (a choice of the optimal model is depended of kind and complexity of a task). So, these models are sufficiently restricted for real knowledge variety.

KR should be understandable for both the system experts and users, otherwise a knowledge acquisition and estimation could be labored. However, if we would be limited to use a single model for a system's representation than we would be forced to represent a large portion of information not evidently to the system nature. It could be difficult for user to understand and modify such a base.

Note, last years, the hybrid models of KR have appeared; these ones combine the above-indicated approaches.

On Computer Languages

Everything we have discussed for general problem of KR is topical for computer-human interaction and programming languages' areas with some distinctive features. In the field, the problem of the description's processing, relating both software and hardware is added. For example, development of complex systems is often related with necessity to use powerful as interface tools, as computing and data resources; it is very difficult to meet all the wishes using a single hardware environment.

There are well-known various attempts to found the "unified knife" (as all-absorbing PL/1 or newest JAVA [23]) in computer languages area. Principally the some basic approaches are used in computer languages' area as in the general KR field.

The first one is to use some universal, domain-independent, narrow language, basing on one main paradigm [6, 27], like to "RISC" idea for microprocessors (Fig.5). In this case, it is necessary to reduce every object, we deal with, to selected single a paradigm (or to small amount of paradigms) and language. To apply the approach, a user should select some universal paradigm (for example, algorithmic, functional, or logical) and corresponding computer environment. Then it is necessary to apply the specific science/art to reduce tasks from different areas to models in the paradigm and language terms. Therefore, it is necessary to select a priory the only best paradigm (and the best language) for objects of wide class. The most popular basis of this approach is algorithmic paradigm. One more common approach supposes usage of a large multiparadigm domain-oriented language with a large amount of included paradigms (similar to "CISC" idea for microprocessors) [2, 10] (Fig.6). The structure of the multiparadigm language elements' connection is quite stated by such a system's developers, as a rule. Accordingly to the idea, it is necessary to develop a tremendous variety of special compound languages (and systems) for various areas of application, unifying main metaphors in various combinations. Multiparadigm systems might be also specialized and intricate in study and use.

On Hierarchical Approach

It seems, that the best solution of "the best language" problem could be achieved by usage of the modular assembly technology for a language area [20].

The idea of hierarchy is classic. It is obvious now, that well knowledge about complex phenomena or object is structured one. The method is common used in large systems analysis, related with hierarchical dissection of a large problem to more simple parts. As to programming area, the idea of hierarchy was developing from the early idea of modular and structured programming to modern concepts of object-oriented programming and object-oriented design [1, 4, 26], and some other modern ideas [8, 12, 15]. The idea finds its reflection in hypertext [3, 13], hypermedia [9, 24], and many other concepts. In KR, the frame-based approach [5, 25] is based on multilevel descriptions. Hierarchy is corner stone of UNIX system.

The structural organization of a language for document representation is offered in very many software packages now. For example, every media type in HyTime system [14] is supported by its own editing environment. The OLE-technology of the MSÒ WINDOWSÔ operating system and the similar approach in AppleÒ MacintoshÔ System support hierarchical organization of documents (including multimedia ones); editing is processed by tools, specialized for a given type of subdocuments. The idea has been materialized in HyperCardÔ , HyperLinkÔ , and in similar software environments [9].

The approach of hierarchical microcontext, multiparadigm, multiequipment "p -technology" [17-21] is one of such type. Moreover, the approach combines "programming language design" and "computer construction" (see [27]). The analogy between this approach and the modern ideas of machinery building and electronics is obvious.

On Static Microlanguage Structures

Dividing of complex languages on smaller parts is the first step to the open layered multilanguage technology.

Programming Language as Structure

Let us analyze the programming languages' area. The very first programming languages were called algorithmic ones; the name quite reflected their essence. Later, the languages were enriched by various constructions of not algorithmic nature, for example, formulae notation. Nevertheless, these constructions were interpreted as some external form (like to "macroses") of specific notation of some algorithms, and the languages saved the name of algorithmic ones. It is curious to remember that even Prolog was often called as algorithmic language in the beginning because of "in actual fact" the execution of a program in Prolog initiates execution of some algorithm.

One the other hand, CHI rules and programming languages were considered as quite different areas.

It seems more fruitful to view any computer language from viewpoint of various descriptive models, not only analyze the execution process. In this way, we could view some language as complex structure or models' hierarchy.

Let us consider the pairs {[set of basic elements], [set of composition/decomposition tools]} as language-forming basis. Each such a pair corresponds to some particular kind of informational models [6], for example:
Algorithmic tools allowing us to represent an action as a temporal sequence of more simple ones (The basic elements are from some set of actions. The composition/decomposition tools are algorithmic constructions; such as, sequential execution, alternative, loop, composition, and recursion).
Functional (formula) tools to build complex functional transformations from primitive ones, to use formulae. (The basic elements are a certain set of functions. The composition/decomposition tools are a superposition of functions, conditional assignment of functions, and a recursive definition.)
Logical (predicate) tools to construct complex logical statements from primitive ones [7].
"Geometrical" tools to construct complex graphic elements basing on simple ones (such as transference, imposition, etc.).
Rules to create complex data types from simple ones (such as Hoare's sublanguage in Pascal).
A group of tools for sound and voice definitions, allowing us to manipulate with sounds, music, and speech.
Rules for syntax definitions to construct a complex syntactical object from primitive ones.
Tools to create complex data types from more simple ones.
Tools to describe position of chips on an electronic board.
Musical tools to create complex sounds from elementary, etc.

We could consider microlanguages corresponding to each set of composing/decomposing tools. Note, that from the proposed point of view, for example, the algorithmic language not includes variables, assign and others operators, etc.!

Now, we try to consider a traditional language as complex structure of atomic ones.

Fig.1. A dissected program in Pascal

An Example: Dissection of Pascal

Let us analyze, for instance, one of simplest languages, namely Pascal. The obvious method to form sublanguages is to group syntactical terms descriptions in whole language definition on some compact sections. Considering formal syntax description and semantic of Pascal [11], we could separate all the constructions into some hierarchically related groups, each of them could be interpreted as independent sublanguage. Fig.1 illustrates the idea on the example of genuine program fragment from the BORLANDÒ DELPHIÔ installation pack (the file Delphi\Demos\Doc\Calendar\calsamp.pas). The original program is shown on the top-right of the picture. The same program is shown on the main area of the figure, where elements, corresponding to different sublanguages are framed.

Looking at the language from the viewpoint of sublanguages' allocation, we could separate some independent layers including the next ones:
rules for textual representation of names and numbers,
functional (formula) layer (rules for formulae writing),
algorithmic sublanguage (constructions of sequential, alternative, loop execution, etc.),
rules to define data type of variable,
sublanguage for complex data type description, etc.

We could imagine framed pairs of the language elements, as client/server pairs of the objects, where one language is a shell for others. In other words, a complex construction in a language could be applied as an atomic symbol of another language (Fig.2).

Fig.2. Encapsulated languages

Fig.3 shows a possible chart of selected sublanguages' interconnection for Pascal. Note once more, that from the described viewpoint, Pascal is not an "algorithmic language"; it is not a language of algorithmic paradigm. It merely includes an algorithmic layer! The algorithmic language in the concept does not include variables, numbers, assigns, etc.

Fig.3. A possible dissection of Pascal

Merit of the Microlanguages Detachment

It is possible to carry out dissection of any non-trivial languages and software, for example, "logical" Prolog, "functional" Lisp, "object-oriented" C++, JAVA, HTML, or any more complex system possessing more undoubted multiparadigm nature. We propose to study any non-trivial language as a complex object.

Of course, borders between sublanguages could be built differently. The main criterion in the separation is as follows: relations between terms in the same sublanguage could be stronger then between elements from different sublanguages. We mean here the relations both in internal essence and external representation (for example, textual or graphical one) of the elements.

The language dissection is valuable for both better understanding of its essence, and formation of an "orthogonal" composition/decomposition rules' collection. If we would draw the charts similar Fig.3 for various languages, we could see that many microlanguages (for example, algorithmic constructions) are met in tremendous variety of languages with some variations.

Fig.4. Disassembling of complex languages, creation of a set of various microlanguages, and assembly of multiparadigm language for some particular task

The idea of complex languages' "dissection" is highly useful on its own to determine the best specimens of implementation in every group of rules. Furthermore, it leads the idea of the micro-context approach.

The Microcontext Approach

The idea of complex languages' dissection could be enhanced in some directions, generating the microcontext approach.

Assembly of Microlanguages

The first, additionally to the preview section, we could free connections between sublanguages resulting of various languages fragmentation (Fig.4). Then we could consider these ones as raw material to assemble a new language. It allows dynamically construct a task-oriented KR language, that is suited the best for a particular problem. Moreover, each of sublanguages would own external form, for example, there might be mixed both textual and visual languages.

Fig.5 - Fig.7 illustrates a difference between basic approaches to description of complex phenomena. It could be difficult to use mono-paradigm language (Fig.5). The troubles could occur in usage of a powerful language with static relations between components, if its authors did not suppose to apply it for the particular complex subject in details (Fig.6). However, it could be possible to achieve a very high adequateness of description using sufficient amount of elementary languages reflecting various metaphors (Fig.7).

Fig.5. Complex object and single-paradigm language

Fig.6. Complex object and not adequate complex language

Fig.7. Complex objects and dynamically adapted complex language

The Phases of A Description's Existence, And Supporting Software

The second, we could consider various "phases of existence" for knowledge description. For example, we could select the phases of editing, compiling, interpreting, and deleting of descriptions. Fig.9 illustrates languages' interconnection for some stages of a description existence. We discussed above the abstract problem of KR. If we could assume computer-related description, we should discuss both software and hardware to support preparation of the description and different kinds of work with this one.

The most common phases of the language description existence are the next:
Development of a phenomena's model.
Preparing and editing of the description using computer environment,
Compiling or another conversion.
Computer modeling or interpreting of the description ("execution" in particular).
Obliterating of a description's part in sublanguage.
Documenting (print) of the description.

Some editor's operations: saving of subdescription, and insert from buffer, etc.

Fig.8. Example of multilanguage description using the algorithmic layer (in p -chart form) and subordinate layers

Fig.8 shows a mixture of a graph algorithmic language (as a top layer) and some sublanguages at the editing phase; some commonly used software is used to form underneath layers.

Fig.9. Phases of a description existence, and supporting software

Fig.9 illustrates some phases of a description existence. If we deal with combined language, it is natural to demand the software supporting each of phases be assembly too. So, it would be excellent if for every microlanguages we have software supporting each phase of this ones existence, and the software components could be work together in various combinations, adaptively forming task-oriented editor, compiler, executor, etc.

Hence, to define some sublanguage for computer use, we have to define
the program must be run if user would like to edit a fragment in this sublanguage,
the program must be run if compiler of upload layer would like to compile a fragment in this sublanguage,
the program must be run if by execution of upload layer it would be necessary to interpret a fragment in the sublanguage, etc.

The software must be agreed to work together. We would emphasize that a work at every phase seems as a work in united media, as a work with united language. Therefore, we could edit hierarchically enclosure parts of a specification in about the same manner as fragments in sublanguage of the "multilanguage" program Fig.1.

Hardware To Support Assembly Technology

The third, we could consider different material media ("Hostme hardware") to support each existence phase of each microlanguages. So, we could say here about computer architecture dynamically synthesized for particular task. Fig.10 illustrates a possible distribution of processing on set of computers (similar to one shown on Fig.11) for some existence phases.

Fig.10. Different Host hardware for different phases

Note that distribution of computers may be different for different phases. For example, preparation and compiling of some submodule might be done on root PC, but execution - by another computer. Moreover, some subwork might be a complex work itself. For example, editing of a sublanguage could be executed on some peripheral computer, while the root one is used as terminal, and needed work files could be stored on a third computer of the network.

Fig.11. Particular hardware configuration

Common Environment and Languages Coordination

During execution, described object could affect on a common environment (for example, computer's memory, screen, etc.). The subobjects being described by different sublanguages could modify on some parts of common environment. So, it is reasonable to dissect common environment of the description on some subenvironments, to make modules' interactions clearer.

Forms Of Screen Representation for Multilanguage Description

It is not a question now, how to represent hierarchical knowledge, because of the topic have been well stood for layered documents representation. It could be applied the same kinds for layered KRL's representation, namely

  1. Sublanguage fragment is shown in natural form on a description in language-container (as in OLE 1 in MS(r) Windows(tm)), see Fig.8.
  2. Sublanguage fragment is shown in its natural form in a window (as in OLE 2 in MS(r) Windows(tm)), see Fig.8.
  3. Sublanguage fragment is represented as a label (as "minimized"), we could activate the label to view/edit the fragment's natural site in the form (i) or (ii).

Fig.12. The task environment as subenvironments' union

Summary: The Characteristic Features of the Approach

The characteristic features of the concept are the next [20]:

  1. Any knowledge description (except the "atomic" ones) is regarded as a hierarchic structure, a superposition of more simple ones.
  2. Each of the sub-language layers is oriented toward a much narrower class of operations and its set of rules is much more compact.
  3. For every sub-language layer we have:
    1. an independent internal idea of the sub-language,
    2. an independent form of external representation of the sub-specifications (including media type).
  4. The following phases of the work with the layer of specification:
    1. creating/viewing/editing,
    2. interpreting or/and translating/compiling, etc.,

      and independent

    3. hardware,
    4. software

corresponding to each of phases listed above. The software and hardware for each phase of each sub-language may be to be independent of each other, may be created independently by their producer, and may be free chosen

There are treaties supporting the multipurpose use of every language layer, the multiplicity of couples of micro-languages, for which the components mentioned in (IV) could be used together, be free combined and changed (as "plug and play").

Particularly, the items in (IV) may be supplemented with other ones, such as phases of documenting (printing), creating, deleting, and copying of carriers of subspecifications (for example, files). Some of the phases mentioned in (4) (for example, compiling) may be absent. Generally, the idea proposes to decompose a development task (object) into micro contexts that each can best be supported with their own micro sublanguage at every stage of the work with a description.

Merit of the Approach

Every element of a complex phenomenon could be represented in much adequate form.
The description elements are processed in software microenvironments, much suitable for this particular work.
Support of different phases of existence for different sublanguages by different hardware could achieve high quality of a work in general.
The software supporting each sub-environment (dialogue monitor or editor, interpreter or compiler, etc.) is compact, hence reliable and cheap; independent producers of the sub-environments ensure the high quality of the particular components.
Each of sub-environments is much simple in study because of its compactness.
An uniform approach could be realized for different informational concepts; differences between "algorithmic", "functional", "logical" languages, between "programming" and "usage of programs" are neutralized.
Even a very small set of microenvironments generates substantial variety of environments, hierarchically formed by this set.
The approach possesses very high reuse ability.
........................It could be applied for various level of description the uniform philosophy of models' hierarchy with different phases of description existence, and different executors of each phase (both "software" and "hardware"). .............., from low-level programming to sciences' relations (Fig.13) (note, that for the top levels, the methods and knowledge could be "software" for particular area, and specialist could be its "hardware").

Fig.13. Chart of sciences' relations as model's hierarchy

It is impossible to create "the best language" for all types of models. However, it is possible to create a certain special micro language especially for the particular type of composition/decomposition tools, and make it (reasonably) optimal by both its internal conception and form of external representation. Microlanguages could form metalanguage/sublanguage pairs. The one language environment may serve as a shell (container) for another one. 


Software environment PYTHAGORAS for MS(r) DOS(tm) and MS(r) WINDOWS(tm) is developed at the Visual Systems Laboratory, Institute of Math and Mechanics, Russian Academy of Sciences to support the microcontext approach. This visual environment could be used to develop multilanguage, multicomputer software for distributed calculations in local and global networks (for example, for simulating complexes). Use of graphic programming language and animation make the software be effective in education [17, 23].

Fig.14 and Fig.15 illustrates screen view for the DOS and WINDOWS versions (the elements marked by icons with "C" letter, are assigned to remote multiprocessor machine).

Fig.14. An example of PYTHAGORAS for DOS screen view

PYTHAGORAS includes:

Some editors to create and edit descriptions in sublanguage layers, represented by p-charts, and to run external programs assigned as editors of underneath (embedded) sublanguage modules.
Internal compilers for some micro sublanguages (algorithmic, functional, and syntactical); the compilers run programs assigned as compilers of embedded submodules, developed in underneath (embedded) sublanguages.
Executing subsystems with debugging mode.
Registry editors to tune subsystems, remote computers configuration, etc.
A variety of some special subenvironments to use PYTHAGORAS in multimachine environments, and others.

PYTHAGORAS provides:

use of open layered multilanguage multicomputer approach,
integration of available computing hardware, accessible through local network, or direct connection and Internet (personal computers, multiprocessor computing machine, work stations);
integration of available computing software;
integration of accumulated experience in software and hardware mastering;
simplest dynamic reconfiguring of architecture depending on soluble problem and available hardware;
support of programming in the environment at all levels of the work, from problem's metalevel, to processes in cells of multiprocessor machine;
use of visual programming and animation for program design.

The software is a set of layers for several paradigms and corresponding micro languages. Algorithmic, formulae, syntactical microlanguage layers have been realized in the media. The layers are opened to incorporate any language as sublayer. If a sublanguage have been registered in a container-system, then we could use objects defined in the sublanguage as the container program's atoms. PYTHAGORAS would run the corresponding editor when user would edit the underneath operator, it would start the corresponding compiler when compiling is done, and it would run the corresponding interpreter if the execution phase is done. Incidentally, a description in whole seems not as a set of linked in execution environments, but as single whole, because of all phases linking.

Fig.15. An example of PYTHAGORAS for Windows screen view

It is very easy to define a new sublayer for any language-container. In PYTHAGORAS it is necessary to set in the registry the next sublanguage attributes:

an icon and/or name to designate the sublanguage;
a program, that should be started when user would try to edit a fragment in the sublanguage;
a program, that should be started when a compiler of the language-container would come across the sublanguage fragment;
a program, that should be started when execution of the program in the language-container would come across the sublanguage framing;
a program, that should be started when a user would try to delete the fragment in the sublanguage, etc.

For example, the registry section for C as sublanguage might be as follows:

Name = C++
Icon = CPP.bmp
Mask = *.cpp
Edit = edit %1.cpp
Compile = TCC&send ^.cpp Alex:^.exe
Execute = Alex:^.exe
Delete = del ^.cpp Alex:^.exe

(Of course, C is not a "microlanguage". Nevertheless, usage of big languages in the multilanguage complex might be very useful too.) Really, user would use a registry editor included in PYTHAGORAS to define the sublanguages. Also it is necessary to indicate in the registry the descriptions of data transfer between each of these programs and corresponding ones for contained language. We have realized some kinds of data transfer between sublayers, namely usage of common file and common RAM area with some types of the parameters' transfer for numerous sublanguages.

It could be indicated a remote computer alias, if the phase for the subsystem is done on remote processor, or data from the remote is used.

We realize three forms of sublanguage module representation in PYTHAGORAS. The modules could be represented as icon (minimized form), as a windowed image (any for MS(r) WINDOWS(tm) version and maximized for MS(r) DOS(tm)), or as frame encapsulated in description-container (the latest is for a textual sublanguage only). 

Application of the Approach

The approach of micro languages and their hierarchy might be used as a basic philosophy of a curriculum in computer science. We have incorporated this idea in the course for students majoring in System Design of the Ural Tech University. During some years, the author gives the course "Models and Languages", basing on teach of primary micro tools. Students study such main concepts, as algorithmic, functional, logical, syntactical paradigms, and others. Each of them is illustrated by examples of elements of that type in complex languages, such as examples of procedural elements in PROLOG, LISP, music environments, publishing systems, etc. We have used the approach at the Summer Math and Computer School for Gifted Children during the last few years. The essence of this education first stage consists of learning (and computer mastering) of some set of micro-languages.

On the other hand, the approach is used to develop complex software systems. PYTHAGORAS was applied to development some software systems. For example, the multimedia complex for diagnosis of pancreas disease has been developed in the environment (it had been programmed by S.Gershtein). This one includes some "external" software tools, particularly data base, tools for connection of medical equipment, etc. was developed in C, assembler, and languages of authoring microenvironments as parts of a whole complex language.

A version of PYTHAGORAS is developed for network that includes PCs and powerful multiprocessor machine MVS-100 (Fig.11) (with operator's workstation on PC working under MS DOS and MS WINDOWS). The complex includes a media for visual development of submodules for MVS-100 under UNIX-like operating system HELIOS. That machine consists of transputer matrix with high-speed RISC accelerators, and a large external memory bank for each of tens of transputers. User could program a top level of developed complex, and RISC processors, using graphic version of C language, extended by some constructions for parallel programming. To program lower layers of a project, operating on root or network PC, user can utilize the graphical C. Developer could use any software working on any computer of a whole complex, to support any phase of a description's existence. 


The author would like to acknowledge and thank the group of software programmers: S.Kalugin, A.Kopelev, R.Pekhov, S.Puzhevich, D.Smirnov, D.Toropov, D.Zuyev. 


1. Brooks F.: No silver bullet: essence and accidents of software engineering. IEEE Computer 20 (1985) 215-230.

2. Budd T.A., Pandey R.K.: Never mind the paradigm, what about multiparadigm languages? SIGCSE Bulletin 27 (1995), 25-40.

3. Conklin J.: Hypertext: an introduction and survey. Computer, 20 (1987), 17-41.

4. Cortois P.: On time and space decomposition of complex structures. Communications of the ACM 28 (1985), 590-604.

5. Fikes R., Kehler T.: The role of frame-based representation in reasoning. Communications of the ACM 28 (1985), 904-920.

6. Floyd R.W.: The paradigms of programming. Communications of the ACM 22 (1979), 455-460.

7. Genesereth M., Ginsberg M.: Logic programming. Communications of the ACM 28 (1985), 933-941.

8. Gulliksen J., Johnson M., Lind M., Nyargen E., Sandblad B.: The need for new application specific interface elements. In: G.Salvendy and M.J.Smith, Eds. Human-computer Interaction: Software and Hardware Interfaces 2. Advances in Human Factors/Ergonomics 19B. Elsevier, New York (1993), 15-20.

9. Haan D., Kahn P., Riley V., Coombs J., Mayravits N.: IRIS hypermedia services. Communications of the ACM 35 (1992), 36-51.

10. Hailpern B.: Multiparadigm languages and environments. IEEE Software 3 (1986), 6-9.

11. Jentsen K., Wirth N.: Pascal. User Manual and Report. Springer-Verlag, New York, Heidelberg, Berlin, 1978.

12. Kantorovitz E., Sudorsky O.: The adaptable user interface. Communications of the ACM 32 (1989), 1352-1358.

13. LeJeune U.A.: Netscape & HTML Explorer. Coriolis Group Books, Scottsdale, 1995.

14. Newcomb S., Kipp N., Newcomb V.: The "HyTime" hypermedia/time-based document structure language. Communications of the ACM 34 (1991), 67-83.

15. Norman R., Nunamaker J. CASE productivity perceptions of software engineering professions. Communications of the ACM 32 (1989), 1102-1108.

17. Papert S.: Mindstorms. Basic Books, Inc. New York, 1980.

17. Prokhorov V.V.: On contradictions between wealth and compactness of languages. In: M.Purvis, ed. Proceedings of Software Education Conference (SRIG-ET'94). IEEE Computer Society Press, Los Alamitos (1994), 289-296.

18. Prokhorov V.V.: On graph representation of syntax definitions. In: J.G.Chen, ed. Expert Systems Applications and Artificial Intelligence. Technology Transfer Series. IITT International, Gournay-Sur-Marne (1995), 53-58.

19. Prokhorov V.V.: Pi-charts — the language of graph representation of algorithms and syntax definitions. Cybernetics and Systems Analysis 2 (1992), 98-107.

20. Prokhorov V.V.: Pi-technology: concept of hierarchical languages of information and its processing specifications. In: East-West Conference on Emerging Computer Technologies in Education. Abstracts. International Center for Scientific and Technical Information, Moscow (1992), 172-173.

21. Prokhorov V.V.: PYTHAGORAS: multienvironment software. In: B.Blumenthal, J.Gornostaev, and C.Unger, Eds. Human-Computer Interaction. Lecture Notes in Computer Science 1015. Springer Verlag, Berlin (1995), 135-148.

23. Raeder G.: A survey of current graphical programming techniques. Computer 14 (1985), 11-23.

23. Simkin S., Bartlett N., Leslie A.: JAVA Programming Explorer. Coriolis Group Books, Scottsdale, 1996.

24. Teege G., Koch M.: Integrating access and collaboration for multimedia applications. In: P. Brusilovsky, ed. Proceedings of East-West International Conference on Multimedia, Hypermedia and Virtual Reality. ICSTI, Moscow (1994), 170-175.

25. Weaver M.T., France R.K., Chen Q.-F., Foix E.A.: Using frame-based language for information retrieval. International Journal of Intelligent Systems, 4 (1989), 223-258.

26. Wirfs-Brock R.J., Johnson R.E.: EYING Current research in object-oriented design. Communications of the ACM 33 (1990), 104-124.

27. Wirth N.: From programming language design to computer construction. Communications of the ACM 32 (1989), 160-164.