Entwicklung industrieller Anwendungssysteme

in einer CORBA-basierten Softwarearchitektur

Bogdan Franczyk

Robert Hirschfeld

Torsten Heverhagen

Reinhold Schönefeld

Ulrich Eisenecker

Wilfried Reimann

TU Ilmenau

TU Ilmenau

TU Ilmenau

TU Ilmenau

Daimler-Benz AG

Mercedes-Benz AG

September 1994


Einführung

Viele der in der heutigen Zeit eingesetzten Informationssysteme werden schon geraume Zeit benutzt. Sie wurden mit Hilfe von zum jeweiligen Zeitpunkt verfügbaren Entwicklungsmethoden, Programmierwerkzeugen usw. entwickelt, modifiziert und erweitert [JaLi91]. Es stellt sich oftmals die Frage, entweder bisherige Investitionen in Form von Programmen und Systemen beizubehalten oder von modernen Paradigmen und Methoden der Softwaretechnik zu profitieren. In vielen Fällen versucht man, dieses Problem dadurch zu lösen, daß alte Systeme um neue Merkmale erweitert und dadurch immer umfangreicher werden ("fat software") [Wirt94].

Entwickler und Betreiber sind mit dem Problem nicht weiter wartbarer Softwaresysteme konfrontiert, was eine Fortsetzung der Systempflege zu teuer oder gar unmöglich werden läßt. Ziel ist die Anpassung vieler Softwaresysteme einschließlich ihrer gesamten IV-Infrastruktur an neueste Technologien, um im Wettlauf mit der Zeit nicht zu unterliegen.

Erste Ansätze zur Strukturierung und Organisation von Softwaresystemen zeigen sich im Bestreben, den allgemeinen Begriff der Architektur in den Bereich der Software zu übertragen.

Auf dem 1992 in Dagstuhl abgehaltenen Workshop "Future Directions in Software Engineering" wurde unterstrichen, daß heute die Spezifikation und Konstruktion einer allgemeinen Struktur von Softwaresystemen eine der größten Herausforderungen der Softwaretechnik darstellt. Die Information über die Architektur von Softwaresystemen repräsentiert eine der treibendsten Kräfte in der Entwicklung von Software. In der gegenwärtigen Zeit ist jedoch wenig darüber bekannt, wie man grundsätzliche Entwurfsentscheidungen fällt, Entwürfe in einer brauchbaren Form beschreibt und bestehende Softwaresysteme genau analysiert und vergleicht [THP93].

Auch auf der 15th International Conference on Software Engineering (ICSE 94) wurde das relativ neue Thema der Software-Architekturen in einem Tutorial eingeführt. Trotz regem Interesse war keiner der Teilnehmer willens, den Begriff der Software-Architektur zu definieren [Kobi94].

Anliegen dieser Arbeit ist die Darstellung eines Ansatzes einer Architektur für verteilte objektorientierte Anwendungssysteme. Die Grundprinzipien der Objekttechnologie (Kapselung, Vererbung und Polymorphismus) begünstigen eine stabile, wart- und erweiterbare Strukturierung von Softwaresystemen. In diesem Zusammenhang sind die Standardisierungsbestrebungen der Object Management Group von großer Bedeutung. Durch sie soll eine Vereinheitlichung des objetorientierten Paradigmas, sowohl seiner Grundlagen als auch seiner Terminologie, erreicht werden. Erste kommerziell verfügbare Produkte wie Hewlett-Packards Distributed Smalltalk zeigen die Vorteile der Standardisierungen.

Um solch komplexe Strukturen wie die Architektur von Softwaresystemen beschreiben zu können, ist der Einsatz einer von einem Entwicklungsprozeß unterstützten objektorientierten Modellierungsmethode erforderlich. Im Rahmen dieser Arbeit fiel die Entscheidung auf Objectory, da diese Methode einschließlich Entwicklungsprozeß einige interessante Ansätze liefert.

Bei der Betrachtung einer Architektur für verteilte objektorientierte Anwendungssysteme wurden drei verschiedene Sichtweisen auf diese gewählt. Die Makroarchitektur behandelt mögliche Infrastrukturkomponenten und ihre Zusammenarbeit. Sie modelliert das Gesamtsystem. Der interne Aufbau einer Applikation wird durch die Mikroarchitektur beschrieben. Der allgemeinen Akzeptanz des Client/Server-Konzeptes, dessen Verfeinerung durch OMG-Aktivitäten und der zunehmenden Dezentralisierung der Informationsverarbeitung zufolge ist eine Betrachtung von Aspekten der Verteilung verschiedenster System- und Applikationsteile ebenfalls notwendig.

Software-Architekturen sind Strukturierungs-Paradigmen, Stile und Muster, die ein Softwaresystem beschreiben. Systeme mit konzeptueller Klarheit und Vollständigkeit sind leichter verständlich, modifizierbar und erweiterbar als andere. Die Einfachheit solcher Systeme ist ein Ausdruck einer wohldurchdachten Architektur bzw. Grundstruktur.

Obwohl es im Zusammenhang mit Software noch keine Festlegung des Architekturbegriffs gibt, existiert ein von allen geteiltes Grundverständnis für diesen [And+93].

Software-Architektur beschäftigt sich mit der Organisation von Software-Systemen, also:

Software-Architektur behandelt nicht nur Systemstruktur, sondern auch Funktionalität, Performance, Verständlichkeit und vieles mehr. Keine Architektur wird alle Wünsche erfüllen (bzw. allen Anforderungen gerecht werden), denn verschiedene Applikationen werden von verschiedenen Architekturen unterschiedlich gut oder schlecht unterstützt [And+93].

Software-Architekturen vereinigen verschiedene Aspekte:

Die Architektur gibt den Entwicklern eine einheitliche Terminologie, ermöglicht das Erkennen von generischen Entwurfsstrukturen und sollte zu wiederverwendbaren Komponenten führen.

Architektur kann auch als Summe der Erfahrungen eines Architekten bei seiner Arbeit verstanden werden. Besseres technisches Verständnis der Paradigmen, erweitertes Wissen über Komponenten und konzeptuelle Mechanismen, ein verbesserter Entwurfsprozeß usw. sind alles nur sichere Ausgangspunkte für einen kreativen Architekten und kein Ersatz für diesen.

Durch Architektur wird es erst möglich, über Systeme zu reden, ohne dabei Details zu besprechen [And+93].

Megaprogramming, ein auf der DARPA 1990 (DARPA Software Technology Conference) eingeführter Begriff, soll die Ausweitung der Software Technologie auf sehr große Systeme, bestehend aus verteilten Software-Komponenten in heterogenen Netzwerken, motivieren [Weg+92]. Megaprogramming bezieht sich auf die Entwicklung komplexer Software Stück für Stück (component by component). Die komponenten-orientierte Entwicklung bringt eine höhere Wichtung der Architektur, der Schnittstellen von Komponenten, der Wiederverwendung und eine Minderung der Wichtung der exakten Implementierung der einzelnen Komponenten. Megaprogramming hat nach Johnson [Weg+92] zwei Schlüsselideen:

Megaprogramming = Objects + Glue

(Ralph Johnson)

Systeme wie der Object Request Broker der OMG (Object Management Group) sind eine Möglichkeit für verteilte Moduln, miteinander zu kommunizieren. Der ORB ist dabei der Glue (Kitt, Leim), welcher alle Module über Schnittstellen bedient, die in einer abstrakten Sprache, der Interface-Definition-Language, beschrieben sind. In einem der folgenden Abschnitte erfolgt eine Einführung in die Konzepte der in den Spezifikationen der OMG manifestierten Modelle für verteilte objektorientierte Anwendungen.

