Oberon (Programmiersprache)

Oberon ist eine von Niklaus Wirth und Jürg Gutknecht entwickelte, objektorientierte, streng strukturierte Programmiersprache. Sie ist den ebenfalls von Wirth entworfenen Vorgängern Pascal und Modula-2 recht ähnlich, allerdings strukturierter und mächtiger als Pascal, gleichzeitig aber erheblich weniger umfangreich als Modula-2. Die Definition der Sprache war Anfang 1986 abgeschlossen. Das Oberon System ist ein eigenständiges Betriebssystem der ETH Zürich, das in der Sprache Oberon implementiert ist, als Entwicklungsgrundlage für die Sprache diente und ebenso wie der Compiler kostenlos erhältlich war.

Oberon
Basisdaten
Paradigmen:	imperativ, strukturiert, objektorientiert
Erscheinungsjahr:	1987
Designer:	Niklaus Wirth
Entwickler:	Niklaus Wirth, Jürg Gutknecht
Beeinflusst von:	Pascal, Modula-2
Beeinflusste:	Component Pascal, Active Oberon, Zonnon
Lizenz:	unbekannt
projectoberon.net

Überblick

Einordnung

Oberon ist das Ergebnis eines Forschungsprojekts, eine Programmiersprache und ein Betriebssystem für Arbeitsplatzrechner zu entwickeln. Wirth und Reiser führten die Motivation für das Projekt auf die Zeit der Implementierung des persönlichen Rechners zurück. So hätten die damaligen üblichen Betriebssysteme beim Umsetzen der Prinzipien der Softwaretechnik versagt. Dazu seien eine voreilige Flucht in Standards gekommen sowie Programme, die Schichten auf veraltete Grundsysteme stapelten. Die Softwaretechnik habe einen wirtschaftlichen Mitteleinsatz und die Einfachheit der Lösungen vermissen lassen. Als Leitmotiv für das Projekt zitierten sie Einstein: „Mach es so einfach wie möglich, aber nicht einfacher.“ Das Projekt wurde nach dem größten Mond des Planeten Uranus benannt, dessen Monde zu dieser Zeit von einer Voyager-Raumsonde fotografiert wurden. Oberon sei auch der Name des Elfenkönigs.

Die Entwicklung von Oberon begann 1985 und mündete in einer vollständigen Definition der Sprache Anfang 1986 als Ergebnis einer Kooperation zwischen Niklaus Wirth und Jürg Gutknecht. Der dazu veröffentlichte Report umfasst lediglich circa 16 Seiten.

Ein Ziel der Programmiersprache Oberon war es, den erweiterbaren Entwurf zu unterstützen. Während ihr Vorgänger Modula-2 zwar strukturierte, modulare und hierarchische Programmierung erlaubt, um Abstraktionsebenen einzuführen, fügt Oberon die Erweiterbarkeit von Datentypen hinzu und zwar derart, dass erweiterte Typen kompatibel mit ihren Ausgangstypen bleiben. Modula-2 bietet dieses Merkmal nicht. Reiser und Wirth sahen darin die eigentliche Neuerung der „in den achtziger Jahren zur Modewelle avancierten objektorientierten Sprachen.“ Diese hätten darüber hinaus mit dem Ziel eines Paradigmenwechsels altbekannte Konzepte umbenannt. Aus Variablen wurden Instanzen, aus Prozeduren Methoden und aus dem Prozeduraufruf das Senden von Meldungen. Oberon hingegen blieb bei den Begriffen des Datentyps und der Prozedur, um einen „Bruch mit der Tradition“ zu vermeiden.

Die nachfolgende Tabelle zeigt einen Terminologienvergleich zwischen der objektorientierten Programmierung (OOP) und Oberon.

Terminologienvergleich

