The ModulaTor logo 7KB

The ModulaTor

Oberon-2 and Modula-2 Technical Publication

Ubaye's First Independent Modula-2 & Oberon-2 Journal! Nr. 6, Jul-1995

Oberon in Education

This is a summary of Prof. J. Gutknecht's talk, which he gave in German at the Oberon Day 1994, ETH-Zuerich

Copyright (1995) by Guenter Dotzel

Designing software systems is equally different from conventional programming as is any architectural composition of bricks in comparison to manufacturing of individual bricks. The former allows to create complex structures (buildings) out of simple units (bricks) and is called "programming in the large".

Oberon is simultaneously the name of an (operating) system and of a programming lnaguage language [Wirt 92, Reis 92]. Using one and the same name for system and language reflects entity and integration.

Having evolved from an evolution process over decades [Wirt 88], Oberon establishes a significant progress to tackle large projects. It's quite important how a programming language design emerged. Oberon is teachable as it is, because the design passed through all stages of software engineering.

In contrast to other object oriented languages such as C++, which is an integrating pot of many different low- and high-level concepts, Oberon (a) cleanly separates different concepts and - conversely - (b) unifies similar or equal constructs.

C++ is essentially a combination of C - which is nothing much more than a structured assembly language - and a conglomerate of different concepts such as functions, files, types, classes, inheritance, reusability etc.. Hence it is difficult to teach individual concepts with C++. C++ can be compared to different meals, all made with the same sauce.

We can roughly distinguish the following three programming concepts:

1. Modularisation

Modularisation is an important concept for programming in the large. Every module hierarchy is static, though extensible. Static structures allow better consistency checks (at compile- and run-time) and provide both good overview and readability.

A good example of a non-trivial modular structure is the Oberon System [Wirt 92] itself.

With modular systems, the gap between system and application programmers is eliminated. Programmers unifiedly use abstract module interfaces to import from. An example for a functional modularisation in the Oberon System is the text sub-system [Reis 92], which is responsible for handling texts, fonts, and display representations.

2. Abstract data types (ADT)

Abstract data types provide an abstract representation of objects, together with a complete set of operations. An example for an ADT in the Oberon System are files [Reis 92]. Module Files exports a complete ADT File, together with all necessary operations.

3. Class Design

Class design is used to create a specialisation-chain of object types. Such a chain is typically short, mostly only two levels. The first level is highly abstract ("virtual") and each concret realisation represents a specialisation thereof. Polymorphy [Moes 93] at run-time allows to select dynamically the associated operations.

While modules typically provide a hierarchy of importable functionality, classes establish a basis of inheritance. It should explicitly be pointed out that inheritance is not the same as import: The two concerns of reusing functionality and polymorphic behaviour are quite different. In typical OOP-languages, there is only a class construct and no module hierarchy, so that the two concepts import and inheritance are unfortunately entangled. A typical representative of such a model is Smalltalk.

In Oberon, class and type are unified concepts. This is reasonable because classes and types can be looked at as merely two different views of the same construct. Nevertheless, some languages such as C++ provide both, types and classes, thus leading to confusion more than to clarity.

A class in Oberon is simply represented as a record type. Type extension is used as a specialising tool, i.e. for defining sub-classes. Notice that type extension is also used in Oberon to create generic as well as heterogeneous data structures. For example, a heterogenous list is a list of elements whose exact identity can vary. A good example of a heterogeneous data structure in the Oberon System is the display space dag (direct acyclic graph) that is managed by modules Frames and Gadgets [Mare 93].

Another interesting construction in Oberon is generic message interfaces. Such interfaces do not require software designers to fix the set of messages for a given class once and for all. With generic message interfaces, objects can process "unknown" messages, or at least accept and forward such messages to descendants. This is important e.g. for messages that are broadcast into the display space. Also, the type concept allows later extension of the message protocol.

Procedure variables are used in Oberon to represent methods in classes (record types) and for so-called up-calls. Up-calls are usually made by the operating system on demand. A good application of up-calls are generic device drivers, i.e. abstract device drivers that up-call installed functions.

An example for an abstract data type in the Oberon System is provided by the Texts module. Because texts are editable, they have a complex implementation. However, the implementation is hidden behind a narrow and abstract interface, so that clients are neither required to know of the implementation details, nor are they able to corrupt the internals. A further result of such an encaspulation is the freedom to change or modify the implementation without invalidating client modules. Of course, this is an important aspect in large projects.

Oberon as an operating system has many different facettes. It provides

Programming in Oberon is equivalent to extending the module hierarchy. Modules on the top of the module hierarchy can be viewed as application packages or tools, whereas modules at the bottom are system oriented. There might be different types of contents and different requirements concerning the robustness and correctness of modules, depending on their position within the module hierarchy, but their form and structure is uniform through all levels. For example, low-level modules must be of extremely high quality because they cannot be exchanged without restarting the system.