Grady Booch [Booc94] vertritt den Standpunkt, daß gute Architekturen dazu tendieren, objektorientiert zu sein. Dies soll weder bedeuten, daß alle objektorientierten Architekturen, noch daß ausschließlich objektorientierte Architekturen gut sind. Booch zeigt in [Booc94], daß auf dem Prinzip der objektorientierten Dekomposition aufbauende Systeme Architekturen hervorbringen, die die allseits gewünschte Eigenschaft der organisierten Komplexität aufweisen.

The complexity of industrial-strength software exceeds the human intellectual capacity.

This complexity seems to be an essential property of all large software systems.

By essential we mean that we may master this complexity, but we can never make it go away.

(Grady Booch)

Software-Architekturen werden aus mehreren, aufeinander aufsetzenden und mit einer wohldefinierten Schnittstelle versehenen Abstraktionsstufen bzw. -schichten konstruiert. Es besteht eine saubere Trennung zwischen Schnittstelle und Implementierung auf jeder dieser Ebenen (Seperation of Concerns), wodurch jede dieser Schichten für den Anwender transparent austauschbar wird. Die Architektur ist einfach gestaltet: gleiches Verhalten wird erzielt durch gleiche Abstraktionen und gleiche Mechanismen.

Component composition has always been the important problem in OOP.

Although inheritance is important, composition is more important.

This will clearly continue in importance as system size scale up.

(Ralph Johnson)

Object Management Architecture

Die Entwicklung verteilter objektorientierter Applikationen erfolgt meist für heterogene, vernetzte, von mehreren Anbietern zusammengestellte Umgebungen. Ein großes Problem dabei ist die Tatsache, daß keine kommerziell verfügbare, allgemein anerkannte und darüber hinaus standardisierte Methode zur Integration bzw. verteilten Verarbeitung existiert.

Die Object Management Group (OMG), eine "not-for-profit"-Organisation, welche 1989 in den USA gegründet wurde, hat sich zum Ziel gesetzt, eine offene Architektur für verteilte Applikationen in einer heterogenen Umgebung und deren Integration unter Ausnutzung der objektorientierten Technologie zu entwickeln und diese durch entsprechende Standardisierungsbestrebungen als Referenz zur Verfügung zu stellen.

OMG - Object Model

Als Grundlage für alle von der OMG erstellten Spezifikationen wurde ein einheitliches Objekt-Modell geschaffen [OMG92, Sole93]. Es wird unterteilt in das Core-Model und die Components. Das Core-Model definiert Begriffe wie z.B. Objekt, Operation, Typ, Subtyping, Identität oder Vererbung, die in allen OMG-Object-Model-konformen Systemen identisch sein müssen. Die Components wiederum ergänzen bzw. komplettieren das Core-Model um die für den entsprechenden Einsatzbereich (z.B. verteiltes Application-Framework oder Relationen zwischen Objekten) relevanten Begriffe.

Abbildung 1: Core-Model, Components, Profiles [Atwo94]

Das Core-Model bildet in Kombination mit ausgewählten Components sogenannte Profiles (z.B. ORB-Profile oder Object-Oriented-Database-Profile), welche gemeinsam eine Familie konformer Produkte beschreiben (Abbildung 1).

Object Management Architecture

Die Object Management Architecture (OMA), Referenzarchitektur der OMG [OMG92], soll die Wiederverwendbarkeit von Komponenten, deren Interoperabilität und Portabilität sicherstellen sowie als Grundlage für kommerziell verfügbare Software dienen. Ziel der OMA ist die netzwerktransparente Kommunikation in heterogenen Systemen auf der Basis objektorientierter Softwarekomponenten. Sie beschreibt den grundlegenden Aufbau eines verteilten objektorientierten Systems.

Abbildung 2: Object Management Architecture [OMG92]

In [OMG92] werden das Anliegen der OMG, technische Anforderungen an verteilte Systeme, ein als Grundlage für alle weiteren Aktivitäten dienendes Objektmodell sowie die OMA selbst vorgestellt.

Die OMG glaubt, durch diesen Ansatz die Lösung des oben genannten Problems zu vereinfachen, da dadurch die Sicht auf verteilte heterogene Systeme vereinheitlicht und durch die Einbringung der Schlüsselkonzepte der Objektorientierung diese verallgemeinert wird.

Die Object Management Architecture gliedert sich in folgende vier Teile, welche im Anschluß vorgestellt werden (Abbildung 2):

Object Services

Die Komponente der Object Services standardisiert die Verwaltung des Lebenszyklus von Objekten, deren Identifikation über Namen, den asynchronen Datenaustausch zwischen Objekten und die Eigenschaft der Persistenz. Es wird Funktionalität zum Erzeugen von Objekten, zur Kontrolle des Zugriffs auf Objekte und die Behandlung von Relationen zwischen Objekten bereitgestellt. Object Services stellen grundlegende Operationen zur logischen Modellierung und physischen Speicherung von Objekten bereit. Alle in den Object Services definierten Grundoperationen (root operations) sollten von allen Klassen implementiert oder ererbt werden. Der Zugriff auf die Operationen der Object Services erfolgt über den Object Request Broker. Object Services sind ebenfalls Bausteine für die Common Facilities.

Die Standardisierung der Object Services führt zur Konsistenz dieser in einer Vielzahl von Applikationen und erhöht darüber hinaus die Produktivität der Entwickler. Object Services sind auf allen Plattformen verfügbar.

Common Facilities

Die Komponente der Common Facilities umfaßt Dienste, die in vielen Problemräumen wichtig und über ein OMA-konformes Objekt-Interface bereitgestellt werden. Diese Komponente erhöht ebenfalls den Grad der Wiederverwendung und damit auch die Produktivität des Entwicklers.

Ein Dienst wird zu einer Common Facility [OMG92, Sole93], wenn er:

Common Facilities unterliegen, wie auch die Object Services, der Standardisierung durch die OMG. Die sind optional und damit nicht auf allen Plattformen verfügbar.

Application Objects

Application Objects sind der Teil der Object Management Architecture, der alle Objekte, welche für Benutzer eine spezielle Aufgabe erfüllen, repräsentiert. Eine Applikation besteht typischerweise aus einer Vielzahl von grundlegenden, für diese Applikation spezifischen Klassen und einer Menge von Common Facilities.

Application Objects können zu Common Facilities werden, wenn sie ihre Dienste über ein allgemeines (OMA-konformes) Objekt-Interface bereitstellen.

Application Objects unterliegen nicht der Standardisierung durch die OMG - hier sind Fachvereinigungen und -organisationen gefragt.

Object Request Broker

Der Object Request Broker ist die Kommunikationszentrale der Object Management Architecture. Er wird von den Object Services, den Common Facilities und den Application Objects zur Interaktion benutzt. Die durch ihn ermöglichte Kommunikation von Objekten ist unabhängig von der Plattform, der Lokation der Objekte sowie deren konkreter Implementierung.

CORBA, die Spezifikation des ORB's, wird im folgenden Abschitt näher beschrieben.

CORBA & COSS

Auf Grundlage der OMA [OMG92] wurde als erste Spezifikation die des Object Request Brokers (CORBA 1.1) erarbeitet [OMG91]. Hierbei soll auf der Basis des ORB ein netzwerktransparenter, hardware-, betriebssystem- und programmiersprachenunabhängiger Aufruf von Operationen eines Objektes in einer heterogenen Umgebung ermöglicht werden.

