3.2 expansion of the type

If, for example, type Viewer is defined in the module by the name Viewers, then type TextViewer can be defined as expansion Viewer (as a rule, in other module, which it is added to the system). Any operation, used to Viewers, can be applied also to TextViewers, and any property, which have Viewers; also it relates also to TextViewers.

Expansibility guarantees, which the modules can be added to the system later, and in this case will be, required neither changes nor recompilations. It is obvious that standard safety appears in this context of critical and must it is free be extended through the boundaries of modules.

Expansion of the type is the typical objective- oriented special feature. In order to avoid misleading anthropomorphism, we prefer to speak "TextViewers they are compatible with Viewers", but not "TextViewers inherit from Viewers". We also avoid the introduction of completely new terms for the well-known concepts; for example, we remain true to term "type", avoiding word "class"; we preserve terms "variable" and "procedure", avoiding new terms "copy" and "method". There is no doubt that our first principle (concentration on the essence) equally to applicable to the terminology.

3.3 example of the type of the data

Let us examine an example of the type of data, which will illustrate our strategy of the construction of basic functionality in the base system, and also special features, added in accordance with the principle of the expansibility of system.

In the system nucleus the type of the data Text is defined as the sequence of symbols with attributes font, offset and color. The basic operations of editing are placed in the module with name TextFrames.

The module of the electronic mail Email is not included in base system, but it can be added on the demand. This new module, being the superstructure above the base system, imports types Text and TextFrame, which make it possible to work with the fragments of text. This means that to the communications obtained on the electronic mail the usual operations of editing can be applied. With the aid of the basic operations these communications can be modified, copied and inserted into other fragments of text, which are aluminized on the display screen. However, as far as the operations, ensured by module itself Email, are concerned, they include the operations of obtaining, dispatch and destruction of communications, and also command for the work with the catalog of mailboxes.

3.4 making more active of the operations

The making more active of operations will be another example, which illustrates our strategy. In Oberone are carried out not the programs and, separate procedures exported from the modules. If the certain module M exports procedure P, then P can be caused by simple indication of line M.P, which is present in any visible on the screen text - i.e., with the aid of positioning of cursor at line M.P with the subsequent flick by the key for mouse. This simple procedure of making more active offers the following possibilities:

1. The frequently utilized commands are represented in the form of the small portions of text. They are called "tool-texts" and resemble the tuned menu, moreover no special program menu- support it is required. Usually they are mapped into small review windows.

2. System can be extended by the simple graphic editor, who ensures the title inscriptions, based on the text lines of Oberon. This makes it possible to perform the illumination of the commands either to decorate with their framework or shadows. As result, the floating up and/or descending menu, buttons and pictograms realize "free of charge" - due to repeated use of a basic mechanism of the making more active of commands.

3. The communication, obtained on the electronic mail, can together with the usual text contain commands. These commands can be performed by way all of the same only flick by the key for mouse, carried out by recipient (without copying of the corresponding section of communication into the special command window). We is utilized this special feature, for example, with the information about the new or modified versions of modules. In this case the communication usually contains commands "receive", which follows the list of the names of the modules, which must be loaded from the network. Entire process requires only several flicks by the key for mouse.

3.5 preserve the system of the simple

Strategy of the support of the system of simple, but expansible, with the interest rewards users without the large ambitions. The nucleus of Oberon occupies less than 200 kbytes - including editor and compiler. Computer system on the basis Of Oberon needs growth only in the case of work with the separately demanding to the presence of computational resources applications, such as automated design and development systems with their significant appetites to the memory. If several such applications are used, system does not require their simultaneous load. This efficiency is reached due to the following properties of system:

1. Modules can load on the demand. Signal to the demand is given either when it is activated the command (which is determined in the yet not loaded module), or when the loaded module imports another module, which does not yet be present. The load of module can be initiated by very fact of demand to the access to the data. For example, when to the document, which contains graphic elements, editor requests access, whose graphic packet is not opened, then this access initiates its load in a concealed manner.

2. In the memory is present only one copy of any module. This rule forbids the creation of the connected loading it is file (usable modules). As a rule, the connected loading files are introduced in the operating systems because the process of binding is complex and requiring there is much time (sometimes even more than compilation). In Oberone the binding cannot be isolated from the load, which is completely acceptable, since it is easy to fix these hard-to-separate processes: they occur automatically, when the first reference to the module is encountered.

3.6 price of simplicity

