Objektorientierte Programmierung (OOP) ist inzwischen gang und gäbe. Der Erfolg dieser Methode ermutigt die Anbieter, nach und nach sämtliche DV-Bereiche mit dieser Technik abzudecken. Nachdem nun die Objektdatenbanken dabei sind, sich Marktanteile zu erobern, liegt es für OOP-Entwickler auf der Hand, diese für die Verwaltung ihrer Programme zu nutzen. Raymund Vorwerk* nennt die Vorteile einer solchen Vorgehensweise.
Der Vorteil, der sich aus der Diskussion um objektorientierte Techniken herauskristallisiert, ist die Wiederverwendbarkeit von Softwarekomponenten. Diese wird erreicht durch die Nutzung von entsprechend definierten Objekten und mehr noch durch die Eigenschaft der Vererbung, die den gravierendsten Unterschied zwischen prozeduralen und objektorientierten Programmierumgebungen darstellt.
Die Wiederverwendbarkeit bezieht sich auf Objekte, die sich wiederum aus Klassen herleiten, und auf die Methoden, die das Verhalten der einzelnen Objekte bestimmen. Darüber hinaus erstreckt sich diese Eigenschaft nicht nur auf Objekte, sondern auch auf Business-Modelle, die das Zusammenspiel der unterschiedlichen Objekte definieren.
Im Prinzip nur Singleuser-Umgebungen
Entscheidendes Kriterium für einen Nutzenvorsprung durch die Anwendung objektorientierter Technologien ist weniger die jeweilige objektorientierte Programmierungsumgebung, sei es Smalltalk, C+ + etc., sondern die Notwendigkeit, wiederverwendbare Komponenten zu erkennen, zu erstellen und zu verwalten.
Die gängigen objektorientierten Programmiersysteme sind im Prinzip Singleuser-Umgebungen. Jeder Benutzer hat ausschließlich Zugriff auf die in seinem System vorhandenen Klassen und Methoden. Abgesehen von dieser Art einer Mehrfachbenutzung beruht die Kenntnis anderer wiederverwendbarer Komponenten auf Hören-Sagen. Somit hätte sich gegenüber den klassischen Programmierumgebungen - abgesehen von vielleicht verbesserten Werkzeugen - nichts geändert.
Zur Erreichung der durch objektorientierte Entwicklungsprodukte propagierten Vorteile ist daher ein Verfahren notwendig, das jedem Programmierer die Möglichkeit bietet, sich jederzeit über verfügbare wieder verwendbare Komponenten, die Software ICs, zu informieren. Information bedeutet nicht nur das Suchen in einer Liste von Klassen und Methoden, sondern auch das Verstehen des Kontextes, in dem diese Objekte zu verwenden sind. Für Small talk beispielsweise sind für einen einzelnen isolierten Benutzer diese Informationen über den Class-Hierarchy-Browser einfach zu ermitteln.
Was geschieht jedoch, wenn mehr als ein Entwickler an einer Anwendung arbeitet, was ja im Regelfall der Fall ist? Hierzu ist es notwendig, daß sämtliche wiederverwendbaren Komponenten jedem Anwendungsentwickler zugänglich gemacht werden, das heißt, alle wiederverwendbaren Bausteine sind hl einem zentralen Repository zu speichern.
Repository-Strukturen ist allerdings, das hat die Vergangenheit gelehrt, die Eigenschaft zueigen, relativ schnell zu veralten und so ihre Wirksamkeit zu verlieren. Das bedeutet, wiederverwendbare Komponenten - sprich: Klassen und Methoden - müssen immer automatisch in diesem zentralen Repository erfaßt werden.
Weiterhin gehört zur Verwaltung von wiederverwendbaren Komponenten eine Organisation einschließlich der dazugehörigen Definition von Verantwortlichkeit. Dieses bedeutet ganz klar: Klassen haben einen Besitzer find einen oder mehrere Nutzer.
Darüber hinaus sind Speicherungsformen zu wählen, die es erlauben, nicht notwendigerweise vordefinierte Komponenten zu speichern und beliebig untereinander zu verknüpfen Nur hierdurch wird es möglich den Kontext, in dem diese Komponente steht, sinnvoll darzustellen Die Nutzung dieses Repositorys muß in die jeweilige Programmierumgebung gebettet sein und darf nicht administrativ behindert werden.
Zur Archivierung bieten sich heute objektorientierte Datenbanksysteme (ODBMS) an. Sie besitzen Eigenschaften, die geradezu prädestiniert sind für die verteilte Anwendungsentwicklung. Zum einen lassen sich dort Informationen einer beliebigen Struktur speichern und verwalten.
Im Gegensatz zu relationalen Datenbanksystemen muß die Art und Länge der jeweiligen Information nicht vorher definiert werden.
Zum anderen lassen sich die in einer objektorientierten Datenbank gespeicherten Informationen beliebig untereinander, auch über Datenbankgrenzen hinaus, verknüpfen. Dies bedeutet, daß die bei relationalen Systemen implizite Verknüpfung durch eine explizite Verknüpfung in ODBMS ersetzt wird Hierdurch können beliebige Klassen und Methoden zu Anwendungen, Versionen und Konfigurationen zusammengefaßt werden.
Durch die besondere Art der Speicherung von Objekten in ODBMS wird nicht nur der aktuelle Zustand eines Objektes verfügbar, sondern auch sämtliche vorhergehenden Versionen Aus Sicht der Programmierung bedeutet dies, daß alle Änderungszustände eines Programmoduls verfolgt und untersucht werden können.
Hinsichtlich einer verteilten Anwendungsentwicklung weisen objektorientierte Datenbanken - auch über die Eigenschaft der Versionsverwaltung - besondere Zugriffsmechanismen auf. Diese nicht notwendigerweise transaktionsorientierten Kontrollmechanismen ermöglichen es einem Team von Mitarbeitern, an derselben Sache zu selben Zeit zu arbeiten Diese Eigenschaft wird Workgroup-Management genannt.
Gerade im Bereich der objektorientierten Programmiersprachen ist dieses um so notwendiger, als ein Programmierer üblicherweise keine vollständige Anwendung, sondern nur noch Methoden einzelner Klassen bearbeitet. Methoden haben im Regelfall nur einen Umfang von wenigen Zeilen. Erst durch ihre Nutzung entsteht die tatsächliche Anwendung. Für den praktischen Einsatz bedeutet dies, daß die herkömmlichen Zugriffsmechanismen einer relationalen Datenbank, die ja transaktionsorientiert sind, für die verteilte Anwendungsentwicklung nicht angemessen sind.
Die "optimistischen" Zugriffsverfahren einer objektorientierten Datenbank, einschließlich der Möglichkeit, Versionen von Objekten zu verwalten, sind die Voraussetzung für ein erfolgreiches Workgroup-Management. Dieses Verfahren verringert den Verwaltungsaufwand dadurch, daß optimistisch davon ausgegangen wird, daß nur ein Benutzer auf ein Objekt zugreift. Anders als bei der pesimistischen Methode werden mögliche Konflikte nicht im voraus durch Locking-Verfahren abgeblockt, sondern erst dann wenn sie tatsächlich auftreten.
Vom Prinzip her bilden Datenbanken wie sie im nebenstehenden Kasten beschrieben sind, eine quasi hierarchische Struktur, in die jeweils Klassen und Methoden aggregiert werden. Jedes Objekt oberhalb der Klassendatenbank enthält Verbindungen zu existierenden Klassen oder auch zu einzelnen Methoden anderer Klassen, die notwendig sind, um eine Anwendung ausführen zu können.
Versionen sind zu einem bestimmten Zeitpunkt eingefrorene Applikationen, das heißt, sie sind nicht mehr änderbar. Konfigurationen bestehen aus mehreren Versionen unterschiedlicher Applikationen sowie gegebenenfalls aus veränderbaren Anteilen von Business-Modellen, Klassen und Methoden.
Jeder Benutzer hat das Recht, alle Klassen zu benutzen und sie durch die Anwendung des Vererbungsmechanismus zu erweitern. Die Veränderung von Klassendefinitionen und deren Verhalten, sprich: die inhaltliche Veränderung von Methoden, obliegt ausschließlich dem Besitzer (Owner) dieser Klasse. Er kann allerdings diese Rechte delegieren.
Objektorientierte Datenbanken weisen zumeist die Eigenschaft des Versionsverwaltung auf, das heißt, der Änderungsstand von Objekten läßt sich zurückverfolgen. Dieses ist eine Eigenschaft, mit der die historische Entwicklung von Applikationen (Business-Modell, Klassen und Methoden), die ja nichts anderes sind als kleine Programme, verfolgt werden kann.
Die Forderung nach einer integrierten Einbettung dieses Repositories in die Anwendungs-Entwicklungsumgebung garantiert, daß nur tatsächliche lauffähige Module gespeichert werden. In der Smalltalk-Umgebung zum Beispiel lassen sich Methoden nur in der objektorientierten Datenbank speichern, wenn sie erfolgreich kompiliert wurden. Das bedeutet nicht, daß sie fehlerfrei Saufen, stellt aber sicher, daß andere Benutzer nur auf einwandfreie Module zugreifen.
Verteilte Anwendungs-Entwicklungsumgebungen sind erst seit dem Jahre 1991 kommerziell verfügbar. Für die objektorientierte Programmierung mit Smalltalk sind dies zum Beispiel "Envy Developer" von OTI und "DSSDE" von VC Software Construction. Für C+ + kann durch eine geeignete Definition der diesen Anwendungsentwicklungsumgebungen zugrundeliegenden Datenbanken ein entsprechender Ansatz verfügbar gemacht werden.
Generell können die Prinzipien der verteilten Anwendungsentwicklung durch die Verwendung objektorientierter Datenbanksysteme auch in klassischen Sprachen wie Cobol oder PL1 verwendet werden. Dies hat dann zwar mit Objektorientierung nichts mehr zu tun, kann aber doch erhebliche Produktivitätsgewinne durch die transparente Nutzung einzelner Programmteile nach sich ziehen.
Objektdatenbanken für die SW-Entwicklung
Für die Arbeit in einer mit Hilfe von objektorientierten Datenbanken definierten verteilten Anwendungs-Entwicklungsumgebung bietet sich die Definition folgender Datenbanken an:
Methoden: Die Datenbank enthält sämtliche verfügbaren Methoden als Sourcecode.
Klassen: Die Klassendatenbank umfaßt die Beschreibung der jeweiligen Klasse und die Zeiger auf die entsprechenden Methoden in der Methodendatenbank.
Business-Modelle: Business-Modelle beinhalten Klassen sowie gegebenenfalls notwendige Methoden anderer Objekte die im Business-Modell verwendet werden, jedoch nicht integraler Bestandteil des Business-Modells sind.
Applikationen: In der Applikationsdatenbank wird die Funktionalität einer Anwendung beschrieben. Applikationen bestehen aus Business-Modellen, anderen Klassen und Methoden.
Versionen: Die Versionsdatenbank enthält den eingefrorenen Sourcecode einer Applikation zu einem bestimmten Zeitpunkt.
Konfigurationen: Eine Konfiguration besteht aus unterschiedlichen Versionen und Applikationen. Darüber hinaus ist zur Administration der verteilten Anwendungs-Entwicklungsumgebung eine Benutzerdatenbank erforderlich.