Abbildung 3: Common Object Request Broker Architecture [OMG91]

Durch den ORB wird ein standardisierter Verteilungsmechanismus bereitgestellt. Der ORB trennt zwischen Clients und Server-Objects. Dabei wird diese Rolle erst zum Zeitpunkt des Aufrufes festgelegt (Abbildung 3).

Das ORB-Interface macht vom ORB bereitgestellte Basisoperationen erreichbar.

IDL-Compiler

Die Interface-Definition-Language (IDL) ist eine von der Implementation unabhängige Spezifikationssprache der von einem Server-Object zur Verfügung gestellten Schnittstelle. IDL ist an die Klassendefinition in C++ angelehnt und unterstützt Mehrfachvererbung zur Erzeugung von Interfaces. Mit IDL sind folgende Komponenten eines Interfaces beschreibbar:

Module (modules) sind nicht Teil einer Schnittstelle. Sie dienen der Gruppierung von zusammengehörigen Schnittstellen.

Ein IDL-Compiler erzeugt aus der IDL-Definition sowohl IDL-Stubs als auch IDL-Skeletons entsprechend des Bindings an eine konkrete Programmiersprache. IDL-Stubs für jedes Interface ermöglichen auf der Seite der Clients den Zugriff auf die in IDL spezifizierten Operationen eines Server-Objects. Auf der Implementationsseite werden in Abhängigkeit vom jeweiligen Object-Adapter IDL-Skeletons als Schnittstellen zu den Implementation jedes dieser Objekttypen erstellt. Object-Adapter (OA) ermöglichen Server-Objects den Zugriff auf vom ORB bereitgestellte Dienste. IDL-Stubs und -Skeletons setzen in Zusammenarbeit mit dem Interface-Repository Requests aus der lokalen Implementationssprache in IDL-Operationen um und umgekehrt.

Interface Repository

Im Interface-Repository (IR) erfolgt die Registrierung der nach außen sichtbaren Schnittstellen von CORBA-Objekten. Das IR ist ein Dienst, welcher IDL-Informationen in Form von persistenten Objekten zur Laufzeit zur Verfügung stellt. Es wird vom ORB bei der Ausführung von Requests benutzt. Der Namensraum, welcher im IR durch entsprechende IDL-Definitionen aufgebaut wird, ist ein anderer als der der Implementation. Dieser Sachverhalt wird in einem späteren Abschitt am Beispiel einer konkreten CORBA-Implementation (HP-DST) verdeutlicht.

Static & Dynamic Invocation Interface

Auf der Seite der Clients existieren zwei Möglichkeiten, Operationen von Server-Objects zu aktivieren. Die erste Möglichkeit ist das Static-Invocation-Interface (SII) oder auch Stub-Interface. Es unterstützt die Anforderung einer bestimmten Operation eines entfernten Objektes. Die zweite Möglichkeit, das Dynamic-Invocation-Interface (DII), repräsentiert ein generisches Interface. Ein Client kann hiermit zur Laufzeit die bis zum Zeitpunkt der Übersetzung nicht bekannte Schnittstelle eines Server-Objects vom Interface-Repository erfragen und daraus den Aufruf einer Operation dieses Server-Objects erzeugen.

COSS

Der erste Teil der Object Services wird im voraussichtlich noch 1994 erscheinenden "Common Object Services Specification" (COSS) [OMG94b] standardisiert. Die in diesem Dokument betrachteten Object-Services sind:

In [OBsp94] wird die Aufnahme eines vierten Services, des Persistent-Object-Service, in die COSS bestätigt.

Distributed Smalltalk

Hewlett-Packard's Distributed-Smalltalk 2.0 (HP-DST) ist eine vollständige Implementierung der aktuellen CORBA Spezifikation [OMG91] sowie aller derzeit durch die OMG standardisierten Object Services [OMG94].

HP-DST wurde vollständig in Smalltalk-80 (VisualWorks) implementiert und ist damit eine Erweiterung des Produkts von ParcPlace. Alle Benutzerschnittstellenelemente von VisualWorks können auch weiterhin wie gewohnt verwendet werden. Ergänzt wurden diese lediglich um den Mechanismus des Drag&Drop. Auch von der Plattformunabhängigkeit und Portabilität von VisualWorks konnte HP-DST profitieren. Lediglich das Vorhandensein der entsprechenden Kommunikationssoftware ist erforderlich.

Der vom Object Request Broker benutzte Kommunikationsmechanismus ist das NCS (Network Computing System) Version 1.5.1, eine Untermenge von DCE (Distributed Computing Environment der OSF), welches über die Smalltalk-Socket-Schnittstelle (Berkeley Sockets) integriert wurde. Die Kommunikation mit DCE-Knoten soll bereits möglich sein.

Abbildung 4: Implementationsumfang von HP-DST

Da die durch die OMG bisher spezifizierten Common Object Services (COSS) für die effektive Entwicklung verteilter objektorientierter Applikationen nicht ausreichen, wurden diese von HP-DST um eine Vielzahl weiterer Services ergänzt (Abbildung 4). Diese Services wurden, soweit entsprechende Requests for Proposal von der OMG vorliegen, zur Standardisierung eingereicht. Den zur Zeit noch nicht standardisierten Common Facilities wären die die Entwicklung von verteilten Smalltalk-Applikationen unterstützenden Werkzeuge von HP-DST zuzuordnen.

HP-DST stellt drei Arten von Images zur Verfügung, mit welchen Arbeitsplätze unterschiedlich konfiguriert werden können (Abbildung 5).

Abbildung 5: Konfiguration von Arbeitsplätzen unter HP-DST

Je Maschine muß genau ein ORB/OA- (Kombination aus Object-Request-Broker und Object-Adapter) oder ORB/RT-Image (Runtime­ORB, ohne Object-Adapter) aktiv sein. Zusätzlich dazu können je Maschine mehrere OA-Images laufen. Für Mehrplatzsysteme sowie die Arbeit im Netz ist nur die Konfiguration mit einem ORB/RT- und mehreren OA-Images zu empfehlen, damit bei möglichen Fehlern (z.B. menschliches Versagen) nicht alle auf der entsprechenden Maschine laufenden bzw. über diese Maschine kommunizierenden Anwendungen hängen bleiben.

Makroarchitektur

Die Makroarchitektur beschäftigt sich mit der Strukturierung von komplexen Softwaresystemen. Durch die Partitionierung eines im Ansatz noch monolithischen Systems in Infrastrukturkomponenten bzw. Subsysteme und der Beschreibung der Interaktionsmöglichkeiten dieser kann auch größere Software wartbarer gestaltet werden. Subsysteme lassen sich einfacher ersetzen, wodurch sich die Abhängigkeit von proprietären Produkten verringert.

Der Ansatz zur Modellierung einer Makroarchitektur basiert auf zum Teil selbst gestellten Anforderungen. Auf diesen Anforderungen und Erfahrungen aus bestehenden Systemen basierend konnten direkt Architekturkomponenten identifiziert werden. Diese Komponenten wurden in das Domain-Object-Model von Objectory übernommen. Die weiteren Schritte bestanden darin, Beziehungen zwischen diesen Komponenten zu erkennen sowie noch fehlende Komponenten, welche aus verschiedensten Gründen noch nicht berücksichtigt wurden bzw. werden konnten, dem Modell hinzuzufügen. Selbstverständlich müssen alle bis dahin eingeführten Beziehungen und Interaktionsmuster an die ergänzten Komponenten angepaßt werden. In diesem Abschnitt werden die bisher identifizierten Hauptkomponenten der Infrastruktur beschrieben (Abbildung 6).