OOP-Terminologie	Oberon-Terminologie
Klasse	Zeigertyp, der einen Record-Typ mit Prozedurvariablen referenziert, welcher einen abstrakten Datentyp definiert
Objekt	Zeigervariable, die auf eine Record-Variable dieses Typs zeigt
Methode	Eine Prozedur des Record-Typs
Meldung senden	Aufruf einer dynamisch gebundenen Prozedur
Unterklasse (Subclass)	Erweiterter Record-Typ
Oberklasse (Superclass)	Basistyp einer Erweiterung
Vererbung (Inheritance)	Typerweiterung
Überschreiben einer Methode	Ändern der einem Record-Feld zugewiesenen Prozedur in einer Erweiterung
Empfänger (Receiver)	Das als Parameter übergebene Objekt bei einem Prozeduraufruf
Super-Aufruf	Aufruf einer Prozedur, die an den Basistyp einer Erweiterung gebunden ist
Dynamisches Binden	Aufruf einer Prozedurvariablen

Oberon hat im Vergleich zu seinem Vorgänger Modula-2 einen verminderten Befehlsumfang. In der damit erreichten Vereinfachung und Vereinheitlichung sahen Reiser und Wirth „echten Fortschritt“ beim Vermitteln wissenschaftlicher Grundlagen, da die Ausdruckskraft Oberon erhalten bliebe.

Oberon wurde wie auch schon Modula-2 parallel zu einer Workstation, in diesem Fall Ceres, entwickelt. Oberon fand nach seiner Veröffentlichung unter anderem zu Bildungszwecken in Lehreinrichtungen Verwendung. Es existierten seinerzeit auf Oberon basierende, ebenfalls kostenlos verfügbare Werkzeuge, die auch kommerziell eingesetzt wurden, wie zum Beispiel die Programmiersprache Component Pascal und die integrierte Entwicklungsumgebung BlackBox Component Builder.

Wirth veröffentlichte Revisionen von Oberon in den Jahren 2007 und 2016. Im Rückblick wies er darauf hin, dass Oberon (im Jahr 2021) an „vielen Stellen“ im Einsatz gewesen sei, konstatierte jedoch, dass ein Durchbruch von Oberon im Gegensatz zu Pascal aufgrund „komplexer, kommerzieller Systeme mit weiter Verbreitung“ nicht stattgefunden habe.

Besonderheiten

Hanspeter Mössenböck und Wirth haben Oberon mit wenigen Ergänzungen zur Programmiersprache Oberon-2 weiterentwickelt, die kompatibel zu Oberon ist. Wesentlich ist die Aufnahme von Prozeduren in den Befehlsumfang, die als Teil des Datentyps eines Objekts definiert werden können. Eine solche Prozedur erhält stets bei ihrem Aufruf eine Referenz auf das Objekt, über das ihr Aufruf erfolgt ist. Bei Oberon muss in diesem Fall eine Prozedur zunächst einer Prozedurvariablen des Objekts zur Laufzeit zugewiesen und, sofern benötigt, eine Referenz auf das Objekt als Parameter der Prozedur bei ihrem Aufruf übergeben werden. Ferner wurden unter anderem die For-Schleife und die Exportmarkierung - (als Alternative zu *) eingeführt, letzteres, um Variablen oder Objektkomponenten schreibgeschützt sichtbar zu machen.

Mössenböck bezeichnet die Frage, ob die Konzepte des Moduls und der Klasse in Oberon gleichzeitig vorhanden sein müssten, als berechtigt, da beide eine Datenstruktur verstecken und nur über Prozeduren zugänglich machen können. Er begründet das gleichzeitige Vorhandensein mit einer unterschiedlichen Sichtbarkeit. Das Modul regelt die Sichtbarkeit von außen, während innerhalb eines Moduls sämtliche Bestandteile der enthaltenen Klassen sichtbar sind.

Oberon sieht verglichen beispielsweise mit dem standardmäßigen Verhalten von C++ eine automatischen Speicherbereinigung (garbage collection) vor. Damit wird die Verwendung von Programmanweisungen zur Deallokation des von Objekten im Heap belegten Speichers obsolet. Wird erneut freier Speicher für ein Objekt im Heap benötigt, wird dort zunächst der Speicher von allen Objekten freigegeben, die aus keinem der geladenen Module mehr referenziert werden.

