"Das Schlagwort der 80er Jahre heißt Objektorientierung" schreibt Brad J. Cox in seinem Buch "Objektoriented Programming". Offenbar ist der Terminus auf dem besten Weg auch in den 90ern weiter Kariere zu machen, und zwar deshalb, weil nach den zahlreichen theoretischen Erörterung jetzt eine ebenso große Anzahl brauchbarer Implementierungen auf den Markt kommen werden.

Bei Objektorientierung denkt man sofort an Programmiersprachen wie Smalltalk, C++ oder Modula-2. Diese moderne Konzeption sollte allerdings auch durch entsprechende Betriebssysteme sowie Hardwareeinrichtungen unterstützt werden. Erst durch eine geschickte Kombination aus objektorientierter Sprache, Betriebssystem und Hardware läßt sich ein Höchstmaß an Leistung und Funktionalität erreicht.

Was Objektorientierung bedeutet

Viele andere Konzepte der Informatik profitieren von der objektorientierten Betrachtungsweise der zu untersuchenden Themen. Um die Wichtigkeit des Konzepts Objektorientierung zu verdeutlichen, seien ein paar Beispiele für objektorientierte Lösungsvorschläge genannt, die nicht nur Programmiersprachen betreffen.

- Das wesentlich Neue in der Entwicklung der Rechnerarchitektur IBM System/370-XA, ESA/370, ist der Objektbegriff. IBM war offensichtlich Objektadressierung und -schutz so wichtig, daß sie dafür eigens eine Erweiterung der 370-XA-Architektur einführte.

- Die großen Softwarehäuser, wie etwa die Software AG, planen als nächstes objektorientierte Lösungen für komplexe Anwendungen. Das Datenbanksystem Adabas will man auf Basis des Entity-Relationship-Modells (ERM) erweitern (Entities entsprechen Objekten).

- Eine Aufstellung eines ERM empfiehlt auch Professor Dr. A.-W. Scheer von der Universität des Saarlandes für ein Unternehmensdatenmodell als Anfangsaufgabe bei CIM-Konzeptionen.

- Anbieter relationaler Datenbanksysteme experimentieren mit der Erweiterung des Relationenmodells zur Unterstützung von Objekten. So zum Beispiel Relational Technology Inc., die an einem Folgeprodukt für das relationale Datenbankmanagementsystem Ingres: Postgres (PostIngres) arbeitet.

Grundprinzip der Objektorientierung ist, daß Daten, Programme, Geräte-Konfigurationen nur über festgelegte Schnittstellen verändert werden können. Jedes Objekt besteht aus einer Einheit von Daten (instances) und Funktionen (methods), die auf denselben operieren. Nur diese, den Objekten angehörende Funktionen können die Daten des Objektes lesen oder verändern. Um ein Objekt verändern zu können, muß man

erstens: die Methoden - Funktionsaufrufe in konventionellen Programmiersprachen - benutzen, die für das Objekt zugelassen sind und zweitens: die Zugriffsberechtigung zu diesen Objekten besitzen.

Ein Projektleiter oder Systemadministrator legt fest, wem welche Objekte zugänglich gemacht werden dürfen und welche Schnittstellen (Funktionen) zur Verfügung gestellt werden.

Die innere Struktur von Objekten (Daten und Funktionen) sind nur dem Entwickler bekannt. Ein Projektleiter oder Systemadministrator legt fest, wem welche Objekte zugänglich gemacht werden dürfen.

"Objektschutz" VLSls-gestützt

Es ist heute schon möglich, Rechnerarchitekturen zu schaffen, die ein "Knacken" der Objekte zusätzlich über hardwareimplementierte Sicherheitseinrichtungen erschweren oder sogar unmöglich machen. So hat zum Beispiel BiiN, ein Joint-Venture der Unternehmen Siemens und Intel, eine Rechnerarchitektur entwickelt, die spezielle Mechanismen zur Unterstützung des objektorientierten Programmierkonzepts bietet.

Bevor die grundsätzlichen Vorteile von Objekt-Architekturen angesprochen werden, seien hier die zwei wesentlichen nicht-objektorientierten Systemarchitekturen einer objektorientierten gegenübergestellt.

In der Supervisor/User-Architektur wird jeder Benutzerprozeß (usermode) in einen eigenen Adreßraum gelegt. Dadurch werden sowohl das Betriebssystem als auch andere Benutzerprozesse von irrtümlichen oder böswilligen Fehleradressierungen geschützt. Das Betriebssystem selbst läuft in supervisor mode, in dem alle Adreßbereiche zugänglich sind. Fast alle gängigen Risc-Architekturen arbeiten mit dieser Architektur. Die wesentlichen Probleme dieser Architektur bestehen darin, daß

þein Fehler im Betriebssystem, welches in Supervisor-mode läuft, alle Strukturen anderer Betriebssystemdienste und Anwendungsprogramme beschädigen/zerstören kann

þein neues Softwarewerkzeug, welches man als eigenständigen Prozeß wegen Sicherheitsbedenken im User-Adreßraum ablaufen läßt, kann mit anderen Prozessen nur über die langsame Interprozeßkommunikation in Verbindung treten.