Abbildung 6: Domain-Object-Model der Makroarchitektur

Der Entry ist der Zugang zum System. Durch ihn hat ein Benutzer die Möglichkeit, sich durch Angabe von Paßwort, Nutzer-ID und evtl. Stellvertreter-ID gegenüber diesem System zu identifizieren.

Der Entry benutzt die Authentication-Komponente, welche die Richtigkeit der Paarung von Paßwort und Nutzer-ID überprüft. Im Fehlerfall wird der Wunsch des Benutzers um Systemzugang abgewiesen, ansonsten natürlich gewährt.

Die Authentication-Komponente erfragt alle für eine entsprechende Überprüfung notwendigen Informationen von einem diese bereitstellenden Repository. Dieses Repository ist nicht nur für die Haltung und Strukturierung von ausschließlich für die Authentication-Komponente wichtige Daten verantwortlich. Es dient vielmehr als für alle Systemdienste und damit -komponenten verfügbare Ablage bzw. Aufbewahrungsort relevanter Informationen unterschiedlichster Art.

Ein Berechtigungssystem (Security-System) hat sich aus den Anforderungen als von besonderer Bedeutung für die gesamte Architektur erwiesen. Es besteht aus folgenden drei Komponenten:

Die Authentication-Komponente wurde bereits im Zusammenhang mit dem Entry vorgestellt. Die Authorisation-Komponente, Bestandteil der Mikroarchitektur einer Applikation aus dem vorherigen Abschnitt, dient dem aktiven Eingriff des Security-Systems in den Ablauf einer Applikation. An Hand von Informationen über Benutzer, zu schützende Objekte sowie statische und dynamische Restriktionen kann der Zugriff auf und die Modifikation des Zusandes bestimmter Objekte beeinflußt werden.

Die Administrations-Komponente richtet die für die beiden anderen Teile des Security-Systems notwendigen Informationsstrukturen ein, pflegt und wartet diese. Ein Beispiel hierfür ist die Zuordnung von Nutzern zu Nutzergruppen und die von Ressourcen zu Ressourcegruppen. Eine Nutzergruppe stellt eine Zusammenfassung von Nutzern dar, die bezüglich einer oder mehrerer Ressourcegruppen die gleichen Rechte haben. Ressourcegruppen sind analog dazu Gruppierungen verschiedener Ressourcen (schützenswerter Objekte). Dabei sollte jede Ressource nur einer Ressourcegruppe angehören. Von Bedeutung ist in diesem Zusammenhang auch die Art der Vergabe von Rechten:

Der additive Ansatz ist beim Schutz von Applikationen als Ganzes denkbar. Ein neuer Benutzer darf, wenn er von einem Systemverwalter neu angelegt wurde, zuerst keine der im System verfügbaren Applikationen benutzen. Berechtigungen auf bestimmte Applikationen müssen vom Systemverwalter explizit zugeordnet werden.

Die Verwendung des subtraktiven Ansatzes ist bei der Vergabe von Berechtigungen innerhalb einer Applikation möglich. Ein Nutzer darf eine Applikation in vollem Umfang verwenden, bis dies durch Einschränkungen seitens des Systemverwalters geändert wird.

Eine weitere Frage, die beantwortet werden muß, ist jene, was in das Zentrum der Schutzbestrebungen gestellt werden soll:

Bei der in HP-DST durch den Presentation/Semantic-Split (siehe Abschnitt über Verteilungsarchitektur) möglichen dreistufigen Architektur der Verteilung ist die Verwendung beider Ansätze möglich. Am Presentation-Object, welches genau einem Nutzer zugeordnet ist, bietet sich der nutzerzentrierte Ansatz an. Der schutzobjektzentrierte Ansatz ist bei einem von mehreren Presentation-Objects und damit potentiell mehreren Nutzern geteilten Semantic-Object sinnvoll.

Eines der wichtigsten Kriterien beim Systementwurf stellen die Einfachkeit und die daraus resultierende Beherrschbarkeit dar. Obwohl viele Möglichkeiten der Integration eines Security-Systems von technischer Seite realisiserbar sind, muß ein Großteil dieser wegen mangelnder Praktikabilität, eingeschränkter Performance oder unsauberem Eingriff in bestehende Komponenten zurückgestellt werden. Desweiteren sollte eine Applikation auch ohne Security-System lauffähig sein.

Für einen Nutzer, der den Entry passiert hat, wird ein Desktop aufgebaut, von welchem er alle Applikationen, für die er eine Berechtigung besitzt, starten kann. Der Desktop kennt alle vom jeweiligen Nutzer aufrufbaren Applikationen. Er ist der Arbeitsbereich des Nutzers. Desktop und Entry können niemals gleichzeitig geöffnet sein. Wenn ein Desktop für einen Nutzer aufgebaut wird, verschwindet der Entry. Analog verschwindet der Desktop, wenn sich ein Nutzer vom System abgemeldet hat und der Entry erscheint, um anderen Nutzern den Zugang zum System zu ermöglichen.

Das Clipboard dient dem Austausch sowie der Duplikation von Daten bzw. Informationen innerhalb von Applikationen und über Applikationsgrenzen hinweg. Es kann Mechanismen wie Cut&Paste, Drag&Drop und den eines Blackboards bereitstellen.

Das Board weist gleiche Funktionalität wie das Clipboard auf, erweitert diese jedoch auf das gesamte Netzwerk. Damit soll die Einrichtung einer formularorientierten Bearbeitung erleichtert werden.

Die Audit-Komponente dient der chronologischen Protokollierung von Ereignissen und Systemzuständen.

Die Help-Komponente übernimmt die Ausgabe von applikationsspezifischem Hilfetext. Hierbei ist, wie auch bei allen anderen Komponenten, die Festlegung einer möglichst allgemeinen Schnittstelle sinnvoll. Ein Protokollwandler (Bridge) kann die Anpassung dieses Protokolls an die Schnittstelle des tatsächlich eingesetzten Hilfesystems vornehmen. Ein Beipspiel für die flexible Einbindung von Komponenten anderer Hersteller in die Umgebung von VisualWorks wird in [HeSm93] gezeigt.

Eine Mail-Komponente dient der Kommunikation der Anwender untereinander (analog E-Mail oder Memo).

Mittels der Meldungskomponente (Message) können Nachrichten über Applikationszustände etc. auf den Bildschirm des Anwenders ausgegeben werden.

Die Administrations-Komponente des Security-Systems ist, wie jede andere denkbare Administrations-Komponente auch, eine spezielle Applikation, da sie Manipulationen der im Repository befindlichen Information durchführen kann.

Um die Schnittstelle einer Applikation zu anderen Architekturkomonenten zu reduzieren, kommuniziert die Applikation immer indirekt mit diesen über den Desktop. Um den Desktop ebenfalls von der Unzahl weiterer Komponenten zu lösen, kam es zur Einführung eines Dispatchers, welcher sich ausschließlich mit der Verteilung von Anforderungen (Request) beschäftigt. Er verwaltet alle Schnittstellen zu den entsprechenden Komponenten.

Die Schnittstellen der Infrastrukturkomponenten lassen sich mittels Aufstellung von Objektszenarios finden. Die Darstellungen von Objektszenarios werden herrvoragend durch die Interaktionsdiagramme Objectory's unterstützt.