Oberon verlangt, dass Operanden in Ausdrücken und die Bestandteile von Wertzuweisungen kompatibel sind, und nennt diese Forderung strenge Typisierung. Ein Compiler kann so prüfen, ob Ausdrücke oder Zuweisungen sinnvoll sind, so dass Programmierfehler bereits vor der Programmausführung erkannt werden.

Der im Rahmen des Oberon-Projekts von Wirth und Gutknecht entwickelte Compiler – Wirth hielt die Entwicklung einer Programmiersprache ohne einen dazugehörigen Compiler für anmaßend und unprofessionell – für die NS-32000-Mikroprozessorarchitektur hatte zum Ziel, selbst kompakt zu sein und eine schnelle Übersetzung von Quelltext in effizienten und knappen Maschinencode aufzuweisen. Der erzeugte Maschinencode überprüft standardmäßig zur Laufzeit, ob der für einen Zugriff auf ein Array-Element verwendete Index in dem Bereich liegt, der bei der Deklaration des Arrays im Quelltext angegeben wurde. Ist dies nicht der Fall, liegt ein Fehler vor und die Programmausführung wird abgebrochen. Da die Indexprüfung einen zusätzlichen Laufzeitaufwand nach sich zieht, erlauben dieser und andere Compiler, sie per Option abzuschalten.

Der Compiler erzeugt ebenso eine Liste von Zuordnungen zwischen Prozeduren und Variablen im Quelltext und dem entsprechend erzeugten Maschinencode. Damit kann im Fehlerfall bei einem Programmabbruch der letzte Zustand der Programmausführung angezeigt werden hinsichtlich der Folge der aufgerufenen Prozeduren und deren Variablen. Das dazu verwendete Werkzeug ist üblicherweise ein symbolischer Debugger.

Die Quelltexte der Compiler waren in der Regel frei verfügbar. Es gab verschiedene integrierte Entwicklungsumgebungen wie zum Beispiel POW!.

Die Zeit, die ein Compiler benötigt, um seinen eigenen Quelltext in Maschinencode zu übersetzen, auch Selbstübersetzungszeit genannt, kann als Maß für die Qualität des Compilers angesehen werden. Die Selbstübersetzungszeit eines Oberon-2-Compilers betrug im Jahr 1991 mit einer DECstation 5000 (MIPS R3000, 25 Megahertz) lediglich 7 Sekunden. (Anmerkung: Auf modernen Computern ist die Taktrate über einhundert Mal schneller, und die Selbstübersetzungszeit beträgt damit deutlich weniger eine Zehntelsekunde. Zum Vergleich: Im Jahr 1985 dauerte die Selbstübersetzung für den Modula-2-Compiler von Niklaus Wirth auf einem Lilith-Computer (vergleichbare Rechenleistung wie eine VAX 750) knapp zwei Minuten.)

Code-Beispiele

Hello World im Ulmer Oberon-System:

MODULE HelloWorld;

IMPORT Write;

BEGIN

   Write.Line ("Hello World");

END HelloWorld.

Die objektorientierte Programmierung wird mit erweiterten Datenverbünden vom Datentyp RECORD erreicht. Die Definition von Methoden wird durch typengebundene Prozeduren, und die Definition von Sichtbarkeiten durch Exportmarkierungen (* für Schreib- und Lesezugriff und - für Lesezugriff) erwirkt. Beispiel in Oberon-2:

MODULE Vererbung;

TYPE

   GraphischesObjekt* = POINTER TO GraphischesObjektBeschreibung; (* Das nachgestellte Malzeichen kennzeichnet einen Datentyp, der exportiert wird *)
   GraphischesObjektBeschreibung = RECORD farbe*: LONGINT; END; (* Das nachgestellte Malzeichen kennzeichnet ein exportiertes Attribut, auf das wahlfrei zugegriffen werden kann *)

   Punkt* = POINTER TO PunktBeschreibung;
   PunktBeschreibung = RECORD (GraphischesObjekt) x*, y*: LONGINT; END; (* Punkt erbt die Eigenschaft "farbe" von GraphischesObjekt *)

   Linie* = POINTER TO LinienBeschreibung;
   LinienBeschreibung = RECORD (GraphischesObjekt) xStart*, yStart*, xEnde*, yEnde*: LONGINT; END; (* Linie erbt die Eigenschaft "farbe" von GraphischesObjekt *)