Because of its careful module design, the Oberon System provides a good case study of programming in the large that includes non-trivial examples for ADT and classes. Such examples are of invaluable importance when teaching or learning professional programming concepts. Another important aspect of teaching is transparency and deep understanding of the system to be taught.

With the advances in computer hardware, it is desirable to push software design one step further towards e.g. persistent and visual objects.

A corresponding example in the Oberon System 3 is the Gadgets framework [Mare 93]. Gadgets supports the interactive and programmed construction of persistent objects. Gadgets programming is done in pure Oberon so that Gadgets programmers need not learn a new language. However, to take full advantage of Gadgets and in particular of its facilities to program customized gadgets, programmers need to know about a system-wide message protocol that consists of about six base messages and seven additional messages for visual objects. Skeleton modules in source form are provided for the help to create new gadgets. This is highly beneficial because, in general, modification is much simpler than any new development from scratch.

The object hierarchy in System 3 is rooted in the system kernel by class Objects.Object. It is noteworthy that - thanks to the mentioned decoupling of import and inheritence - the object hierarchy in Oberon is shallow, with a typical depth of three. The concept of objects alone is not sufficient.

An organising tool is needed that allows grouping of objects in collections. In Oberon System 3, such collections are called libraries. In their totality, the object libraries build a hierarchy that accompanies the module hierarchy. While the latter is used to structure the system's functionality, the former organises the system's persistent components.

Short Summary of Oberon Literature

[Mare 93] H.Marais. Gadgets: Principles and Programming. ETH Zurich, 1993.

[Moes 91] H.M~ossenb~ock, N.Wirth. The Programming Language Oberon-2. Structured Programming, Springer Verlag, 1991, 12, 179-195.

[Moes 93] "Object Oriented Programming in Oberon-2" by H. Moessenboeck, Springer-Verlag, 1993.

[Reis 92] "The Oberon System: User Guide and Programmer's Manual" by M. Reiser, ACM Press 1992; ISBN 0-201-54422-9

[Reis 92a] "Programming in Oberon: Steps Beyond Pascal and Modula-2" by M. Reiser and N. Wirth, ACM Press 1992; ISBN 0-201-56543-9

[Wirt 88] "From Modula to Oberon" by N. Wirth Software: Practice and Experience 18,7 (July 1988) 661-670

[Wirt 88a] "The Programming Language Oberon" by N. Wirth Software: Practice and Experience 18,7 (July 1988) 671-690

[Wirt 89] "The Oberon System" by N. Wirth and J. Gutknecht Software: Practice and Experience 19,9 (September 1989) 857-893

[Wirt 92] "Project Oberon: The Design of an Operating System and Compiler" by N. Wirth and J. Gutknecht, ACM Press 1992; ISBN 0-201-54428-8

[Ed. note: Permission for publication of the above article was granted by Prof. Gutknecht in 07-Jun-1995.]

The ModulaTor Forum

There is a new CD-ROM entitled "Modula & Oberon - The Technology of Programming" published by International University of Engineering, Moscow, Mar-1995.

The CD-ROM can be ordered from ModulaWare now. The price is DEM 75.- + shipping (DEM 10.- Europe, DEM 15.- world/air mail).

Recommended reading

The Armchair Universe - An exploration of computer worlds, by A.K. Dewdney, 1998. 330 pages.
Quote from the cover note: Expert programmers and computer-shy neophytes alike will enjoy these games and problems drawn from the Computer Recreations column of Scientific American magazin. With Dewdney's lucid programming directions to follow, you can actually sit at your computer and try your hand at them all.

The Turing Omnibus - 61 excursions in computer science, by A.K. Dewdney, 1989, 415 pages.
Quote from the cover note: Prepare yourself for a wonderfully electric journey through the land of Turing, that ripe mathematical landscape fed by imagination and technology. From artificial intelligence and simulation to computer vision and cryptography, and how computers generate and manipulate random numbers, to simulate real life situations.
Whether your interest is casual or professional, The Turing Omnibus gives you a portable reference you'll read and refer to for years to come.

IMPRESSUM: The ModulaTor is an unrefereed journal. Technical papers are to be taken as working papers and personal rather than organizational statements. Items are printed at the discretion of the Editor based upon his judgement on the interest and relevancy to the readership. Letters, announcements, and other items of professional interest are selected on the same basis. Office of publication: The Editor of The ModulaTor is Guenter Dotzel; he can be reached by tel/fax: [removed due to abuse] or by mailto:[email deleted due to spam]

Home Site_index Contact Legal Buy_products OpenVMS_compiler Alpha_Oberon_System DOS_compiler ModulaTor Bibliography Oberon[-2]_links Modula-2_links [3KB] [Any browser]

Webdesign by, 07-Dec-1998