Obwohl das bisher vorgestellte Modell der Makroarchitektur in seinen Komponenten einigermaßen stabil erscheint, werden sich die Beziehungen zwischen diesen gewiß noch ändern. Eine der möglichen Veränderungen resultiert aus der Orientierung an der Object Management Architecture der OMG. Sie gibt einen Rahmen zur Klassifikation von Infrastrukturkomponenten und eine einfachere Strukturierungsmöglichkeit als der bisherige Ansatz vor. Eine Ausrichtung an der OMA der OMG ist damit sehr interessant. Aus diesem Grund wird die weitere Verfolgung dieses Konzeptes innerhalb der Makroarchitektur von den Autoren als erfolgversprechend eingestuft.

Mikroarchitektur

Unter dem Begiff Mikroarchitektur soll im weiteren der interne Aufbau einer objektorientierten Applikation verstanden werden. Es werden Applikationskomponenten und deren Interaktion vorgestellt (Abbildung 7).

Abbildung 7: Domain-Object-Model der Mikroarchitektur

Eine Applikation besteht aus einer problemraumspezifischen Lösung (PD-Solution) und einem lokalen Security-System, der Authorisation-Komponente (Authorisation).

Die problemraumspezifische Lösung entsteht durch Verfeinerung aus einem durch andere Entwickler oder kommerzielle Anbieter zur Verfügung gestellten Framework. Frameworks beschreiben das abstrakte Design einer bestimmten für einen Problemraum relevanten Lösung durch Dekomposition in kleinere Einheiten sowie deren Zusammenspiel (Interaktion). Frameworks bereichern diese um die Einführung von Abstraktionen bzw. einer abstrakten Ebene. Frameworks kann man entsprechend ihrer Hauptanwendungsgebiete untergliedern in Frameworks für die Gestaltung von Nutzerschnittstellen (UI-Frameworks), für die Behandlung von Schnittstellen zu Datenbanken (DB-Frameworks) und andere Frameworks, die sich nicht diesen beiden Gruppen zuordnen lassen (Control-Frameworks, analog zu der in [Jac+93] vorgenommenen Klassifikation von Objektarten im Analyse-Modell der Robustheitsanalyse).

UI-Frameworks, wie z.B. das des MVC in Objectworks\Smalltalk, abstrahieren Formen der Interaktion mit Anwendern, strukturieren sie und beschreiben Möglichkeiten der Integration dieser in eine konkrete Applikation. Die grundlegende Idee hinter dem MVC-Konzept [Parc92a] soll nachfolgend kurz vorgestellt werden. Dem Problemraum zugeordnete Informationen können innerhalb einer oder sogar mehrerer Applikationen unterschiedlich aufbereitet und dargestellt werden. Einem Anwender wird oft die Möglichkeit gegeben, durch gewisse Formen der Interaktion diese Informationen zu verändern. Um zwischen der Nutzerschnittstelle und dem restlichen System unnötige Abhängigkeiten zu vermeiden, erfolgt eine Aufteilung in folgende, lose miteinander gekoppelte Einheiten, der sogenannten MVC-Triade:

Durch die Trennung der Nutzerschnittstelle in Komponenten zur Ein- und Ausgabe entsteht die Möglichkeit der freien Kombination dieser. So ist es möglich, einem View, welcher für alle Anwender gleich ist, unterschiedliche Controller, entsprechend den einer bestimmten Nutzergruppe nachgesagten Erfahrungen, zuzuordnen. Ein weiterer Anwendungsfall könnte die Einschränkung bzw. Erweiterung von Manipulationsmöglichkeiten durch, unter Umständen dynamisch veranlaßter Zuordnung entsprechender Controller sein. Die Variation von Views innerhalb der View-Controller-Paare erfolgt analog. Einem Model können mehr als nur ein View-Controller-Paar zugeordnet werden. Um alle von ihm abhängigen Views über möglicherweise relevante Veränderungen zu unterichten, bedient sich das Model des in Smalltalk häufig eingesetzten Mechanismus der Dependencies. Dieser Mechanismus, in der Klasse Object global eingeführt, wird für das Model lokal reimplementiert. Jedes Model hält hierfür ein lokales Verzeichnis aller von ihm abhängigen Applikationsteile einschließlich der Views. Will das Model seine Abhängigen über eine Änderung seiner selbst informieren, so wird ein Folge von Botschaften aktiviert, die alle in der Abhängigenliste eingetragenen Objekte benachrichtigt. Diese wiederum können durch Auswertung eines vom Model gelieferten, die Änderung näher spezifizierenden Aspektes entscheiden, ob sie von dieser Änderung betroffen sind oder nicht. Der Betroffene einer solchen Änderung veranlaßt alles Notwendige, um sich bzw. seinen Zustand mit dem entsprechenden Teil des Models und damit dem durch ihn repräsentierten View zu synchronisieren.

In VisualWorks [Parc92b, Parc92c, Parc94] erfolgt eine Erweiterung des MVC-Konzeptes. In der klassischen MVC-Struktur war das Model für zwei voneinander verschiedene Aktivitäten verantwortlich: die Erfüllung seiner Verantwortlichkeiten innerhalb des Applikationskerns und die Kommunikation mit dem View-Controller-Paar. In VisualWorks wird nun explizit unterschieden zwischen (Abbildung 8):

Abbildung 8: Erweiterung des MVC-Konzeptes in VisualWorks