þman prinzipiell nicht zu einer hohen Sicherheitsklassifizierung wie etwa B3 (laut "Orange Book") gelangen kann und daher von vornherein für bestimmte Anwendungen - etwa für das Mission-Critical Computing - ausscheidet.

Die Ringarchitektur ist eine Verallgemeinerung obiger 2-Adreß-Bereich-Architektur (user/supervisor). In der Ringarchitektur existieren mehrere hierarchisch gegliederte Adreßbereiche, die man sich ringförmig denken kann, wobei jeweils ein Ring auf alle weiter außen liegenden Speicherbereiche Zugriff hat. Hinsichtlich Sicherheit, Zuverlässigkeit und Performance ist diese Architektur der ersteren überlegen. Typische Vertreter dieser Architektur sind die Prozessoren Intel 80286/386 und die VAX-Prozessoren, die mit vier Ringen ausgestattet sind. Auch wenn es prinzipiell möglich ist, mit dieser Methodik A1-Sicherheit zu erreichen, gibt es auch hier Mängel:

- In den meisten Ringarchitekturen ist der virtuelle Adreßraum auf 2**32 Bytes oder weniger beschränkt. Da dieser Speicherraum alle Ringe einschließt, treten in Systemen mit sehr vielen Systemdiensten Platzprobleme für Anwendungen auf.

- Die Zahl der Dienstprogramme ist größer als die Zahl der Ringe. So passiert es zwangsläufig, daß oftmals unabhängige Werkzeuge im selben Ring zu finden sind. Das führt zu folgendem Problem: Will man ein neues Dienstprogramm einführen, das vor denen im Ring n geschützt sein soll, so muß man es mindestens im Ring n-1 unterbringen. Dort aber ist unter Umständen schon ein Programm, das man wiederum vor diesem neuen Dienst schützen will. Ein dazwischengelegener Ring existiert aber nicht.

- Eine Ringstruktur erzwingt Hierarchien für Programme, für die eine solche keinen Sinn macht. Außerdem kann ein Tool im Ring n prinzipiell jedes andere, im Ring n + x beeinträchtigen.

Auf Benutzerebene unmöglich

Die oben genannten Mängel treffen die objektorientierte Architektur nicht. Positiv formuliert kann man ergänzend konstatieren:

þDer virtuelle Adreßraum für einen einzelnen Prozeß kann bei Objektadressierung über die

2**32-Byte-Grenze hinausgehen. Darüber hinaus werden die virtuellen Adreßräume von

Dienstprogrammen von denen der Anwendungsprogramme getrennt, so daß mit deren

Anwachsen hinsichtlich Größe und Anzahl keine Beeinträchtigungen für

Anwendungssoftware verbunden sind.

þDie Zahl der Adreßräume unterliegt keinen durch die Systemarchitektur bedingten

Einschränkungen. Dadurch kann prinzipiell jedes Programm in mehrere gegeneinander

geschützte Adreßbereiche zergliedert werden.

þEs existieren keine künstlichen Hierarchien zwischen Adreßbereichen. Jedes

Dienstprogramm hat exakt nur zu den Diensten Zugriff, die zu seiner Funktionalität

erforderlich sind.

Objekte werden über Objektzeiger identifiziert, diese wiederum durch ein sogenanntes Tag-Bit von anderen Maschinendaten unterschieden. So ist zum Beispiel der Systembus 32 + 1 Bit breit, um die Konsistenz der Objektzeiger zu gewährleisten. Die Verwaltung der Tag-Bits ist tief im System verankert, so daß das Erschleichen von Objektzugriffsmöglichkeiten durch Manipulation von Objektzeigern auf Benutzerebene nicht möglich ist. Das Eindringen von Viren (wie zum Beispiel des sogenannten "Morris-Virus") wird dadurch verhindert.

Bei Objektzugriffen wird mit Hilfe des eindeutigen Objektzeigers überprüft, ob der Begriff für den Anrufer zulässig ist. Die entsprechenden Überprüfungsoptionen werden von der Hardware unterstützt, um Performanceeinbußen gegenüber herkömmlichen Systemen, die eine solche Überprüfung softwaremäßig durchführen müßten, zu vermeiden.

Weitere Eigenschaften im Dienst von Objekten sind

- Der virtuelle Adreßraum ist in Objekte aufgeteilt. Jedes Adreß-Objekt kann zwischen 64

Bytes und 4 Gigabytes groß sein.

- Jedes Objekt wird über einen "hardware-geschützten" Objektzeiger referenziert.

- BiiN implementiert Objektspeicherung. Objekte sind "Type"-gebunden. Diese

Typenbindung sorgt für zusätzlichen Schutz und Zuverlässigkeit indem Daten nur in streng

kontrollierter Weise manipuliert werden können.

- Objekte werden einheitlich über Zugriffsbezeichner referenziert, ob sie nun im

Hauptspeicher auf der Platte oder einem anderen Knoten im Netzwerk liegen.

Obwohl diese Systemarchitektur völlig neue Wege geht, unterstützt das BiiN-Betriebssystem (BiiN/OS) traditionelle Programme, indem sie diese auf konventionelle "flache" 32-Bit Adreßbereiche abbilden.