PROCEDURE (punkt: Punkt) Zeichne*; (* typgebundene Methode "Zeichne" für Instanzen vom Typ "Punkt" *)
BEGIN
   ...
END Zeichne;

PROCEDURE (linie: Linie) Zeichne*; (* typgebundene Methode "Zeichne" für Instanzen vom Typ "Linie" *)
BEGIN
   ...
END Zeichne;

CONST

   ROT = 00000FFH; (* RGB *)

VAR

   punkt: Punkt;
   linie: Linie;

BEGIN

   NEW (punkt);
   punkt.farbe := ROT;
   punkt.x := 1;
   punkt.y := 1;
   punkt.Zeichne ();

   NEW (linie);
   punkt.farbe := ROT;
   linie.xStart := 1;
   linie.yStart := 1;
   linie.xEnde  := 2;
   linie.yEnde  := 2;
   linie.Zeichne ();

END Vererbung.

Attribute, die nur einen Lesezugriff haben, können durch typengebundene Prozeduren (Methoden) verändert werden. Beispiel in Oberon-2:

MODULE Schreibschutz;

TYPE

   Objekt* = POINTER TO Objektbeschreibung; (* Das nachgestellte Malzeichen kennzeichnet einen Datentyp, der exportiert wird *)
   Objektbeschreibung = RECORD x-: INTEGER; END; (* Das nachgestellte Minuszeichen kennzeichnet ein exportiertes Attribut, auf das nur lesend zugegriffen werden kann *)

PROCEDURE (objekt: Objekt) SetzeX* (wert: INTEGER); (* typgebundene Methode "SetzeX" *)
BEGIN
   objekt.x := wert; (* Schreibzugriff auf das Attribut "x" nur in typgebundener Methode *)
END SetzeX;

VAR

   objekt: Objekt;
   int: INTEGER;

BEGIN

   NEW (objekt); (* Erzeugen einer anonymen Variable vom Typ "Objektbeschreibung" und Initialisieren des Zeigers "objekt", der damit diese Variable referenziert *)
   objekt.SetzeX (1); (* Schreibzugriff auf das Attribut "x" nur über Methodenaufruf *)
   int := objekt.x; (* Lesezugriff auf das Attribut "x" auch über Zuweisung *)

END Schreibschutz.

Weiterentwicklungen

Ausgehend von Oberon und Oberon-2 sind die Programmiersprachen Component Pascal, Active Oberon und Zonnon entstanden.

Siehe auch

• Oberon microsystems

Literatur

• Hanspeter Mössenböck: Object-Oriented Programming in Oberon-2. 2. Auflage. Springer-Verlag, 1993, 1994 (englisch)
• Martin Reiser, Niklaus Wirth: Programmieren in Oberon. Das neue Pascal. Addison-Wesley, 1994, ISBN 3-89319-657-9 (338 Seiten, 2. korrigierter Nachdruck 1997). 
• Martin Reiser, Niklaus Wirth: Programming in Oberon. Steps Beyond Pascal and Modula. Addison-Wesley, 1992, ISBN 0-201-56543-9 (englisch, 336 Seiten). 
• Niklaus Wirth, Jürg Gutknecht: Project Oberon. The Design of an Operating System and Compiler. 1. Auflage. Addison-Wesley, 1992, ISBN 0-201-54428-8 (englisch, 548 Seiten). 
• Martin Reiser: The Oberon System. User Guide and Programmer’s Manual. 1. Auflage. Addison-Wesley, 1991, ISBN 0-201-54422-9 (englisch, 300 Seiten). 

Weblinks

• Project Oberon. 10. Januar 2021, abgerufen am 16. November 2023 (Project Oberon is a design for a complete desktop computer system from scratch.).