Bei der Gestaltung von graphischen Nutzerschnittstellen, sei es durch die Definition bestimmter Services oder deren Abstraktion innerhalb von Frameworks, sind einheitliche Bedien- und Darstellungskonzepte von großer Bedeutung [BaWi93]. Breiter Akzeptanz hierfür scheint sich das Look&Feel des Windows-Interface von Microsoft [Micr92] zu erfreuen. Im Rahmen des ChameleonViews von VisualWorks lassen sich die meisten der in [Micr92] enthaltenen Widgets mit nur geringen Abweichungen simulieren. Lediglich die Erzeugung von Multi-Document-Interfaces (MDI's) ist mit VisualWorks nicht möglich. Diese Einschränkung wird in [Brow94] auf die Plazierung der Klasse ApplicationModel innerhalb der Smalltalk-Klassenhierarchie und die daraus resultierenden Eigenschaften zurückgeführt.

Der Einsatz von objektorientierten Datenbanksystemen (ODBMS) erhöht sich in solchen Bereichen wie z.B. Multimedia, CIM und medizinischen Informationssystemen, da innerhalb dieser Anwendungsgebiete komplexe Datentypen (z.B. Sprache, Bilder, Musik) sowie komplexe Relationen zwischen den beteiligten Entitäten bzw. Objekten auftreten. In diesen Bereichen weisen objektorientierte Datenbanksysteme gegenüber relationalen (RDBMS) beachtliche Vorteile auf. Jedoch in vielen Unternehmen, die mit altlastigen Systemen (legacy systems) oder mit Systemen, die eine hohe Zahl von Transaktionen je Zeiteinheit fordern, ausgestattet sind, werden relationale Datenbanken auch weiterhin eine wichtige Rolle im täglichen Geschäft spielen [LaPu93b]. In [Heue93] wird auf die Nachteile des Relationenmodells und der darauf aufsetzenden Systeme detailliert eingegangen sowie deren Lösung unter Zuhilfenahme des objektorientierten Paradigmas in der Welt der Datenbanken aufgezeigt.

DB-Frameworks stellen mögliche Vorgehensweisen zur persistenten Speicherung von Objekten oder, falls eine relationale Datenbank (RDBMS) verwendet werden soll, Mechanismen zur Abbildung von komplexen Objektstrukturen in SQL-Tables zur Verfügung. Ein Beispiel eines Frameworks zur Anbindung einer relationalen Datenbank ist die von VisualWorks ab Version 2.0 mitgelieferte ObjectLens. Sie erlaubt die Abfrage und Manipulation relationaler Datenbestände, als ob diese Objekte seien. Aus vorgegebenen relationalen Tabellen können automatisch Objektklassen erzeugt werden und umgekehrt. Es wird der Entwurf hersteller- und plattformunabhängiger Datenbankanwendungen ermöglicht, ohne dabei weder in Smalltalk noch in SQL programmieren zu müssen [Maie94]. Mit Hilfe des VisualDataModeller erfolgt die Aufbereitung des Datenmodells einer Anwendung. Nach dem Festlegen der Entitäten und deren Beziehungen untereinander werden daraus die benötigten Tabellenbeschreibungen und Smalltalk-Klassen generiert. Darauf aufbauend bestimmt der Benutzer die Arten der Visualisierung und Manipulation dieser Daten. Auf Grundlage dieser Entscheidungen werden automatisch formular- und tabellenbasierte Anwendungsmasken erzeugt [Maie94]. Der QueryEditor ermöglicht die Erstellung weiterer Anfragen und deren Speicherung als Smalltalk-Methoden.

Bei der Betrachtung von DB-Frameworks ist auch die Einordnung des Mappings von Objekt-ID's innerhalb der Datenbank (ODBMS) auf Object-ID's einer CORBA-Umgebung denkbar.

Der momentan durch die OMG standardisierte Persistent Object Service (POS) wird bei einer einheitlichen Lösung dieses Problems weiterhelfen.

Control-Frameworks beinhalten alle weiteren Frameworks, die sich weder mit der Behandlung von Schnittstellen zum Benutzer noch zu einer Datenbank beschäftigen. Ein Beispiel hierfür wäre das in [GoRo89] vorgestellte Framework for Simulations für Smalltalk-80. Es besteht aus den Klassen SimulationObject und Simulation und dient der ereignisgesteuerten Simulation.

Über die mit einem Framework zur Verfügung gestellten Inversion des Kontrollflusses soll das Eingreifen der Authorisation-Komponente des Security-Systems in den Applikationsverlauf sichergestellt werden. Der aktive Eingriff dieser Komponente sollte unabhängig vom Entwickler der entsprechenden Applikation konfigurierbar und aktivierbar sein, da administrative Aufgaben in größeren Systemen meist durch andere Personen, zumindest aber von Personen, die in verschiedenen Rollen innerhalb des Systems agieren, wahrgenommen werden. Bei der Betrachtung der Authorisation-Komponente ist wichtig, was innerhalb einer Applikation geschützt werden kann und was sinnvollerweise geschützt werden soll, d.h. der Schutz sollte nur so umfassend wie nötig und nicht so gut wie möglich sein. Vor der Spezifikation eines Security-Systems sind mehrfache Machbarkeitsstudien erforderlich, um zu erkennen, an welcher Stelle und in welcher Form der Authorisation-Mechanismus im System zu plazieren ist. Diese Entscheidung hat großen Einfluß auf sowohl Performance als auch Wartbarkeit und Konfigurierbarkeit. Als vorerst ausreichend und den oben angeführten Kriterien genügend wird der Eingriff der Authorisation-Komponente an der Schnittstelle zum Benutzer erachtet.

Ein weiterer Eingriff der Authorisation-Komponente wäre an der Schnittstelle zur Datenbank denkbar. Dabei stehen jedoch weniger Sicherheitsinteressen als mehr die Erhöhung der Performance bzw. Reduzierung des Netzwerkverkehrs im Vordergrund. Dies kann durch Optimierung bzw. Einschränkung von DB-Anfragen erreicht werden, was zur Verringerung von z.B. der Konvertierung von Zeilen einer SQL-Table in eine Objektstruktur und der zu übertragenden Datenmenge führt. Die Authorisation-Komponente wird beim Applikationsstart mit allen für die entsprechenden Eingriffe notwendigen Informationen, den sogenannten Startup-Informationen, versorgt. Das bedeutet, das alle nach dem Start der Applikation getätigten Modifikationen innerhalb der Ablage der security-relevanten Informationen erst bei erneutem Start in der jeweiligen Applikation wirksam werden.

Das Framework kann, genau wie der problemraumspezifische Teil, allgemeine Dienste (Services) zur Erfüllung seiner Verantwortlichkeiten benutzen. Diese Dienste werden von einzelnen Klassen, Teams oder Subsystemen einschließlich bereits erfolgter Konkretisierungen bzw. Spezialisierungen anderer Frameworks bereitgestellt. Beispiele für solche Dienste sind die durch die OMG standardisierten Object Services (COSS) Naming, Lifecycle und Event-Notification. Die Klassifikation der Services erfolgt innerhalb des oben abgebildeten Modells der Mikroarchitektur in gleicher Weise wie die der Frameworks.

Der hier beschriebene innere Aufbau einer objektorientierten Applikation erfolgte im Kontext des Domain-Object-Models von Objectory. Auf dieser Abstraktionsstufe ist der dargestellte Umfang durchaus ausreichend. Eine Verfeinerung der Komponenten und ihrer Beziehungen untereinander ist erst in weiteren Stufen der Modellierung sinnvoll.

Verteilungsarchitektur

Presentation/Semantic Split

Der Presentation/Semantic-Split, ein Service von HP-DST, ist ein Mechanismus, der den Entwurf verteilter Applikationen erleichtern soll. Er beschreibt die Erweiterung des MVC-Konzeptes für ein Netzwerk, also über Rechnergrenzen hinaus. Dabei wird ein logisches Objekt in zwei oder mehrere Objekte geteilt. Diese Objekte nennt man dann Semantic- (SO) bzw. Presentation-Object (PO).

Ein Semantic-Object kann sowohl lokal oder entfernt sein. Es kann von mehreren Presentation-Objects geteilt werden und beinhaltet den für alle gemeinsamen Teil an Zustand und Verhalten. Mehrere Presentation-Objects können eine unterschiedliche Sicht auf dieses Semantic-Object haben.

Abbildung 9: Presentation/Semantic-Split

Ein Presentation-Object ist immer lokal und wird auf dem Host-System des Benutzers angelegt. Es ist für die Interaktion mit dem Nutzer zuständig und enthält Applikationsteile (Zustand und Verhalten), die für den entsprechenden Nutzer einmalig sind. Ein Presentation-Object ist selbst keine Komponente des Nutzerinterfaces, enthält diese aber. Zwischen Semantic- und Presentation-Objects besteht eine 1:n Beziehung (Abbildung 9).

Es existieren keine allgemeinen Richtlinien, wo diese Teilung vorzunehmen ist. Der Service des Presentation/Semantic-Split soll der Minimierung der Anzahl von RPC's (Remote-Procedure-Calls) dienen. Er ist ein Beitrag zur Optimierung des Verhältnisses von Communication-Workload zu Computation-Workload.

3-stufige Architektur

Durch den Presentation/Semantic-Split wird der Aufbau der folgenden dreistufigen Architektur nahegelegt (Abbildung 10).

An der dem Benutzer zugewandten Seite befinden sich die Frontend-Systeme. In ihnen werden die Presentation-Objects, welche die gesamte Interaktion mit den entsprechenden Nutzern handhaben, angesiedelt.

Auf der mittleren Stufe agieren Domain-Server, auf denen alle Semantic-Objects gehalten werden. Diese Semantic-Objects werden von verschiedenen den Frontends (Clients) zugeordneten Presentation-Objects geteilt.

Auf der letzten Stufe übernimmt ein Datenbank-Server die Langzeitspeicherung von Daten. Ein vorgeschalteter Prozeß führt Aufgaben aus wie z.B. die Abbildung von Objekt-IDs innerhalb der Datenbank in CORBA-UUIDs (HP-DST) und umgekehrt sowie, falls es sich um eine relationale Datenbank (RDBMS) handelt, das Mapping einer Objektstruktur in SQL-Tables und zurück. Für den Einsatz innerhalb eines objektorientierten Systems ist eine objektorientierte Datenbank (ODBMS) selbstredend von Vorteil.

Abbildung 10: Dreistufige Architektur

Durch diese Abstufung kann eine gute Skalierbarkeit, insbesondere der Frontends (Clients) erreicht werden. Im Gegensatz zu von vielen Datenbankherstellern propagierten zweistufigen Architekturen, die unter Umständen vielfältige Synchronisationen erforderlich werden lassen, kann mit dieser dreistufigen Architektur auch noch bei sehr vielen Benutzern eine gute Performance erreicht werden.

Applikationsentwurf

Die Analyse der Anforderungen

Für den Anwender einer Applikation ist es nicht von Interesse, ob diese verteilt oder lokal arbeitet. Die Anforderungen sowie die Analyse dieser Anforderungen gestalten sich genauso wie für nichtverteilte Applikationen. Die wichtigsten Ergebnisse dieses Entwicklungsabschnittes sollten sein:

Wie in [Jac+93] dargestellt wird, gibt es keine universelle Vorgehensweise, um diese Ziele zu erreichen. Wichtig im Hinblick auf den Reifegrad des Entwicklungsprozesses ist die Dokumentation der einzelnen Arbeitsschritte. Neben dem rein textuellen Fixieren von Anforderungen und notwendigen Begriffsdefinitionen sollte in Objectory das Use-Case-Model [Jac+93] entwickelt werden. Es führt nicht nur zu einer besseren Verständigung mit dem Anwender, sondern auch zu einer Modularisierung der Applikation, wodurch in der späteren Entwicklungsarbeit eine höhere Übersichtlichkeit erreicht wird.

Der Entwurf einer robusten Mikroarchitektur

Innerhalb von Objectory wird dieser Entwicklungsschritt als Robustness-Analysis bezeichnet. Das zentrale Ziel ist die Ausarbeitung eines Objektmodells, des sogenannten Analysemodells, das die Mikroarchitektur auf einer idealen Ebene darstellt. Charakteristisch für diese ideale Ebene ist die Unabhängigkeit von einer konkreten Implementierungsumgebung, zu der die Programmiersprache, Klassenbibliotheken, das Betriebssystem, die Hardware, konkrete Datenbanken usw. gehören.

Eine Besonderheit des Analysemodells ist, daß es sich aus drei verschiedenen Arten von Objekten, den Schnittstellen-, Steuer- und Entitätsobjekten, zusammensetzt. Um die Mikroarchitektur auch auf der Ebene von Komponenten betrachten zu können, wird das Analysemodell durch Subsysteme und Packages erweitert.

Auf dieser Ebene sollte man dafür Sorge tragen, daß die von der Applikation geforderte Funktionalität vollständig auf die Objekte aufgeteilt wurde. Da die Applikation in eine bestehende Anwendungsarchitektur eingebaut wird, kann sie für bestimmte Standardfunktionalität auf Komponenten der Makroarchitektur wie Help, Mail, Clipboard usw. zugreifen, die dem Applikationsentwickler in einem Service-Package zur Verfügung gestellt werden.

Durch die idealisierte Darstellungsweise gewinnen komplizierte Strukturen wie die verteilter Architekturen wieder an Übersichtlichkeit.

Speziell bei großen Systemen sollte die Mikroarchitektur mit besonderer Rücksicht auf ihre Wiederverwendbarkeit und ihre Verteilbarkeit entworfen werden. Eine große Unterstützung beim Finden einer wiederverwendbaren und verteilbaren Architektur ist eine Einbettung in die oben vorgestellten drei Stufen. Die Einteilung der Applikation in Komponenten, die:

sollte schon im Analysemodell erfolgen.

Die Einbettung der Mikroarchitektur in die Implementationsumgebung

Die Implementationsumgebung setzt sich innerhalb der Anwendungsarchitektur aus HP-DST und in den meisten Fällen einer relationalen Datenbank zusammen. Die Verwendung von VisualWorks (ST-80) erlaubt in Design und Implementierung eine Plattformunabhängigkeit. Über sogenannte Datenbanktreiber sind auch relationale Datenbanken ansprechbar.

Für das implementationsabhängige Design der Anwendung stellt Objectory das Designmodell bereit. Es besteht im Gegensatz zum Analysemodell nur noch aus einer Art von Objekten - dem Designobjekt. Zwischen Analyse- und Designobjekten bestehen Referenzen, die eine Verfolgbarkeit des Überganges vom Analyse- zum Designmodell erleichtern (Traceability).

Bevor man beginnt, die Anwendung in verteiltem Smalltalk (HP-DST) zu implementieren, sollte man sie zunächst in herkömmlichem VisualWorks als lokaler Umgebung realisieren und testen. Hierbei kann der Dependents-Mechanismus der Klasse Model verwendet werden, um die Trennung zwischen Presentation- und Semantic-Objects zu simulieren. Erst wenn in diesem Modus keine Fehler mehr auftreten, ist es sinnvoll, die Klassenbibliothek von HP-DST einzusetzen.

Beim Übergang von reinem VisualWorks zu HP-DST sollte man das Analysemodell als konstantes Referenzmodell ansehen. Dies ist auch eine gute Gelegenheit, zu überprüfen, ob die Architekturentscheidungen aus dem Analysemodell auch vollständig in das Designmodell übernommen wurden.

Zusammenfassung & Ausblick

Ziel dieses Beitrages war die Vorstellung erster Ansätze zur Beschreibung einer Softwarearchitektur für verteilte objektorientierte Anwendungssysteme.

Die allgemeine Situation, in der sich Entwickler und Betreiber von Softwaresystemen befinden, wurde kurz vorgestellt. Nicht weiter wartbare bzw. erweiterbare Systeme lassen eine Fortsetzung ihrer Pflege zu teuer oder gar unmöglich werden. Es steht somit die Aufgabe der Anpassung vieler dieser Systeme an neueste Technologien, um von modernen Paradigmen und Methoden der Softwaretechnik profitieren zu können.

Durch die Strukturierung bzw. Organisation von Softwaresystemen nach entsprechenden Mustern und Regeln sollen diese durch konzeptuelle Klarheit und Vollständigkeit leichter verständlich und modifizierbar werden. Software-Architektur wird die Komplexität von großen industriellen Softwaresystemen nicht reduzieren, sie kann diese jedoch beherrschen helfen. Einfachkeit in jeglicher Hinsicht ist hierbei Grundvoraussetzung.

Das objektorientierte Paradigma begünstigt aufgrund seiner Hauptprinzipien Kapselung, Vererbung und Polymorphismus eine stabile und zugleich modifizierbare Strukturierung von Softwaresystemen. Die Bestrebungen der Object Management Group um die Standardisierung und damit Vereinheitlichung eines objektorientierten Modells im Rahmen der Object Management Architecture sind ein großer Schritt in Richtung offener, verteilter und flexibler Softwaresysteme.

Hewlett-Packard's Distributed-Smalltalk ist eine vollständige Implementierung und Erweiterung aller bisher durch die Object Management Group standardisierten Komponenten der Object Management Architecture. Eine dreistufige, durch die Verwendung von Distributed-Smalltalk unterstützte Architektur ermöglicht die effiziente Verteilung von System- und Applikationsteilen innerhalb eines heterogenen Netzwerkes. Hierbei handhaben sogenannte Frontends die Interaktion mit den entsprechenden Nutzern, Domain-Server verwalten von verschiedenen Nutzern bzw. Applikationskomponenten geteilte Daten und Funktionalität und ein Datenbank-Server sorgt für Langzeitspeicherung bzw. Persistenz ausgewählter Entitäten.

Währenddessen die Mikroarchitektur den internen Aufbau einer objektorientierten Applikationen modelliert, ist eine Möglichkeit der Teilung und Organisation des Gesamtsystems in Infrastrukturkomponenten bzw. Subsysteme sowie deren Möglichkeiten zur Kooperation in der Makroarchitektur aufgezeigt.

Die Beschreibung der Makro- und Mikroarchitektur erfolgte bisher ausschließlich im Rahmen der Problemraummodellierung mittels Domain-Object-Model's von Objectory. Diese Modelle beinhalten vornehmlich "naive" Objekte, die gemeinsam mit der sie umgebenden Struktur in stabilere und damit robustere Formen zu überführen sind. Schnittstellen von Infrastrukturkomponenten lassen sich durch Beobachtung ihres Interaktionsverhaltens mit anderen Komponenten unter Zuhilfenahme von Interaktionsdiagrammen genauer bestimmen. Ist die Schnittstelle einer Komponente relativ stabil, so kann diese Komponente als eigenständiges Projekt innerhalb des Objectory-Entwicklungsprozesses bearbeitet werden. Die getrennte Bearbeitung scheint aufgrund der hohen Komplexität des Gesamtsystems notwendig und unumgänglich. Der von Objectory vorgegebene Entwicklungsprozeß bietet sich für die weitere Bearbeitung dieser ersten Ansätze und der Überführung in ein funktionsfähiges System an. Durch Einsatz eines solchen prototypischen Systems läßt sich die Richtigkeit der Entscheidungen und Konzepte überprüfen und möglicherweise korrigieren.

Die Aktivitäten der Object Management Group werden fortgeführt, was zu einer Vervollständigung der geplanten Standards und damit der diese implementierenden Produkte führen wird. Die Standardisierung von Komponenten bzw. deren Schnittstellen auf feinerer Grannularität als bisher wirkt positiv auf die Marktpositionierung von unabhängigen Softwareanbietern (ISV's bzw. Independent-Software-Vendors), wodurch der Wettbewerb belebt und die Preisvorstellungen bestimmter Anbieter realistischer und damit akzeptabel werden. Mit Distributed-Object-Computing (DOC) erfolgt ein Übergang bisheriger Systeme vom klassischen Client/Server-Modell incl. Data-Sharing in den Bereich von Systemen mit austauschbaren Komponenten. Erste Studien verfolgen Betrachtungen zur Modellierung verteilter Unternehmensstrukturen und -abläufe (Distributed-Enterprise) durch Business-Objects und Business-Engineering.

Bisherige Ansätze zur Beschreibung objektorientierter Systeme lassen die Frage nach einer theoretischen Grundlage dieser offen. Daraus ergibt sich ein weiterer Ansatzpunkt zur Fortführung der Betrachtungen dieses Themas.

Alle in diesem Beitrag beschriebenen Konzepte zielen auf eine Erhöhung der Eigenschaft der Wiederverwendbarkeit von Softwarekomponenten sowohl im Kleinen als auch im Großen. Viele dieser, mit dem Architekturgedanken verbundenen Ideen sind interessant und vielversprechend, erfordern jedoch aufgrund der Neuheit und Aktualität des Forschungsthemas eine weitere Verfolgung und Bearbeitung.

"Software Engineering" will not be a true engineering discipline

until it codifies a large body of design information and creates reference materials

that engineers can use to solve routine design problems quickly and reliably.

(Mary Shaw)

Literatur

[And+93] Anderson, B. u.a.: Software Architecture: The Next Step for Object Technology. In: OOPSLA ´93 Proceedings

[Atwo94] Atwood, Thomas: Der Objekt-DBMS-Standard. In: OBJEKTspektrum, Heft 1, 1994

[BaWi93] Bauer, K. M.; Wiedling, H.-P.: Einheitliche Bedien- und Darstellungskonzepte. Zentrum für Graphische Datenverarbeitung e.V., 1993

[Booc94] Booch, G.: Object-Oriented Analysis and Design with Applications. Benjamin/Cummings, 1994

[Brow94] Brown, K.: GUI Smalltalk: The VisualWorks UIBuilder. In: The Smalltalk Report, Vol. 3 No. 8, 1994

[GoRo89] Goldberg, A.; Robson, D.: Smalltalk-80 - The Language. ParcPlace Systems, 1989

[Jac+93] Jacobson, I. u.a.: Object-Oriented Software Engineering - A Use Case Driven Approach. Addison-Wesley, 1993

[JaLi91] Jacobson, I.; Lindström, F.: Re-engineering of old systems to an object-oriented architecture. In: OOPSLA'91 Proceedings

[Kobi94] Kobialka, H.-U.: 15th International Conference on Software Engineering - Reisebericht. GMD/SET, 1994

[Maie94] Maier, P.: VisualWorks 2.0 - das Objekt des Columbus. In: OBJEKTspektrum, Heft 3, 1994

[Micr92] Microsoft Corporation: The Windows Interface - An application design guide. Microsoft Press, 1992

[OBsp94] OMG-News. In: OBJEKTspektrum, Heft 3, 1994

[OMG91] Object Management Group: The Common Object Request Broker: Architecture and Specification (Revision 1.1). OMG Document Number 91.12.1

[OMG92] Object Management Group: Object Management Architecture Guide (Revision 2.0). OMG TC Document 92.11.1

[OMG94] Object Management Group: Common Object Services Specification (Volume 1). John Wiley & Sons, due to be released in 1994

[Parc92a] Objectworks\Smalltalk 4.1 - User´s Guide. ParcPlace Systems, 1992

[Parc92b] VisualWorks 1.0 - Tutorial. ParcPlace Systems, 1992

[Parc92c] VisualWorks 1.0 - User´s Guide. ParcPlace Systems, 1992

[Parc94] VisualWorks 2.0 - Cookbook. ParcPlace Systems, 1994

[Sole93] Soley, R. M.: An object model for integration. In: Computer Standards & Interfaces (1993) 15

[THP93] Tichy, W. F.; Habermann, N.; Prechelt, L.: Future Directions in Software Engineering. In: ACM Sigsoft Software Engineering Notes, Vol. 18 No. 1, 1993

[Weg+92] Wegner, P. u.a.: Object-Oriented Megaprogramming. In: OOPSLA ´92 Proceedings

[Wirt94] Wirth, N.: Gedanken zur Software-Explosion. In: Informatik-Spektrum (1994) 17