Experienced engineer, understanding, that free dinners it does not occur, undoubtedly it will ask, but where is hidden the price of this efficiency? The simplified answer is such: in the clear conceptual base and in the well thought-out, adequate structure of system.

For guaranteeing the expansibility of the nucleus of system (or any other module) the designer must understand, as system will be used. Actually, precisely, decomposition to the modules is that aspect of design, which requires the greatest attention. Each module must have accurately specific interface, which specifies the mechanisms of import and export.

Each module also encapsulates the methods of realization. All procedures must be compatible from the point of view of processing the exported types of data. The precision determination of the proper decomposition - this is the complex task, which rarely can be solved immediately, without the subsequent iterations. Certainly, iterative (tuning) improvements are possible up to the time of the production of system into the light.

The rules of design with difficulty yield to generalization. With the determination of the abstract type of data should be thoroughly considered the accompanying collection of base operations; as far as composite operations are concerned, it follows to avoid them. It is possible to say with the confidence - the conventional rule about the need for the final formulation of specification to the realization must be weakened. The fact that the specification is inadequate can be explained, when realization fails.

Conclusion or nine lessons from Oberon.

The following nine lessons, extracted from the project of Oberon, would be worthwhile to have in the form for each, which is been going to undertake the new program project:

1. The exceptional use of the strongly typed language was the factor, to the greatest degree, which determined very possibility of the design of this complex system within so short time. (Realization of comparable in the sizes projects with the support into the language with the weakened typification it would unavoidably require the significant expansion and human, and other resources). Static typification, in the first place, allows for compiler with the high degree of accuracy to identify the possible disagreements before the execution of program; the possibility to change to designer determinations and structures with the smaller danger of negative consequences secondly gives; thirdly accelerates the process of the improvement of system, which includes, probably, such changes, which in another case could not be considered as attained.

2. Most difficult design task is the presence of the most adequate decomposition of system to the hierarchically erected modules, with the minimization of functions and duplicating of the code. Oberon is capable to show a good support in this respect with the aid of the propagation of the mechanism of checking's of types above the boundaries of modules.

3. The being present in Oberon construction of expansion of the type proved to be very essential for the design expansible system, where the new modules added functionality, and the new classes of objects painlessly were integrated into one whole with the already existing classes and the types of data. Expansibility is prerequisite for maintaining the system of sufficiently simple and rational from the very beginning work. It also makes it possible at any time to adapt system to any specific application, moreover without the access to the initial code.

4. Key issue in the expansible system - ramification of those base primitives, who ensure the greatest flexibility with the expansion; at the same time it follows to avoid the growth of the collection of primitives.

5. Is erroneous the opinion that the complex system makes demands on the entire army of designers and programmers. If there is no one individual, who understands project in his full weight or at least to the very significant degree of details, then system not will be constructed with the great probability.

6. In proportion to the growth of the command of designers grow the problems of interaction between them. When these problems begin - clearly or implicitly - to predominate above the meaningful, and command, and project they are immersed in the abyss of large problems.

7. The reduction of complexity and dimensions of system must be priority purpose on each phase of development - with the specification, design and directly programming. The competence of programmers one should judge from the ability to find the simple solutions, but completely not on the "productivity", measured by a "quantity of lines of the code, given out on mountain in the day". Excessively fruitful programmers are capable of leading project to the catastrophe.

8. The only method of the acquisition of experience - this is its own programmer practice. The command, which consists of the managers, designers, programmers, analysts and users hardly by the being intersected functions, hardly it will be viable. All must participate (with different degree of involvement) in all aspects of development. In particular, each - including managers - it must from time to time come out in the role of user. This measure - best guarantee of the correction of errors and also, possibly, the elimination of redundancy.

9. Programs must be ground until they acquire worthy for the publication quality. Certain, to design the program, which can be published, is infinitely more difficult than that, which is simply capable "of being carried out". Programs must be calculated for the people to the same degree and for the computers. If this position comes into conflict with some corporate interests, accepted in the commercial peace, then at least in the academic medium it must not meet with resistance.

We demonstrated with the aid of the project of Oberon, that the flexible and powerful system can be created with the attraction of substantially smaller service lives and in the shorter time than usually. No “law of nature” causes the epidemic of the uncontrollable increase in the dimensions of software. It is possible to avoid this, and precisely engineer-programmer is called to intercept any redundancy in the programs developed by it.

Niklaus Wirth
Swiss Federal Technological Institute, Zurich