DE69503065T2

DE69503065T2 - Objektorientierte vorrichtung für konfigurationsverlaufsverwaltung

Info

Publication number: DE69503065T2
Application number: DE69503065T
Authority: DE
Inventors: Farzin Hayward Ca 94542 Maghoul; Jeff W. Los Altos Ca 94022 Parrish
Original assignee: Object Technology Licensing Corp
Current assignee: Object Technology Licensing Corp
Priority date: 1994-12-09
Filing date: 1995-12-05
Publication date: 1999-01-21
Anticipated expiration: 2015-12-06
Also published as: WO1996018157A2; US5752245A; CA2205185A1; DE69503065D1; WO1996018157A3; JPH10512068A; EP0786109B1; EP0786109A2

Description

GEBIET DER ERFINDUNG

Diese Erfindung betrifft im allgemeinen Verbesserungen an Computersystemen, und insbesondere eine objektorientierte Software zur Verwaltung von Änderungen, Revisionen und Modifizierungen in Softwareprogrammentwicklungsobjekten.

HINTERGRUND DER ERFINDUNG

Das Herz eines modernen Computersystems ist das Softwareprogramm, das den Betrieb der Hardware-Komponenten steuert und koordiniert. Die Abfolge von Befehlen oder Schritten, aus denen das Programm besteht, wird im allgemeinen in einer Textdatei gespeichert, die als Quellcodedatei bezeichnet wird. Die Programmanweisungen in der Quellcodedatei können im allgemeinen vom Menschen gelesen und vom Programmentwickler zusammengestellt und bearbeitet werden. Wie im folgenden noch genauer erklärt wird, wird der für den Menschen lesbare Quellcode von einem anderen Programm, das als Kompilierer bezeichnet wird, in einen binären Objektcode umgewandelt oder kompiliert, der dann von der Hardware ausgeführt werden kann.
Als Computersysteme am Anfang entwickelt wurden, waren sowohl die Hardware als auch die Softwareprogramme wesentlich einfacher als heute. Die Hardware bestand aus einem einzelnen Prozessor, und frühe Softwareprogramme waren relativ klein und kompakt und bestanden im allgemeinen aus einer einzigen Textdatei, welche den Quellcode enthielt. Als sowohl die Hardware als auch die Software komplexer wurden und die Softwareentwicklung voranschritt, nahm damit auch die Größe und Komplexität der Programme zu. Daher wurde es notwendig, das Programm in kleinere, leichter zu verstehende Abschnitte aufzuteilen. Das Aufteilen der Programme in mehrere Teile brachte auch den Vorteil mit sich, daß jedes Stück Quellcode während der Programmentwicklung getrennt in den Objektcode kompiliert werden konnte, was natürlich viel schneller vor sich ging als das Kompilieren des gesamten Programms. Aufgrund der Komplexität und der für die Entwicklung von zuverlässigem Software- Code erforderlichen Zeit wurden auch Techniken entwickelt, die es erlaubten, Code-Stücke, die bereits entwickelt waren, in unterschiedlichen Teilen eines einzelnen Programms und auch in zwei getrennten Programmen wiederzuverwenden.
Zum Beispiel wurden strukturierte Programmiertechniken entwickelt, bei denen der Großteil des Quellcodes als separate Unterroutinen geschrieben wurde und das Hauptprogramm einfach die Unterroutinen aufrief. In vielen Fällen war es komfortabel, Sammlungen der Unterroutinen in getrennten Dateien zu speichern.
Mit der Entstehung des objektorientierten Programmierens wurde das Potential der Wiederverwendung von Abschnitten eines bereits geschriebenen Codes wesentlich erhöht, aber auch die Komplexität der Programme nahm damit einhergehend zu. Insbesondere bestehen, wie dies noch genauer weiter unten beschrieben wird, objektorientierte Programme aus einer Sammlung von miteinander in Beziehung stehenden Objekten. Bei vielen modernen Programmiersprachen wird jedes dieser Objekte typischerweise von einer Header-Datei definiert, welche Definitionen der Datenstrukturen und Unterroutinen oder Methoden enthält, aus denen das Objekt besteht. Das Objekt besitzt weiters eine Quellcodedatei, die den Code enthält, der die Methoden implementiert. In einem modernen objektorientierten Programm kann die Anzahl der Objekte leicht in die Hunderte und in manchen Fällen in die Tausende gehen. Wie bei strukturierten Programmen werden Sammlungen von Objekten im allgemeinen in separaten Dateien abgelegt, so daß ein komplexes Programm Hunderte von Dateien umfassen kann.
Da diese Objekte miteinander in Beziehungen stehen, kommt es sehr häufig vor, daß Programmdateien auf andere Programmdateien verweisen. Diese gegenseitige Beziehung erfordert eine Art von Dateiverwaltung, um die Dateien während der Kompilierung rückverfolgen zu können. Eine typische Programmentwicklungsabfolge ist zum Beispiel in sehr vereinfachter Form in Fig. 1 dargestellt.
Insbesondere beginnt die Abfolge bei Schritt 100 und geht zu Schritt 102 weiter, wo allgemeingültige Konstruktionskriterien für das Softwareprogramm festgelegt werden. Danach stellt ein Programmentwickler bei Schritt 104 den Quellcode zusammen, um den Computer so zu steuern, daß er die in Schritt 102 festgesetzten Konstruktionskriterien erfüllt. Wie zuvor erwähnt, kann der Quellcode viele unterschiedliche Dateien umfassen, die den Klassen für die Erzeugung von Menüs, Bildschirmsymbolen, Bitmaps, Textfolgen, Bildschirmaufbauten und anderen Komponenten des Systems entsprechen.
Als nächstes wird bei Schritt 106 der Quellcode von einem Kompilierprogramm in Objektmodule kompiliert. Jede separate Quelldatei kann separat in ein entsprechendes Objektmodul kompiliert werden, das Binärcode enthält. Die separaten Objektmodule werden bei Schritt 108 mittels eines Binderprogramms miteinander verbunden, um ein ausführbares Programm zu erzeugen (das dann tatsächlich auf einem Computer laufen kann). Als nächstes wird das ausführbare Programm bei Schritt 110 ausgeführt und mit den Konstruktionskriterien, die bei Schritt 102 erstellt wurden, verglichen. Wenn sich aufgrund der Ergebnisse der Überprüfung bei Schritt 110 herausstellt, daß das Programm bei Schritt 112 den Konstruktionskriterien entspricht, wird die Programmentwicklung beendet (dargestellt durch den Schritt 116). Wenn sich jedoch zeigt, daß das Programm den Konstruktionskriterien nicht entspricht, wird der Quellcode bei Schritt 114 bearbeitet, und die Kompilations- und Verbindungs schritte 106 und 108 werden wiederholt, bis das Programm schließlich den Konstruktionskriterien entspricht.
Im allgemeinen umfaßt die Bearbeitung des Quellcodes bei Schritt 114 die Bearbeitung einiger, aber nicht aller Quellcodedateien. Da jedoch einige der Dateien auf andere Dateien verweisen können, müssen bestimmte Quellcodedateien wahrscheinlich neu kompiliert werden, selbst wenn sie selbst nicht modifiziert wurden. Wenn zum Beispiel ein Unterobjekt modifiziert wird, muß die Objektdatei, welche einen Verweis auf das Unterobjekt enthält, wahrscheinlich auch in Schritt 106 kompiliert werden. Somit ist es notwendig, die Verweise zwischen Dateien zu verfolgen, damit unterschiedliche Änderungen oder Revisionen an einer Datei die Änderungen an anderen, damit in Verbindung stehenden Dateien wiedergeben.
Eine herkömmliche Art, die Verweise zwischen Quellcodedateien zu verwalten, ist eine "Projekt"-Datei. Die Projektdatei ist eine vereinfachte Datenbank, die eine Liste der Quellcodedateien sowie die Verweise zwischen den Dateien und den aktuellen Status einer jeden Datei (ob die Datei modifiziert wurde oder nicht) verwaltet. Im allgemeinen wird der Dateistatus durch einen Datums- und Zeitstempel verwaltet, der an jeder Quellcodedatei angebracht wird, wenn die Datei modifiziert wird. Wenn eine Projektdatei verwendet wird, nimmt der Kompilierschritt die Form einer Projekt-"Erstellung" an, während der alle Quellcodedateien in der Projektdatenbank, die neu kompiliert werden müssen, der Reihe nach kompiliert werden. Die Projektdatei enthält auch einen Datums- und Zeitstempel für die letzte Erstellungszeit. Wenn das ausführbare Programm das nächste Mal erstellt wird, vergleicht die Programmentwicklungsverwaltungssoftware den Zeitstempel einer jeden Quellcodedatei mit dem Zeitstempel, der während der letzten Programmerstellung in der Projektdatei gespeichert wurde. Jene Quellcodedateien, deren Zeitstempel jünger sind als das letzte Erstellungsdatum, werden vor der Verknüpfung neu kompiliert.
Dieser Projektdateiansatz funktioniert gut bei kleinen und mittelgroßen Projekten, bei denen nur wenige Leute gleichzeitig an einem Projekt arbeiten. Bei großen Projekten jedoch wird dieser Projektdateiansatz zu einem Flaschenhals. Bei großen Projekten gibt es oft Programmentwicklungsteams, die Objekte und andere Programmkomponenten innerhalb eines Projektes und zwischen Projekten gemeinsam verwenden. Demgemäß ist es bei großen Projekten notwendig, eine Art Quellcodekontrollprogramm zu benutzen, das die Verwendung dieser Objekte zwischen den Projekten koordinieren kann, um sicherzustellen, daß die richtige Version für die Kompilierung verwendet wird.
Ein anderes Verfahren zur Verwaltung großer Softwareprojekte, bei dem die Quellcodedateien in Dateiverzeichnissen mit mehreren hierarchischen Ebenen abgelegt werden, wird im US-Patent Nr. 5.361.357 gezeigt. Gemäß diesem Patent wird das Softwareprogramm als eine Gruppe separater Bäume innerhalb des Systems modelliert. Es wird eine kleine Anzahl an Zielen der höchsten Ebene identifiziert, welche das vollständige Quellcodeprogramm erzeugen, wenn sie miteinander verbunden werden. Die Bäume werden so ausgewählt, daß Zwischenebenen einiger Bäume den Blattebenen anderer Bäume entsprechen, so daß die Beziehung zwischen diesen Bäumen schon allein aufgrund der Liste der Ziele höchster Ebene, der Nebenprodukte und der Blattabhängigkeiten der einzelnen Bäume bestimmt werden kann. Jeder Baum repräsentiert ein Quellcodeverzeichnis, und jedes Ziel höchster Ebene kann durch Verarbeitung des Quellcodes aktualisiert werden, der vom zugehörigen Baum abstrakt repräsentiert wird. Die Abhängigkeiten zwischen der Gruppe von Bäumen bestimmt die Reihenfolge, in der die Kompilierung in jedem der Verzeichnisse ausgeführt werden sollte, und sie identifiziert auch alle Verzeichnisse, die aktuell sind und nicht verarbeitet werden müssen. Es wird eine Vorrichtung offenbart zur Ausführung der bevorzugten Ausführungsform, welche einen Speicher und eine Gruppe von Speicherregister umfaßt, welche ein Verzeichnisdatenregi ster umfassen, das die Namen der zu verarbeitenden Verzeichnisse enthält; ein Verzeichnisbeschreibungsregister, das eine hierarchische Baumebenenbeziehung in jedem zu verarbeitenden Verzeichnis enthält; ein Hauptdateiausgaberegister, das die Namen der Ausgabedateien für ein gegebenes Verzeichnis enthält; ein Nebenproduktregister, das die Namen der Dateien enthält, die als Zwischeneingabedateien für gegebene Ausgabedateien des Verzeichnis identifiziert wurden; ein Blattabhängigkeitsregister, das die Namen der Dateien enthält, bei denen es sich um die Primäreingaben für eine gegebene Ausgabedatei handelt; ein abstraktes Baumregister zur Verwaltung der gesammelten Beschreibung der Verzeichnisse, während sie verarbeitet werden, und ein Übereinstimmungsregister zur temporären Aufbewahrung von Datenobjekten für Vergleichszwecke.
Derzeit stehen mehrere kommerzielle Quellcodekontrollsysteme zur Verfügung, einschließlich RCA, SCCS und MPW Projector. Diese Systeme verwalten jedoch nur eine aktuelle Version des Quellcodes und sind nicht in der Lage, irgendwelche anderen zusätzlichen Informationen zu verwalten, die zur Kontrolle des Codes verwendet werden können, wie zum Beispiel zusätzliche Konfigurationsinformationen. Desweiteren können diese Systeme keine Verlaufsinformationen bezüglich früherer Versionen des Codes zur Verfügung stellen, die für Vergleichs- und Zusammenführungszwecke hilfreich wären.
Demgemäß ist es eine Aufgabe der vorliegenden Erfindung, ein Programmentwicklungsverwaltungssystem zu schaffen, das es einem Programmentwicklungsteam ermöglicht, Objekte und andere Programmkomponenten gemeinsam zu verwenden und wiederzuverwenden.
Es ist eine weitere Aufgabe der vorliegenden Erfindung, ein Programmentwicklungsverwaltungssystem zu schaffen, das Konfigurations- und Versionskontrollinformationen verwaltet, und das unterschiedliche Codeversionen, die im Laufe der Zeit entwickelt wurden, speichern kann.
Es ist eine weitere Aufgabe der vorliegenden Erfindung, ein Programmentwicklungsverwaltungssystem zu schaffen, das eine verteilte Datenbank verwendet, die in einem Netzwerk arbeitet.

ZUSAMMENFASSUNG DER ERFINDUNG

Die Erfindung wird durch die angehängten Ansprüche definiert.
Die zuvor beschriebenen Aufgaben werden erfüllt und die zuvor beschriebenen Probleme werden gelöst in einer beispielhaften Ausführungsform der Erfindung, in der ein verteiltes Programmverlaufsdatenbanksystem zur Verwendung in einem Client-Server-Netzwerk konstruiert wird. Das System besteht aus einer Vielzahl an Programmverlaufsservern, die Versionsinformationen für verschiedene Programmkomponenten verwalten.
Beim Anmelden an einem Client-Terminal im Netzwerk errichtet ein Programmentwickler einen Arbeitsraum oder ein Projekt und verbindet sich mit einem der Verlaufsserver. Nach der Verbindung mit dem Verlaufsserver wird ein Entwurf der Programmkonfiguration vom Server geladen. Der Konfigurationsentwurf kann Informationen zur Konstruktion einiger der Programmkomponenten sowie "Brücken"-Informationen enthalten, die andere Programmverlaufsserver auffinden, auf denen sich zusätzliche Programmkomponenten befinden. Der Arbeitsraum verwendet die Komponenteninformationen, um Komponenten zu assemblieren, und die Brückeninformationen, um eine Verbindung mit anderen Servern herzustellen und die restlichen Komponenten wiederaufzufinden, um den vollständigen Quellcode für ein Programm im Arbeitsraum zu assemblieren.
Die Server können zwischen verschiedenen Projekten gemeinsam benutzt werden und mehrere Versionen des Codes speichern. In den Servern werden Methoden zur Verfügung gestellt, um Codeversionen wiederaufzufinden und Codekonfigurationen zu erzeugen.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Fig. 1 ist ein vereinfachtes, schematisches Diagramm eines Programmentwicklungszyklus.
Fig. 2 ist ein vereinfachtes Diagramm eines Client- Server-Systems des Standes der Technik, auf dem die vorliegende Erfindung ausgeführt werden kann.
Fig. 3 ist ein vereinfachtes Schema eines Personalcomputersystems, das entweder den Client- oder den Server-Knoten von Fig. 2 umfassen kann.
Fig. 4 ist ein veranschaulichendes Blockdiagramm, das die Anordnung der Programmkomponenten innerhalb eines Projektes und die Beziehung der Programmkomponenten zu unterschiedlichen Programmverlaufsservern zeigt.
Fig. 5 ist ein schematisches Blockdiagramm eines Projekts und eines Projektverlaufsservers, das jeweils ihre wichtigsten Komponenten darstellt.
Fig. 6 ist ein vereinfachtes Blockdiagramm, das die Erzeugung eines Vermittlerobjektes zur Durchführung von Transaktionen zwischen einem Projektarbeitsraum und einem zugeordneten Verlaufsserver zeigt.
Fig. 7 ist ein Flußdiagramm, das die Schritte zeigt, die bei der Verbindung eines Projektarbeitsraumes mit einem zugeordneten Verlaufsserver ausgeführt werden.
Fig. 8 ist ein Flußdiagramm, daß die während des CreateDraft-Befehls (Erzeuge Entwurf-Befehl) ausgeführten Schritte darstellt.
Fig. 9 ist ein Flußdiagramm der Schritte, die bei einem RetrieveDraft-Befehl (Entwurf wiederauffinden) ausgeführt werden.

DETAILLIERTE BESCHREIBUNG EINER VERANSCHAULICHENDEN AUSFÜHRUNGSFORM

Der Projektverlaufsserver der vorliegenden Erfindung kann auf mehrere Arten implementiert werden. Die einfachste Implementierung besteht in der Verwendung einer einzigen, zentralen Datenbank, die sich in einem lokalen Serverknoten befindet und eine komplette Liste der Programmkomponenten für alle im System befindlichen Projekte enthält. Eine bevorzugte Implementation verwendet jedoch mehrere Verlaufsserver, die an ein Netzwerk angeschlossen sind, und sie verteilt die Programmkomponenten über diese Server. Ein Beispiel für ein solches verteiltes System ist in Fig. 2 dargestellt. Fig. 2 zeigt ein Computernetzwerk, das in einer "Client-Server"-Konfiguration mit einer Vielzahl an Client-Netzknoten 206, 208, 220, 222 und 228 angeordnet ist, bei denen es sich zum Beispiel um Workstations, Personalcomputer, Minicomputer oder andere Computergeräte handeln kann, auf denen Anwendungsprogramme laufen, die über verschiedene Netzwerkverbindungen einschließlich den Verbindungen 202, 210, 216, 226, 234 und 236 miteinander und mit den Server-Netzknoten, wie zum Beispiel den Netzknoten 200, 212, 224, 232 und 238, kommunizieren. Die Server- Netzknoten können spezialisierte Hardwaregeräte und Softwareprogramme umfassen, die allen oder einigen der Client- Netzknoten einen Service oder eine Gruppe von Services zur Verfügung stellen können. Die Client-Netzknoten sind die Benutzer der verschiedenen Netzwerk-Services, welche wiederum von den Server-Netzknoten zur Verfügung gestellt werden.
Typischerweise befinden sich Projektverlaufsdatenbanken 204, 213 und 229 in mehreren der Server-Netzknoten, wie zum Beispiel in den Netzknoten 200, 212 und 232. Ein Client-Netzknoten, wie zum Beispiel der Client-Netzknoten 206, kann auf eine oder mehrere der Datenbanken 204, 213, 229 zugreifen, indem er einen Projekt-Arbeitsraum 207 im Netzknoten 206 initialisiert und eine Verbindung mit einem der Server-Netzknoten herstellt, der einen mit diesem Projekt im Zusammenhang stehenden Eintrag enthält, eine Projektkennung oder einen Namen eingibt und sowohl die in der Datenbank 204 gespeicherten Programmkomponenten als auch die Netzwerkadressen anderer Server wiederauffindet, die Komponenten des Projekts enthalten. Der Mechanismus der Initia lisierung eines Projekt-Arbeitsraumes, des Herstellens einer Verbindung mit einem Verlaufsserver und des Wiederauffindens von Komponentenentwürfen oder Versionen wird im Detail weiter unten diskutiert.
Sowohl der Client- als auch der Server-Abschnitt der Erfindung wird vorzugsweise im Zusammenhang mit einem Betriebssystem angewandt, das sich auf einem Personalcomputer, wie zum Beispiel dem IBM PS/2 oder einem Apple Macintosh Computer, befindet. Eine repräsentative Hardware- Umgebung, die entweder den Client-Netzknoten oder den Server-Netzknoten von Fig. 2 umfassen kann, ist in Fig. 3 dargestellt, welche eine typische Hardware-Konfiguration eines Computers 300 gemäß der vorliegenden Erfindung darstellt. Der Computer 300 wird von einer Zentraleinheit (CPU) 302 gesteuert, bei der es sich um einen herkömmlichen Mikroprozessor handeln kann; eine Anzahl anderer Einheiten, die alle über einen Systembus 308 miteinander verbunden sind, ist ebenfalls vorhanden, um bestimmte Aufgaben auszuführen. Wenngleich ein bestimmter Computer vielleicht nur einige der in Fig. 3 dargestellten Einheiten aufweisen oder zusätzliche Komponenten besitzen kann, welche nicht dargestellt sind, werden die meisten Computer zumindest die dargestellten Einheiten aufweisen.
Insbesondere umfaßt der in Fig. 3 dargestellte Computer 300 einen Direktzugriffsspeicher (RAM) 306 für die zeitweilige Speicherung von Informationen, einen Nur-Lesen- Speicher (ROM) 304 für die dauerhafte Speicherung der Konfiguration des Computers und der grundlegenden Betriebsbefehle, und einen Eingabe-/Ausgabe- (E/A) Adapter 310 für den Anschluß von Peripheriegeräten, wie zum Beispiel einer Platteneinheit 313 und eines Drucker 314 am Bus 308 über die Kabel 315 bzw. 312. Es steht auch ein Benutzerschnittstellenadapter 316 für den Anschluß von Eingabegeräten, wie zum Beispiel einer Tastatur 320, und anderer bekannter Schnittstellengeräte, einschließlich Mäusen, Lautsprechern und Mikrophonen, am Bus 308 zur Verfügung. Die visuelle Ausgabe erfolgt über einen Anzeigenadapter 318, der den Bus 308 mit einem Anzeigegerät 322, wie zum Beispiel einem Videomonitor, verbindet. Auf der Workstation befindet sich eine Betriebssystemsoftware, wie zum Beispiel das Apple System/7-Betriebssystem, welches die Workstation steuert und koordiniert.
In einer bevorzugten Ausführungsform wird die Erfindung in der C++-Programmiersprache mit Hilfe objektorientierter Programmiertechniken implementiert. C++ ist eine kompilierte Sprache, das heißt, Programme werden in einem für den Menschen leicht lesbaren Skript geschrieben, und dieses Skript wird dann von einem anderen Programm, einem sogenannten Kompilierer, bearbeitet, der einen maschinenlesbaren numerischen Code daraus erzeugt, welcher in den Computer geladen und von diesem direkt ausgeführt werden kann. Wie unten beschrieben, besitzt die C++-Sprache bestimmte Merkmale, die es einem Softwareentwickler erlauben, Programme, die von anderen geschrieben wurden, auf einfache Weise zu verwenden und gleichzeitig eine umfangreiche Kontrolle über die Wiederverwendung der Programme zu wahren, um deren Zerstörung oder unsachgemäße Verwendung zu verhindern. Die C++-Sprache ist gut bekannt, und viele Artikel und Texte sind verfügbar, in denen diese Sprache im Detail beschrieben wird. Darüber hinaus sind C++- Kompilierer von mehreren Herstellern einschließlich Borland International, Inc. und der Microsoft Corporation kommerziell erhältlich. Aus Gründen der Verständlichkeit werden daher die Details der C++-Sprache und der Betrieb des C++- Kompilierers in diesem Dokument nicht näher behandelt.
Wie den Fachleuten dieses Bereiches bekannt ist, umfassen die Objektorientierten Programmier- (OOP) Techniken die Definition, Erstellung, Verwendung und Zerstörung von "Objekten". Diese Objekte sind Software-Einheiten, die Datenelemente und Routinen bzw. Funktionen umfassen, welche die Datenelemente manipulieren. Die Daten und damit in Verbindung stehenden Funktionen werden von der Software als eine Einheit behandelt und können erzeugt, verwendet und gelöscht werden, als ob es sich dabei um einen einzigen Gegenstand handeln würde. Gemeinsam machen es die Daten und Funktionen den Objekten möglich, nahezu jede Echtwelt- Einheit hinsichtlich ihrer Merkmale, welche von den Datenelementen repräsentiert werden, und ihrem Verhalten, welches von ihren Datenmanipulationsfunktionen repräsentiert wird, zu modellieren. Auf diese Weise können Objekte konkrete Dinge wie Personen und Computer modellieren, und sie können auch abstrakte Begriffe wie Zahlen oder geometrische Begriffe modellieren.
Objekte werden durch Erzeugung von "Klassen" definiert, die selbst keine Objekte sind, aber die als Vorlagen dienen, welche dem Kompilierer mitteilen, wie das eigentliche Objekt zu konstruieren ist. Eine Klasse kann zum Beispiel die Anzahl und Art der Datenvariablen und die Schritte festlegen, die mit den Funktionen, welche die Daten manipulieren, im Zusammenhang stehen. Ein Objekt wird eigentlich im Programm mittels einer speziellen Funktion erstellt, die als Konstruktor bezeichnet wird, und welche die entsprechende Klassendefinition und zusätzliche Informationen, wie zum Beispiel Argumente, verwendet, die während der Objekterstellung zur Verfügung gestellt werden, um das Objekt zu konstruieren. Auf ähnliche Weise werden Objekte von einer speziellen Funktion, die als Destruktor bezeichnet wird, zerstört. Objekte können durch Verwendung ihrer Daten und Aufruf ihrer Funktionen verwendet werden.
Die Hauptvorteile der objektorientierten Programmiertechniken ergeben sich aus drei grundlegenden Prinzipien: Einkapselung, Polymorphismus und Vererbung. Insbesondere können Objekte entsprechend konstruiert werden, um die gesamte interne Datenstruktur und die internen Funktionen oder einen Teil davon zu verstecken oder einzukapseln. Insbesondere kann ein Programmentwickler während der Programmerstellung Objekte definieren, in denen alle oder einige der Datenvariablen und alle oder einige der damit im Zusammenhang stehenden Funktionen als "privat" oder zur ausschließlichen Verwendung durch das Objekt selbst erklärt werden. Andere Daten oder Funktionen können als "öffentlich" erklärt oder für die Verwendung durch andere Programme freigegeben werden. Der Zugriff auf die privaten Variablen durch andere Programme kann durch das Festlegen öffentlicher Funktionen für ein Objekt gesteuert werden, welche auf die privaten Daten des Objektes zugreifen. Die öffentlichen Funktionen bilden eine kontrollierte und konsistente Schnittstelle zwischen den privaten Daten und der "Außenwelt". Jeder Versuch, einen Programmcode zu schreiben, der direkt auf die privaten Variablen zugreift, führt dazu, daß der Kompilierer einen Fehler während der Programmkompilierung erzeugt, der den Kompilierungsvorgang stoppt und verhindert, daß das Programm ausgeführt werden kann.
Polymorphismus ist ein Konzept, das es Objekten und Funktionen, welche dasselbe Gesamtformat aufweisen, aber mit unterschiedlichen Daten arbeiten, erlaubt, auf unterschiedliche Weise zu arbeiten, um konsistente Ergebnisse zu produzieren. Zum Beispiel kann eine Additionsfunktion als Variable A plus Variable B (A + B) definiert werden, und dieses selbe Format kann unabhängig davon verwendet werden, ob es sich bei A und B um Zahlen, Zeichen oder Dollar und Cent handelt. Der eigentliche Programmcode jedoch, der die Addition ausführt, kann sich je nach Art der Variablen, die A und B enthalten, stark unterscheiden. Polymorphismus ermöglicht das Schreiben dreier separater Funktionsdefinitionen, nämlich eine für jede Variablenart (Zahlen, Zeichen und Dollar). Nachdem die Funktionen definiert wurden, kann ein Programm später durch sein gemeinsames Format (A + B) auf die Additionsfunktion Bezug nehmen, und während der Kompilierung wird der C++-Kompilierer durch Überprüfung der Variablentypen bestimmen, welche der drei Funktionen nun tatsächlich verwendet wird. Daraufhin wird der Kompilierer den entsprechenden Funktionscode ersetzen. Polymorphismus ermöglicht es, daß ähnliche Funktionen, die zu analogen Ergebnissen führen, im Quellcode des Programms "zusammengefaßt" werden, um einen logischeren und klareren Programmablauf zu erzeugen.
Das dritte Prinzip, das der objektorientierten Programmierung zugrunde liegt, ist die Vererbung, die es Programmentwicklern erlaubt, bereits bestehende Programme auf einfache Art und Weise wiederzuverwenden und dadurch die Erstellung einer Software ganz von Beginn an überflüssig machen. Das Prinzip der Vererbung ermöglicht es einem Softwareentwickler, Klassen (und die Objekte, die später von ihnen erzeugt werden) als miteinander in einer Beziehung stehend zu deklarieren. Insbesondere können Klassen als Unterklassen anderer Basisklassen festgelegt werden. Eine Unterklasse "erbt" alle öffentlichen Funktionen ihrer Basisklassen und kann auf diese so zugreifen, als ob diese Funktionen in der Unterklasse selbst enthalten wären. Alternativ dazu kann eine Unterklasse einige oder alle ihrer geerbten Funktionen überschreiben oder einige oder alle ihrer geerbten Funktionen modifizieren, indem sie einfach eine neue Funktion mit derselben Form definiert (das Überschreiben oder Modifizieren ändert die Funktion in der Basisklasse nicht, sondern modifiziert bloß die Verwendung der Funktion in der Unterklasse). Die Erzeugung einer neuen Unterklasse, die einen Teil der Funktionalität (bei selektiver Modifizierung) einer anderen Klasse besitzt, ermöglicht es Softwareentwicklern, auf einfache Weise bestehenden Code maßzuschneidern, um bestimmte Bedürfnisse zu erfüllen.
Obwohl das objektorientierte Programmieren wesentliche Verbesserungen gegenüber anderen Programmierkonzepten bietet, erfordert die Programmentwicklung dennoch einen großen Zeit- und Arbeitsaufwand, besonders dann, wenn keine fertigen Softwareprogramme vorhanden sind, die modifiziert werden können. Daher war es bis jetzt Stand der Technik, einem Programmentwickler eine Reihe vordefinierter, miteinander verknüpfter Klassen zur Verfügung zu stellen, die eine Gruppe von Objekten erzeugen, sowie verschiedene zusätzliche Routinen, die alle auf die Ausführung allgemein auftretender Aufgaben in einer bestimmten Umgebung ausgerichtet sind. Solche vordefinierten Klassen und Bibliothe ken werden typischerweise als "Anwendungsrahmenwerke" bezeichnet und bieten eine vorfabrizierte Struktur für eine Arbeitsanwendung.
So könnte zum Beispiel ein Anwendungsrahmenwerk für eine Benutzerschnittstelle eine Gruppe von vordefinierten Grafikschnittstellenobjekten bieten, die Fenster, Rollbalken, Menüs usw. erzeugen und die Unterstützung und das "Standard"-Verhalten für diese Grafikschnittstellenobjekte bieten. Da Anwendungsrahmenwerke auf objektorientierten Techniken basieren, können die vordefinierten Klassen als Basisklassen verwendet werden, und das eingebaute Standardverhalten kann von Unterklassen, die vom Entwickler definiert werden, geerbt und entweder modifiziert oder überschrieben werden, damit Entwickler das Rahmenwerk erweitern und maßgeschneiderte Lösungen in einem bestimmten Fachbereich erstellen können. Dieser objektorientierte Ansatz bietet gegenüber dem herkömmlichen Programmieren große Vorteile, da der Programmierer das Originalprogramm nicht ändert, sondern vielmehr die Fähigkeiten des Originalprogramms erweitert. Darüber hinaus arbeiten sich Entwickler nicht blind durch Schichten von Codes hindurch, weil das Rahmenwerk eine architekturbezogene Führung und Modellierung bietet, und gleichzeitig die Entwickler befreit, damit diese spezifische Maßnahmen im Hinblick auf den Problembereich ergreifen können.
Es gibt viele verschiedene Arten von Anwendungsrahmenwerken, die zur Verfügung stehen, welche von der Ebene des damit zusammenhängenden Systems und der Art des zu lösenden Problems abhängen. Die Arten der Rahmenwerke reichen von Anwendungsrahmenwerken hoher Ebene, die bei der Entwicklung einer Anwenderschnittstelle helfen, bis hin zu Rahmenwerken niedrigerer Ebene, welche grundlegende Systemsoftwareservices, wie zum Beispiel Kommunikation, Drucken, Dateiablagesystemunterstützung, Grafik usw. bieten. Kommerzielle Beispiele für Anwendungsrahmenwerke sind MacApp (Apple), Bedrock (Symantec), OWL (Borland), NeXTStep App Kit (NeXT), und Smalltalk-80 MVC (ParcPlace) Wenngleich der Ansatz der Anwendungsrahmenwerke alle Prinzipien der Einkapselung, der Polymorphie und der Vererbung auf die Objektschicht anwendet und eine wesentliche Verbesserung gegenüber anderen Programmiertechniken darstellt, ergeben sich bei diesem Ansatz doch auch Schwierigkeiten. Diese Schwierigkeiten beruhen auf der Tatsache, daß es für Entwickler einfach ist, ihre eigenen Objekte wiederzuverwenden, jedoch schwierig, Objekte zu verwenden, die von anderen Programmen erzeugt wurden. Desweiteren bestehen Anwendungsrahmenwerke im allgemeinen aus einer oder mehreren "Schichten" an der Spitze eines monolithischen Betriebssystems, und selbst angesichts der Flexibilität der Objektschicht ist es oft noch notwendig, mittels mühevoller Prozeduraufrufe direkt mit dem darunterliegenden Betriebssystem zu interagieren.
In derselben Weise, wie ein Anwendungsrahmenwerk dem Entwickler eine vorfabrizierte Funktionalität für ein Anwendungsprogramm bietet, kann ein Systemrahmenwerk zur Verwaltung von Softwareprogrammkomponenten, wie zum Beispiel jenes, welches in einer bevorzugten Ausführungsform enthalten ist, eine vorfabrizierte Funktionalität für Systemebenenservices bieten, die von den Entwicklern modifiziert oder überschrieben werden können, um maßgeschneiderte Lösungen zu erstellen, wodurch die mühevollen Prozeduraufrufe vermieden werden, die bei Anwendungsrahmenwerkprogrammen des Standes der Technik notwendig sind.
Gemäß den Prinzipien der Erfindung umfaßt das Programmentwicklungsverwaltungssystem zwei Hauptteile: das Projekt und den Projektverlauf. Das Projekt, oder der Arbeitsraum, befindet sich in einem der Client-Terminals, dort, wo Anwendungen, gemeinsam verwendete Bibliotheken usw. entwikkelt werden. Ein Projektverlauf ist eine Datenbank, die verschiedene Entwürfe oder Versionen des Projekts verwaltet und sich in einem oder mehreren Server-Netzknoten befindet. Daher haben Projekte und Projektverläufe eine Client- Server-Beziehung zueinander. Logischerweise ist ein Projekt ein Client eines einzelnen Projektverlaufs, selbst wenn sich Abschnitte dieses einzelnen Projektverlaufs physikalisch auf mehreren unterschiedlichen Servern befinden, so daß das Projekt mit mehreren unterschiedlichen Projektverlaufsservern verbunden ist und diese gleichzeitig verwendet.
Ein Projektverlaufsserver verwaltet eine einzelne Verlaufsdatenbank, die für die Verwaltung von aktuellen Entwürfen und Verläufen von Programmkomponenten verantwortlich ist, die Teil des Client-Projekts sind. Da alle Zugriffe auf eine Verlaufsdatenbank über ihren alleinigen Verlaufsserver erfolgen, sind Verlaufsserver für die Koordinierung des gleichzeitigen Zugriffs auf die Verlaufsdatenbank verantwortlich. In Übereinstimmung mit einer bevorzugten Ausführungsform handelt es sich bei der Verlaufsdatenbank vorzugsweise um eine objektorientierte Datenbank. Die Einzelheiten einer solchen Datenbank sind für ein Verständnis der vorliegenden Erfindung nicht wichtig, aber eine Datenbank, die für die Verwendung in der vorliegenden Erfindung geeignet ist, wird im Detail im US-Patent Nr. 5.325.533 diskutiert, die an Taligent Inc., dem Zessionar der vorliegenden Erfindung, abgetreten wurde.

DAS PROJEKT

Ein vereinfachtes Diagramm, das Programmkomponenten in einem Projekt zeigt, ist in Fig. 4 dargestellt. Fig. 5 zeigt die wichtigsten Komponenten eines Projekts und eines Projektverlaufsservers. Innerhalb des Projekts 500 sind die Programmkomponenten 508-512 in einem einzelnen Baum 506 organisiert, der in der Projekt- oder Wurzelkomponente 508 verwurzelt ist. Dieser Baum ist detaillierter in Fig. 4 dargestellt, wo sich der Baum 402 aus den Komponenten 404- 412 zusammensetzt. Die Programmkomponenten 404-412 können zum Beispiel Programmcode umfassen, der Klassen definiert und implementiert, die zur Konstruktion von Objekten verwendet werden, Programmcode, der zum Definieren und Implementieren von Menüs, Binärbilder für Bitmaps und Bild schirmsymbole, Textfolgedateien und andere herkömmliche Programmkomponenten.
Wie in Fig. 4 dargestellt, sind die einzelnen Programmkomponenten 404-412 jeweils einem Programmverlaufsserver zugeordnet, auf dem die vorigen Entwürfe oder Überarbeitungen der Komponente gespeichert sind. Zum Beispiel ist die Wurzelkomponente 404 dem Server 0 zugeordnet (bezeichnet durch die Nummer 416, der einen Entwurf 418 speichert), wie dies schematisch durch den Pfeil 414 dargestellt ist. Auf ähnliche Weise sind die Komponenten 2 und 3 (406 bzw. 408) dem Server 1 (422, der die Entwürfe 424 und 426 speichert) zugeordnet, wie dies durch den Pfeil 420 dargestellt ist. Die Komponente 4 (410) ist dem Server 2 (430, er speichert den Entwurf 432) zugeordnet, und die Komponente 5 (412) ist dem Server 3 (436, er speichert den Entwurf 438) zugeordnet.
Um konsistente Konfigurationen beizubehalten, wird die Regel aufgestellt, daß ein einzelner Verlaufsserver nur exakt einem Unterbaum zugeordnet sein kann. Gemäß dieser Regel kann die Komponente 412 dem Verlaufsserver 436 oder dem Verlaufsserver 430 zugeordnet werden, aber sie kann nicht dem Verlaufsserver 422 zugeordnet werden, da die Mutter der Komponente, die Komponente 410, bereits dem Verlaufsserver 430 zugeordnet ist.
Das logische Modell besteht darin, daß es einen einzigen Verlaufsserver pro Projekt gibt, aber die Komponenten, aus denen sich das Projekt zusammensetzt, können physikalisch auf mehreren Verlaufsservern verteilt sein, wie dies in Fig. 4 dargestellt ist. Gemäß den Prinzipien der Erfindung werden die Programmkomponenten, aus denen sich das Projekt zusammensetzt, zum Zeitpunkt der Initialisierung des Projekts assembliert. Insbesondere besitzt das Projekt einen ihm zugeordneten Dauerspeicher, der jenen Server- Netzknoten identifiziert, auf dem sich der Verlaufsserver für die Wurzelkomponente des Projekts befindet.
Während des Prozesses der Initialisierung des Projekt- Arbeitsraumes wird die gespeicherte Verlaufsserverkennung verwendet, um eine Verbindung zu diesem Verlaufsserver herzustellen und eine bestimmte Konfiguration des Projektes wiederaufzufinden. Wie im folgenden noch genauer erklärt wird, enthält diese Konfiguration Informationen bezüglich Komponenten, die sich physikalisch auf diesem Verlaufsserver befinden, aber auch Informationen, die zu Verbindungen mit anderen Verlaufsservern führen können. Während des Prozesses der Initialisierung werden die Komponenten, die sich im Verlaufsserver befinden, dem Projekt-Arbeitsraum- Komponentenbaum 506 hinzugefügt. In Übereinstimmung mit der Erfindung werden die anderen Verlaufsserver automatisch verbunden, und der Programmentwickler muß über die zusätzlichen Verbindungen nicht Bescheid wissen (soferne einige der Server nicht erreicht werden können oder nicht mehr vorhanden sind - was nur in Ausnahmefällen vorkommt). Während des Verbindungsprozesses erzeugt das Projekt auch eine Tabelle 504 aller Verlaufsserver, mit denen es verbunden ist, und verwaltet diese. Diese Tabelle und die Verlaufsserververbindungen bestehen für die gesamte Dauer des Projekts.
Im Projekt-Arbeitsraum und in den Verlaufsservern gibt es unterschiedliche Arten von Komponenten, und jede Komponente besitzt eine Gruppe von Eigenschaften. Eine Komponentenart oder eine Eigenschaftenart wird durch einen Namen gekennzeichnet (dargestellt als Text). Zum Beispiel ist der Name Klasse eine Komponentenart, die eine C++-Klasse repräsentiert. Auf ähnliche Weise ist der Name Implementation eine Eigenschaftenart, die ein Attribut (in diesem Fall eine Implementation) einer gegebenen Komponente repräsentiert. Es kann keine zwei Komponentenarten geben, die durch denselben Namen identifiziert werden: das gleiche gilt auch für Eigenschaftenarten. Eine wichtige Eigenschaft, die jeder Komponente zugeordnet ist, ist eine "Mitgliedseigenschaft", die eine Liste aller Unterkomponenten enthält, die dieser Komponente zugeordnet sind. Die Mitgliedseigenschaft ermöglicht die Auffindung von Unterkomponenten für jede Komponente.
Aus Gründen der Effizienz identifizieren der Arbeitsraum (und die Programmverlaufsserver) jede Komponentenart und jede Eigenschaftenart durch eine Zeichenfolgen-Token- Kennung (eine Indexnummer, die eine Textfolge repräsentiert). Die Zeichenfolgen-Token-Kennungen sind jedoch nicht dauerhaft, weswegen sich der Indexwert einer gegebenen Textfolge zwischen Sitzungen und Maschinen ändern kann. Dies bringt mit sich, daß der Wert der Zeichenfolgen-Token- Kennung für die selbe Komponentenart in einem Verlauf und im Arbeitsraum nicht unbedingt gleich sein muß.
Jede Programmkomponente in einem Projekt wird durch ein Paar einzigartiger Kennungen identifiziert. Die erste Kennung, die als Komponentenkennung bezeichnet wird, repräsentiert eine Komponente unabhängig von ihrer Version. Die zweite Kennung, die als Versionskennung bezeichnet wird, identifiziert die Version der Komponente. Gemeinsam identifizieren die zwei Kennungen eine Version einer Komponente auf unverwechselbare Weise. Während der Erzeugung einer neuen Komponente im Projekt-Arbeitsraum werden sowohl eine neue, unverwechselbare Komponentenkennung als auch eine neue, unverwechselbare Versionskennung erzeugt. Es können mehrere Komponenten mit der selben Komponentenkennung gleichzeitig innerhalb eines Projekts vorhanden sein, aber jede muß eine eigene, unverwechselbare Versionskennung besitzen. Desweiteren kann es nur null oder eine Version einer jeden Komponente im Projekt geben, die der aktuellen Konfiguration zugeordnet ist.
Letztendlich können Komponenten nur durch ihre Komponentenkennung gemeinsam mit ihrer Versionskennung auf unverwechselbare Weise identifiziert werden. Um jedoch den häufigen Fall des Zugriffs auf eine Komponente in der aktuellen Konfiguration zu ermöglichen, stellt das Projekt ein Mittel zur Verfügung, mit dessen Hilfe auf Komponenten nur mittels ihrer Komponentenkennung zugegriffen werden kann. In diesem Fall nimmt das Projekt an, daß die gewünschte Version der Komponente jene in der aktuellen Konfiguration ist.
Die Fähigkeit des Projekts, zu erkennen, welche Komponentenversionen in der aktuellen Konfiguration enthalten sind, ermöglicht einen Grad an indirektem Vorgehen beim Zugriff auf Komponenten, der die Notwendigkeit einer Suche und Aktualisierung bestehender Referenzen zu jener Komponente erübrigt, wenn sich die Version ändert. Zum Beispiel werden keine Referenzen aktualisiert, wenn eine neue Version einer Komponente erzeugt oder eine andere Version geladen wird. Ohne dieses indirekte Vorgehen müßte das System den Versionskennungsteil einer jeden Referenz zur modifizierten Komponente, die innerhalb einer beliebigen Eigenschaft in der Datenbank enthalten ist, suchen und aktualisieren.
Um eine Gruppe von Eigenschaften einer bestimmten Komponentenart zuzuordnen, werden spezielle Informationen verwendet, die als Metadaten bezeichnet werden. Die Metadaten für alle Komponenten im Projekt definieren das "Schema" des Projekt-Arbeitsraums, und dieses Schema wird im Dauerspeicher gespeichert und vom Projekt-Arbeitsraum als Teil der Initialisierung eingelesen und in einer Datei 502 gespeichert, wie dies in Fig. 5 dargestellt ist.
Ein Arbeitsraum-Schema besitzt die Möglichkeit, sich über mehrere Versionen des Arbeitsraumes hinweg zu verändern; so kann es zum Beispiel neue Komponentenarten geben, oder die richtige Gruppe für eine bestimmte Komponentenart kann sich ändern. Die mit einer neuen Version des Arbeitsraumes verbundenen Verlaufsserver müssen die Fähigkeit besitzen, mit den Änderungen umzugehen, so daß alte Programmverläufe noch immer verwendbar sind. Insbesondere umfassen die möglichen Änderungen an einem Schema eines Projekt-Arbeitsraumes folgendes:
Σ Hinzufügen/Löschen von Komponentenarten
Σ Hinzufügen/Löschen von Eigenschaften, die einer Komponentenart oder einer Änderung in den Metadaten der Komponente zugeordnet sind
Σ Hinzufügen/Löschen einer Eigenschaftenart
S Ändern der Definition einer Eigenschaftenart (die geströmten Informationen der Eigenschaftenart haben sich zwischen den Versionen des Arbeitsraumes geändert)
Wie im folgenden noch genauer beschrieben wird, erhält der Verlaufsserver, wenn sich der Projekt-Arbeitsraum mit einem Verlaufsserver verbindet, während der Herstellung der Verbindung genügend Informationen, um alle diese Änderungen außer der letzten (wo sich die Definition einer Eigenschaftenart ändern kann) erkennen zu können. Da der Projektverlauf nicht die Definition einer Eigenschaftenart interpretiert, muß der Projekt-Arbeitsraum diese letzte Änderung handhaben, indem er die Versionserstellung durch die Speichern- und Holen-Funktionen verwaltet, die zum Speichern und Holen der beständigen Projekt-Arbeitsplatzdaten verwendet werden.
Gemäß der objektorientierten Natur des Programmentwicklungssystems würden sowohl der Komponentenbaum als auch seine Knoten in Objekten eingekapselt werden, die in einem anderen Objekt, nämlich TProgramWorkspace, kombiniert werden, welches das Projekt repräsentiert. Der Komponentenbaum wird gemeinsam mit einem Iterator, der über alle Baumzweige "wandert" und die Komponentenkennungen zurückgibt, in ein Objekt eingekapselt. Der Komponentenbaum kann mit Hilfe herkömmlicher Baumstrukturen implementiert werden und wird hier daher nicht weiter diskutiert. Das Projekt enthält ein THistoryManager-Objekt, das den Zugriff auf den Projektverlaufsserver regelt.

DER PROJEKTVERLAUFSSERVER

Die Komponenten eines Verlaufsservers sind in vereinfachter Form in Fig. 5 dargestellt. Diese Komponenten sind Teil eines THistoryServer-Objekts, das den Zugriff auf die in der Datenbank gespeicherten Komponenten steuert. Jeder Verlaufsserver verwaltet eine Liste 516 der Verbindungsinformationen bezüglich anderer Verlaufsserver, auf die von Projektkonfigurationen verwiesen wird, die auf diesem Server gespeichert sind. Ein Verlaufsserver errichtet jedoch niemals eine physikalische Verbindung mit anderen Verlaufsservern (ein Verlaufsserver ist niemals ein "Client" eines anderen Verlaufsservers). Der Projekt- Arbeitsraum stellt eine Verbindung zu allen benötigten Verlaufsservern her, um darin enthaltene Komponenteninformationen wiederaufzufinden. Diese letzteren Verbindungen werden auf beständige Weise beibehalten, solange Komponenten in der Projekt-Konfiguration enthalten sind, die auf die verbundenen Verlaufsserver verweisen.
Zusätzlich zur Verlaufsserver-Liste, die an jedem Verlaufsserver gewartet wird, wird auch eine globale Metadaten-Datei 518 gewartet. Diese Datei enthält die Vereinigung aller Schemata der Projekte, die mit diesem Verlaufsserver über eine Zeitdauer hinweg verbunden sind. Die Datei wird von Objekten gewartet, die von einer Klasse TClientMetaData erzeugt werden. Ein TClientMetaData-Objekt wird jedesmal erzeugt, wenn ein Client-Projekt eine Verbindung zum Verlaufsserver herstellt und alle Methoden und Protokolle zur Verfügung stellt, die benötigt werden, um das Schema des Client zu lesen und der globalen Verlaufsmetadatendatei neue Komponentenarten und Eigenschaftennamen hinzuzufügen. Wie im folgenden noch genauer erklärt wird, gibt das TClientMetaData-Objekt am Ende des Verbindungsprozesses eine Komponentenarten- und Eigenschaftennamenabbildung gemeinsam mit einer Kennung für zukünftige Referenzen an das Client- Projekt zurück.
Die globale Metadatendatei ermöglicht es dem Verlaufsserver, Änderungen im Client-Schema während des Quittungsaustausches (Handshake) zu erkennen, zu dem es während der Verbindung eines Client mit einem Verlaufsserver kommt. Der Verlaufsserver umfaßt auch die Komponentendatenbank 520, die in Übereinstimmung mit den Prinzipien der vorliegenden Erfindung einen Verlauf oder eine Gruppe von Komponentenversionen oder Entwürfen verwaltet. Jeder Entwurf wird auf unverwechselbare Weise durch eine Komponentenkennung und eine Entwurfskennung identifiziert. Zum Beispiel besitzt die Projektwurzelkomponente (mit der Komponentenkennung 0) zwei Entwürfe, den Entwurf 522 mit einer Entwurfskennung 1 und den Entwurf 528 mit einer Komponentenkennung 0 und einer Entwurfskennung 2. Auf ähnliche Weise enthält die Verlaufsdatenbank eine Komponente mit einer Komponentenkennung 2 und zwei Entwürfe: den Entwurf 524 mit einer Entwurfskennung 1, und den Entwurf 530, mit einer Entwurfskennung 2. Eine weitere Komponente mit einer Komponentenkennung N besitzt eine Entwurfskennung 1.
Das THistoryServer-Objekt umfaßt auch Methoden, die es ermöglichen, daß die Komponentenentwürfe wiederaufgefunden oder erzeugt werden können, und daß ein Graph von Beziehungen zwischen Komponentenentwürfen oder einem Verlauf erstellt werden kann.
Der Verlaufsserver interagiert mit dem Client-Projekt- Arbeitsraum, um Komponentenentwürfe zu speichern und sie aus der Komponentendatenbank wiederaufzufinden. Darüber hinaus stellt der Verlaufsserver Informationen zur Verfügung, die andere Verlaufsserver angeben, auf denen Komponentenentwürfe, die mit einem Projekt in Beziehung stehen, verwaltet werden. Diese Informationen sind in Brückenobjekten eingekapselt.
Ein Brückenobjekt verweist auf einen bestimmten Entwurf oder eine Komponente in einem Verlaufsserver, der sich von jenem Verlaufsserver unterscheidet, der die Wurzelkomponente eines Projekts enthält. Daher wird die logische Konnektivität einer Projektkonfiguration von Brückenobjekten verwaltet. Die Brückenobjekte werden in der "Mitgliedseigenschaft" identifiziert, die den einzelnen Komponenten zugeordnet ist, welche alle Mitglieder dieser Komponenten identifizieren. Wenn sich zum Beispiel einige Mitglieder einer Komponente C auf anderen Verlaufsservern befinden als dem Verlaufsserver, auf dem die Komponente C gespeichert ist, enthält die Mitgliedereigenschaft der Komponente C die Brücken, welche diese Komponenten identifizieren, sowie die Mitglieder, die auf jenem Verlaufsser ver gespeichert sind, auf dem die Komponente C gespeichert ist.
Gemäß einer veranschaulichenden Ausführungsform der Erfindung gibt es zwei Typen von Brücken: eine DraftBridge, repräsentiert durch Objekte, die von der Klasse TDraft- Bridge erzeugt werden, und eine SharedProject-Bridge, die durch Objekte repräsentiert wird, die von der Klasse TSharedProjectBridge erzeugt werden. Ein Draft-Bridge-Objekt wird zum Verweisen auf einen Verlaufsserver und einen bestimmten Entwurf einer Komponente in diesem Server verwendet. Zusätzlich zu Informationen, die in einem Draft- Bridge-Objekt eingekapselt sind, identifiziert ein SharedProject-Bridge-Objekt ein SharedProject-Dokument (Dokument eines gemeinsam benutzten Projektes), wo Daten gespeichert sind, die sich auf Komponenten beziehen, die von zwei Projekten gemeinsam verwendet werden. Gemeinsam benutzte Projekte (Shared Projects) werden im Detail weiter unten diskutiert. Brücken gemeinsam benutzter Projekte (Shared Project Bridges) werden als spezielle Mitgliedereigenschaft entworfen und implementiert.
Zum Beispiel besitzt die Projektwurzelkomponente eine spezielle Mitgliedereigenschaft, und diese Mitgliedereigenschaft enthält die SharedProject-Brücken für die einzelnen miteinander verbundenen gemeinsam benutzten Projekte und die Entwurfsbrücken für Komponenten auf anderen Verlaufsservern sowie Mitglieder, die für den Verlaufsserver lokal sind, der die Projektwurzelkomponente enthält.
Der Projekt-Arbeitsraum interagiert mit dem ihm zugeordneten Verlaufsserver über drei Hauptprozesse: einen ClientServer-Verbindungsprozeß und die CreateDraft- und RetrieveDraft-Befehle. Zuerst stellt ein Projekt eine Verbindung zu seinem zugeordneten Server her, und dann werden Komponentenentwürfe erzeugt und geladen.

CLIENT-SERVER-VERBINDUNG

Die Client-Server-Verbindung wird hergestellt, wenn ein Projekt-Arbeitsraum initialisiert wird. Wie zuvor erwähnt, ist dem Arbeitsraum ein Dauerspeicher zugeordnet, der Informationen enthält, die den Server identifizieren, welcher die Wurzelkomponente für das Projekt enthält.
Ebenfalls während des Prozesses der Initialisierung wird das Projektschema aus dem Dauerspeicher eingelesen. Die Verbindung wird mittels eines "Quittungsaustauschprozesses" (Handshake-Prozeß) hergestellt. Insbesondere übermittelt, wenn ein Projekt-Arbeitsraum zum ersten Mal eine Verbindung mit dem ihm zugewiesenen Verlaufsserver herstellt, der Arbeitsraum dem Verlaufsserver sein Schema. Der Verlaufsserver vergleicht das Schema mit seiner internen globalen Metadatentabelle und gibt eine Abbildungstabelle für jede Komponente und jede Eigenschaftenart im Projektschema zurück. Jeder Eintrag in der Abbildungstabelle besitzt die Zeichenfolgen-Token-Kennung des Arbeitsraumes und die Zeichenfolgen-Token-Kennung des Verlaufsservers für eine gegebene Komponente oder eine Eigenschaftenart. Der Projekt-Arbeitsraum verwendet diese Abbildung immer, wenn er mit der Komponente oder der Eigenschaftenart von und zum Verlaufsserver kommunizieren muß.
Wenn ein Projekt-Arbeitsraum zum ersten Mal initialisiert wird, wird eine spezielle Methode aufgerufen, die einen Anschluß an einen Verlaufsserver herstellt und das Projektschema und die Wurzelkomponentenkennung in der Datenbank des Verlaufsservers speichert.
Die Informationen, die zwischen dem Projekt- Arbeitsraum und seinem zugeordneten Verlaufsserver hin- und hergeschickt werden, werden nicht direkt vom Arbeitsraum zum Verlaufsserver geschickt, sondern stattdessen von speziellen "Vermittlerobjekten" übertragen, die von der abstrakten Klasse TAgent abstammen. Die Klasse TAgent definiert das Protokoll für alle Vermittler, um Aufgaben auszuführen, die eine Interaktion zwischen einem Projekt- Arbeitsraum und einem oder mehreren Verlaufsservern erfordern. Um Kommunikationen zwischen einem Projekt-Arbeitsraum und dem ihm zugeordneten Verlaufsserver herzustellen, wird insbesondere ein Vermittler am Projekt-Arbeitsraum erzeugt und zum Verlaufsserver "gesandt". Wenn der Vermittler bereit ist, zum Server gesandt zu werden, "teilt" sich der Vermittler im wesentlichen. Ein "Original"-Vermittler bleibt im Projekt-Arbeitsraum zurück und wartet auf die Ergebnisse, die vom Verlaufsserver zurückgeschickt werden, während eine Kopie des Vermittlerobjekts zum Verlaufsserver gesandt wird. Die Vermittlerkopie kehrt niemals vom Server zurück.
Fig. 6 zeigt auf sehr schematisierte Weise die Erzeugung eines Objektes, das von der TAgent-Klasse abstammt, sowie die Beziehung zwischen dem Projekt-Arbeitsraum und dem zugeordneten Verlaufsserver. Insbesondere wird ein TAgent-Objekt 604 im Projekt-Arbeitsraum 600 erzeugt. Nachdem der Vermittler erzeugt wurde, wird eine TAgent- Objektkopie zum Verlaufsserver 602 geschickt, wie dies schematisch durch den Pfeil 606 dargestellt ist. Nachdem die TAgent-Objektkopie den Verlaufsserver 602 erreicht hat, führt sie eine Aufgabe aus und erzeugt Ergebnisse, wie dies schematisch durch die Box 608 dargestellt ist. Die Ergebnisse 610 werden an den Orginialvermittler 604 zurückgesandt, wie dies durch den Pfeil 610 dargestellt ist. Die TAgent-Objektkopie wird am Verlaufsserver 602 zerstört und kehrt niemals zurück.
Das TAgent-Objekt umfaßt mehrere interne Methoden, die es ihm ermöglichen, Informationen zum Verlaufsserver zu tragen, eine Aufgabe auszuführen und Ergebnisse zur Originalvermittlerkopie zurückzuschicken, die sich im Projekt- Arbeitsraum befindet. Diese Methoden umfassen folgendes:
Σ HandleAssignment()
Σ JobPrologue()
Σ JobEpilogue ()
Σ DoClientWriteJob()
Σ DoServerReadJob()
S DoServerwriteJob(), und
Σ DoClientReadJob
Die HandleAssignment() Methode wird aufgerufen, um den Vermittler zur Aufnahme seiner Tätigkeit zu veranlassen. Im allgemeinen erfordert diese Methode einen Parameter, der den Transportpfad festlegt, den der Vermittler verwenden wird, um vom Projekt-Arbeitsraum zum Verlaufsserver zu reisen. Die Aufgabe des Vermittlers wird bei einer Rückkehr von dieser Methode abgeschlossen sein.
Sämtliche Informationen vom Projekt-Arbeitsraum, die vom Vermittler beim Server benötigt werden, müssen vorbereitet sein, bevor der HandleAssignment()-Aufruf gemacht wird. Demgemäß wird eine JobProlog-Methode verwendet, um diese Informationen zu sammeln und alle zusätzlichen Arbeiten durchzuführen, bevor der Vermittler zum Verlaufsserver transportiert wird. Die als JobEpilog() bezeichnete Begleitmethode wird aufgerufen, nachdem der Vermittler seine Aufgabe am Verlaufsserver erledigt hat und Ergebnisse dieser Aufgabe im Projekt-Arbeitsraum empfangen wurden.
Wenn der Vermittler am Verlaufsserver eintrifft, können vier zusätzliche Methoden aufgerufen werden, um die Aufgabe, die dem Vermittler übertragen worden war, am Server auszuführen. Diese Methoden sind DoClientwriteJob(), DoServerReadJob, DoServerWriteJob, und DoClientReadJob, und sie werden in der zuvor genannten Reihenfolge aufgerufen. Im wesentlichen schreibt der Projekt-Arbeitsraum bei Verwendung dieser vier Methoden eine "Anforderung", und der Server liest die "Anforderung". Der Server verarbeitet die Anforderung und schreibt die "Ergebnisse". Schließlich ließt der Projekt-Arbeitsraum die "Ergebnisse" zurück.
Um den Hin- und Hertransport zwischen Projekt- Arbeitsraum und Verlaufsserver abzuwickeln, werden spezifische Unterklassen der Klasse TAgent instantiiert, um die eigentlichen Vermittler zur Verfügung zu stellen, die die Arbeit tun. Zum Beispiel wird eine Unterklasse mit der Bezeichnung TConnectAgent, ein Abkömmling der Basisklasse TAgent, verwendet, um ein TConnectAgent-Objekt zu instanti ieren, das die Verbindung zwischen dem Projekt-Arbeitsraum und dem ihm zugeordneten Verlaufsserver durchführt. Dieser letztere Vermittler ist dafür verantwortlich, die Client- Metadaten zum Verlaufsserver zu senden und die Abbildungsinformationen für die Komponentenarten und Eigenschaftennamen wieder vom Server zu empfangen. Zu diesem Zweck enthält die Kopie des TConnectAgent-Objektes, das am Server ankommt, Methoden, die wiederum interne Methoden im Verlaufsserver aufrufen, welche die Wurzelkomponentenkennung und die Wurzelkomponentenentwurfskennung der Wurzelkomponente erlangen, die dem Projekt-Arbeitsraum zugeordnet ist.
Die bei der Errichtung einer Verbindung zwischen dem Projekt-Arbeitsraum und seinem zugeordneten Verlaufsserver durchgeführten Schritte sind im Detail in Fig. 7 dargestellt. Insbesondere beginnt die Verbindungsroutine bei Schritt 700 und geht zu den Schritten 702 und 703 weiter, wo der Projekt-Arbeitsraum durch das Einlesen des Client- Schemas aus dem Dauerspeicher (wie dies bei Schritt 702 gezeigt wird) und in der Folge durch das Einlesen der Verlaufsserverpositionsinformationen ebenfalls aus dem Dauerspeicher, wie dies bei Schritt 703 gezeigt wird, initialisiert wird.
Als nächstes wird bei Schritt 704 ein CreateAgent- Objekt von der zuvor diskutierten CreateAgent-Klasse instantiiert. Nachdem das Objekt bei Schritt 708 erzeugt wurde, sendet die Originalkopie des CreateAgent-Objektes das Client-Schema zum Verlaufsserver. Danach wird bei Schritt 710 eine Kopie des CreateAgent-Objektes erzeugt und zum Verlaufsserver geschickt.
Bei Schritt 712 liest die CreateAgent-Kopie die Wurzelkomponentenkennung und erhält die Abbildungstabelle (wobei die internen Methoden im Verlaufsserver verwendet werden). Als nächstes empfängt die Originalkopie des CreateAgent-Objektes bei Schritt 714 die vom Verlaufsserver zurückgeschickte Abbildungstabelle, und die Verbindungsroutine endet bei Schritt 716.

ENTWURF-ERZEUGEN-ROUTINE

Nachdem eine Verbindung zwischen einem Projekt- Arbeitsraum und dem ihm zugeordneten Verlaufsserver errichtet ist, kann der Programmentwickler damit fortfahren, Programmkomponenten zu erzeugen und zu modifizieren. Eine neu erstellte Programmkomponente wird dem Komponentenbaum im Projekt-Arbeitsraum hinzugefügt, wenn sie erzeugt wird. Die Komponente besitzt einen internen Zustand, der entsprechend markiert wird, um anzuzeigen, daß die Komponente gespeichert oder "entworfen" werden muß. Zusätzlich zur Markierung der neuen Komponente wird auch jede Komponente im ererbten Pfad der neuen Komponente markiert, um anzuzeigen, daß diese wiederum entworfen werden muß. Die Fortpflanzung des NeedToDraft-Zustandes auf diese Weise garantiert die Konsistenz der gesamten Konfiguration im Projekt.
Die neu erzeugte Komponente wird in der zugeordneten Verlaufsserver-Datenbank gespeichert, wenn der Programmentwickler den CreateDraft-Befehl aufruft. Der CreateDraft- Befehl identifiziert zuerst die Programmkomponenten im Projekt, die entworfen werden müssen. Zu diesem Zweck wandert der Befehl den Baum ab, wobei er bei der Projektwurzelkomponente beginnt (und die zuvor erwähnte Iterator- Methode verwendet) und jede Komponente und Eigenschaft identifiziert, deren interner Zustand dem NeedToDraft- Zustand ("muß entworfen werden") entspricht. Die identifizierten Komponenten und deren modifizierte Eigenschaften werden danach zu ihren jeweiligen Verlaufsservern geschickt. Eine weitere Komprimierung der Daten innerhalb der modifizierten Eigenschaften ist auch möglich. Die Verlaufsserver wiederum erzeugen eine Version, in der die modifizierten Daten zu empfangen und zu ihren Datenbanken hinzuzufügen sind.
Daher ist es möglich, daß die Wurzel eines Unterbaums zu einem unterschiedlichen Verlauf gehören kann als ihre Elternkomponente. Während der Iterator von der Projektwurzel wandert, um die Komponenten und deren Eigenschaften zu identifizieren, die entworfen werden müssen, verfolgt er auch den Verlaufsserver, der den einzelnen Komponenten zugeordnet ist. Wann immer der Iterator auf eine Situation trifft, bei der sich eine Unterbaum-Wurzel auf einem anderen Verlaufsserver befindet als die Mutter, wird die Wurzel des Unterbaums (die zum anderen Server gehört) nicht auf dem gleichen Verlaufsserver entworfen wie die Mutter, sondern stattdessen markiert. Nachdem alle Komponenten am Server der Mutter entworfen wurden, werden die markierten Unterbäume (jene, die zu anderen Verlaufsservern gehören) auf ihren eigenen Verlaufsservern entworfen.
Betrachen wir zum Beispiel die folgende Komponentenhierarchie mit den zugeordneten Verlaufsserverzuordnungen:
Σ Projekt (S0)
Σ Komponente A (S1)
Σ Komponente B (S2)
Σ Komponente C (S3)
In diesem Beispiel ist die Wurzelkomponente, nämlich Projekt, dem Verlaufsserver S0 zugeordnet, und die Programmkomponenten A, B und C sind den Verlaufsservern S1, S2 bzw. S3 zugeordnet.
In diesem Fall wird der Projekt-Arbeitsraum mit vier Servern verbunden, nämlich S0, S1, S2 und S3. Wenn ein CreateDraft-Befehl vom Projekt in seinen Verlaufsserver S0 aufgerufen wird, werden eine Version der Projektwurzelkomponente und deren Eigenschaften im Verlaufsserver S0 erzeugt. Die Mitgliedseigenschaft dieser Projektwurzelkomponente enthält drei Brückenobjekte, nämlich eines für jede der Komponenten A, B und C. Unter Verwendung der Mitgliedereigenschaft der Projektwurzelkomponente verwaltet der Server S0 eine Liste der Verlaufsserverreferenzen, auf die von den gespeicherten Komponenten verwiesen wird; in diesem Fall würden die Referenzen zu den Verlaufsservern S1, S2 und S3 verweisen.
Die Entwürfe, die in den Verlaufsservern als Reaktion auf die CreateDraft-Routine erzeugt werden, besitzen spezifische Entwurfsattribute, einschließlich der folgenden:
S Draft Name (Entwurfsname) - ein Entwurf besitzt einen oder mehrere statische Namen, die für den Benutzer sichtbar sind und vom Benutzer geändert werden können
Σ Draft Path Name (Entwurfspfadname) - ein Entwurf besitzt einen oder mehrere Pfadnamen; diese sind für den Benutzer sichtbar und können vom Benutzer geändert werden
Σ Draft Date (Entwurfsdatum) - ein Datum, welches das Datum und die Zeit der Erzeugung des Entwurfs angibt; dieses Datum ist für den Benutzer sichtbar, wird aber vom Verlaufsserver zugewiesen.
Σ Draft Creator (Entwurfsersteller) - eine Zeichenfolge, die den verantwortlichen Benutzer angibt, der den Entwurf erzeugt; dies ist für den Benutzer sichtbar, wird aber vom Verlaufsserver zugewiesen.
Σ Draft Description (Entwurfsbeschreibung) - ein Text, der die Art der Änderungen an einem Entwurf beschreibt; diese ist für den Benutzer sichtbar und kann von ihm verändert werden.
Ein Flußdiagramm, welches die grundlegenden Schritte zeigt, die bei der Verarbeitung eines CreateDraft-Befehls ausgeführt werden, ist in Fig. 8 dargestellt. Insbesondere beginnt die CreateDraft-Routine bei Schritt 800 und geht zu Schritt 802 weiter, wo die CreateDraft-Verarbeitung von einem Iterator gesteuert wird, der den Komponentenbaum durchquert, der sich im Projekt-Arbeitsraum befindet. Um die nächste Komponente zu verarbeiten, wird eine Prüfung beim Entscheidungsschritt 802 durchgeführt, ob irgendwelche noch Knoten vorhanden sind. Wenn die Verarbeitung abgeschlossen ist, kehrt die Routine in Schritt 818 zurück.
Wenn bei Schritt 802 eine Entscheidung getroffen wird, daß noch weitere Knoten vorhanden sind, geht der Iterator zum nächsten Unterbaumknoten im Komponentenunterbaum weiter, wie dies bei Schritt 804 dargestellt ist. Als nächstes wird beim Entscheidungsschritt 806 eine Überprüfung durchgeführt, um zu bestimmen, ob der Unterbaumknoten am selben Verlaufsserver gespeichert ist wie der Mutterknoten. Wenn nicht, geht die Routine zu Schritt 808 weiter, wo der Unterbaumknoten (bei dem es sich um eine Unterbaumwurzel handeln kann) für die nachfolgende Verarbeitung markiert und der Unterbaumknoten übersprungen wird. Danach kehrt die Routine zu Schritt 802 zurück, wo eine Überprüfung durchgeführt wird, um zu bestimmen, ob zusätzliche Knoten eine Verarbeitung erfordern.
Wenn alternativ dazu bei Schritt 806 festgelegt wird, daß sich der Unterbaumknoten am selben Verlaufsserver befindet wie der Mutterknoten, geht die Routine zu Schritt 808 weiter, wo der Komponentenzustand, der dem Knoten entspricht, überprüft wird. Wenn sich der Zustand in einem "NeedToDraft"-Modus ("muß entworfen werden") befindet, wie dies am Entscheidungsschritt 810 bestimmt wird, geht die Routine zu Schritt 814 weiter, wo die Komponente und ihre Eigenschaften zum identifizierten Verlaufsserver gesandt werden. Bei Schritt 816 fügt der identifizierte Verlaufsserver die Komponentenentwürfe zu seiner Datenbank hinzu, und die Routine geht danach zu Schritt 802 zurück, wo eine Überprüfung durchgeführt wird, um zu bestimmen, ob noch irgendwelche Knoten im Baum verblieben sind, die noch nicht verarbeitet wurden. Die Verarbeitung wird auf diese Weise so lange wiederholt, bis alle Knoten verarbeitet sind und die Routine bei Schritt 818 endet.
Wenn alternativ dazu der Zustand der Komponente bei Schritt 812 nicht anzeigt, daß sie entworfen werden muß, geht die Routine direkt zu Schritt 802, um zu prüfen, ob irgendwelche Knoten im Komponentenbaum noch verarbeitet werden müssen.
Die CreateDraft-Transaktionen werden eigentlich von Vermittlerobjekten durchgeführt, die von einer Klasse erzeugt werden, die von der TAgent-Klasse mit dem Namen TCreateDraftAgent-Klasse abstammt. Dieses Vermittlerobjekt wird zum zugeordneten Verlaufsserver gesendet, um alle geänderte Komponenten im Unterbaum zu entwerfen (die Wurzel des Unterbaums wird von einer Komponentenkennung und einer Entwurfskennung definiert, die im Objekt enthalten sind). Der Vermittler entwirft nur jene Komponenten, die in einem gegebenen Verlaufsserver gespeichert sind; alle anderen Komponenten oder Knoten werden in einer Liste von Brücken gesammelt. Für jede Brücke in der Liste werden Brückeninformationen entworfern, die ausreichen, damit ein nachfolgender RetrieveDraft-Befehl die echten Komponenteninformationen vom entsprechenden Server wiederauffinden kann. Der Aufrufer des nachfolgenden RetrieveDraft-Befehls verwendet die Brückenliste, um in der Folge jene Komponenten durch Instantiierung zusätzlicher TRetrieveDraftAgent-Objekte mit entsprechenden Argumenten zu entwerfen.
Während der eigentlichen Entwurfserstellung müssen Datenwiederherstellungsprozeduren beachtet werden, um zu verhindern, daß ein Programmentwickler Daten aufgrund eines Stromausfalls, einer Netzwerkaufteilung oder eines Systemfehlers während der Datenbankaktualisierung verliert. Insbesondere können die Client-Server-Transaktionen in "einfache" und "zusammengesetzte" Transaktionen unterteilt werden. Eine einfache Transaktion modifiziert und "übergibt" (macht die Änderungen dauerhaft) danach die Daten einer einzelnen Datenbank. Zum Beispiel ist die Änderung und Übergabe eines Komponentenentwurfs in der Projektdatenbank eine "einfache" Transaktion. Zusammengesetzte Transaktionen bestehen aus mehreren einfachen Transaktionen. Zum Beispiel ist der CreateDraft-Befehl solch eine zusammengesetzte Transaktion - er kann aus so vielen einfachen Transaktionen bestehen, wie es verbundene Verlaufsserver gibt.
Eine zusammengesetzte Transaktion hat nahezu die selben Eigenschaften wie eine herkömmliche verteilte Transaktion, ohne eigentlich eine herkömmliche verteilte Transaktion zu sein. Der wesentliche Unterschied liegt darin, daß im Falle einer herkömmlichen Transaktion, die Untertransaktionen umfaßt, keine Transaktion übergibt, soferne nicht alle eingeschlossenen Untertransaktionen auch übergeben. Im Gegensatz dazu werden in der hierin beschriebenen veranschaulichenden Ausführungsform bei der Verarbeitung einer zusammengesetzten Transaktion so viele der zugeordne ten einfachen Transaktionen übergeben wie möglich. Die zusammengesetzte Transaktion wird als in einem zusammengesetzten Zustand betrachtet, nachdem alle ihrer zugeordneten einfachen Transaktionen übergeben wurden.
Nehmen wir zum Beispiel an, eine zusammengesetzte Transaktion G besteht aus den zugeordneten Untertransaktionen g1, g2, g3, ... gn. Die verschiedenen Untertransaktionen greifen auf die unterschiedlichen Datenbanken hauptsächlich auf der Grundlage der Position der Datenobjekte zu, auf die von der zusammengesetzten Transaktion G zugegriffen wird. Während der Verarbeitung einer zusammengesetzten Transaktion verarbeitet der Verarbeitungsmechanismus, wie zum Beispiel der CreateDraft-Befehl, jede Untertransaktion einzeln nacheinander, indem er mit dem entsprechenden Verlaufsserver interagiert und auf den Abschluß einer jeden Transaktion wartet, bevor er die nächste Transaktion verarbeitet.
In einer Umgebung mit mehreren Datenbanken, wie zum Beispiel jener, die in Fig. 2 dargestellt ist, muß ein bestimmter Mechanismus verwendet werden, um eine Wiederherstellung nach einem Fehler einer Untertransaktion zu ermöglichen, nachdem eine andere Untertransaktion der selben zusammengesetzten Transaktion lokal übergeben wurde. Der in der veranschaulichenden Ausführungsform verwendete Mechanismus nutzt die folgenden Tatsachen:
(a) die lokalen Datenbanken sind autonom;
(b) es gibt keine einfachen Transaktionen außerhalb des Schemas der zusammengesetzten Transaktion; und
(c) die Server-Daten sind unveränderlich.
Aufgrund dieser Tatsachen muß der Verarbeitungsmechanismus der zusammengesetzten Transaktion nur sicherstellen, daß die fehlerhafte Untertransaktion oder die fehlerhaften Untertransaktionen letztlich abgeschlossen werden. Um eine Wiederherstellung von zusammengesetzten Transaktionen zu ermöglichen, wird ein herkömmliches lokales Wiederherstellungsschema, wie zum Beispiel eine Vorausschreib-Protokollierung, verwendet, um eine Wiederherstellung für einzelne Datenbanken zu ermöglichen. Ein solches Wiederherstellungsschema wird im zuvor erwähnten Patent Nr. 5.325.533 beschrieben. Darüber hinaus werden ausreichend viele Zustandsinformationen bewahrt, um den Zustand oder das Ergebnis einer jeden Mitgliedstransaktion und den Zustand der lokalen Datenbank identifizieren zu können. Insbesondere behält jede Programmkomponente im Projekt-Arbeitsraum einen "NeedToDraft"-Zustand bei, bis sie als Ergebnis einer einfachen Transaktion erfolgreich in der zugeordneten Verlaufsdatenbank übergeben wird. Desweiteren umfaßt, wie zuvor erwähnt, jeder Verlaufsserver, der der Wurzelkomponente eines Projekts zugeordnet ist, eine Verlaufsservertabelle, die eine Liste der Verlaufsserver enthält, welche mit dem Projekt-Arbeitsraum verbunden sind. Die Verlaufsservertabelle behält ebenfalls einen Zustand für jeden Server bei, der identifiziert, ob eine Transaktion, die auf diesem Server ausgeführt wurde, den "Commit"-Zustand (Übergeben-Zustand) erreicht hat. Zu Beginn der Verarbeitung eines CreateDraft-Befehls wird der Zustand, der dem Verlaufsserver-Tabelleneintrag eines jeden Verlaufsservers zugeordnet ist, der alle neu erzeugten oder geänderten Komponenten speichert, auf einen "NeedToCommit"-Zustand (Muß-übergeben-werden) gesetzt.
Der CreateDraft-Befehl verwendet zuerst die Verlaufsservertabelle, um die Gruppe der Verlaufsserver zu identifizieren, die an der zusammengesetzten Transaktion beteiligt sind. Als nächstes wird jedes Mitglied einer zusammengesetzten Transaktion, bei der einer der Verlaufsserver beteiligt ist, verarbeitet, und es muß den "Commit"-Zustand erreichen (Daten empfangen und übergeben), bevor das nächste Mitglied verarbeitet wird. Wenn alle Mitgliedstransaktionen den "Commit"-Zustand erreichen, wird der Zustandseintrag für diesen Verlaufsserver in der Verlaufsservertabelle auf "Comitted" (Übergeben) gesetzt.
Im Falle eines Fehlers während der Untertransaktionsverarbeitung auf einem Verlaufsserver bleibt der Zustand jenes Verlaufsservers, wie er in der Verlaufsservertabelle gespeichert ist, als "NeedToCommit". Von allen Komponenten, die zu einem Verlaufsserver gehören, wird angenommen, daß sie sich im selben Zustand befinden wie ihr entsprechender Verlaufsserver. Nachdem die Verarbeitung (so weit wie möglich) auf einem bestimmten Verlaufsserver abgeschlossen ist, geht die Verarbeitung zum nächsten Mitglied der zusammengesetzten Transaktion weiter, und so fort.
Nachdem die Verarbeitung abgeschlossen ist, wird die Verlaufsservertabelle überprüft, und jene Verlaufsserver mit einem Eintragszustand "NeedToCommit" stellen jene Programmkomponenten dar, die aufgrund eines Fehlers neu verarbeitet werden müssen. Diese Komponenten werden erneut verarbeitet, um übergeben zu werden, nachdem der Fehler behoben wurde.

ENTWURF-WIEDERAUFFINDEN-ROUTINE

Nach Herstellung der Verbindung zum Verlaufsserver, der den Verlauf eines gegebenen Projektes verwaltet, ist der Projekt-Arbeitsraum leer, und es ist notwendig, ältere Entwürfe der Programmkomponenten wiederaufzufinden, um mit der Verwendung des Arbeitsraumes zu beginnen. Zuerst kann der Arbeitsraum nach Herstellung der Verbindung zum zugeordneten Verlaufsserver eine Verlaufs-/Konfigurationsbetrachterroutine im Projekt verwenden, um die verschiedenen Entwürfe der Konfigurationen des Projekts zu überprüfen. Nachdem ein gewünschter Entwurf identifiziert ist, werden die Komponentenentwürfe durch Aufruf des Retrieve- Draft-Befehls wiederaufgefunden, der eine Wurzelkomponentenkennung und eine Entwurfskennung angibt.
Als Reaktion auf diesen Befehl findet der Verlaufsserver den in der Datenbank gespeicherten identifizierten Wurzelkomponentenentwurf auf und durchwandert mit Hilfe der Mitgliedereigenschaft der Wurzelkomponente den Wurzelkomponentenentwurf und gibt die enthaltenen Komponentenentwürfe und alle ihre entwurffähigen Eigenschaften zum Client- Projekt-Arbeitsraum zurück. Brückenobjekte, die Verbindun gen zu den anderen Servern beschreiben, werden als Teil der Mitgliedereigenschaften der Komponenten zurückgegeben.
Bei Empfang der Komponenteninformationen erzeugt der Projekt-Arbeitsraum Komponenten und Eigenschaften aufgrund der Informationen, die der Verlaufsserver gesendet hat. Der Projekt-Arbeitsraum empfängt auch die Brückenobjekte, stellt die benötigten Verbindungen her und überträgt die erforderlichen Anforderungen an die neu verbundenen Server, um zusätzliche Komponentenentwürfe wiederaufzufinden.
Der RetrieveDraft-Befehl kann auch zusätzliche Entwürfe einer gegebenen Komponente und deren Abkömmlinge für Vergleichs-Misch-Operationen wiederauffinden. Diese wiederaufgefundenen Komponenten werden als Waisenkomponenten bezeichnet, da sie nicht zur Konfiguration des Projekt- Arbeitsraumes gehören. Das Wiederauffinden dieser Komponenten ist für den Benutzer nicht sichtbar und wird von den Befehlen GetComponent() und ComponentExists() initiiert. Der GetComponent() Befehl bewirkt, daß die Komponente aus dem Projekt-Arbeitsraum wiederaufgefunden wird. Ein ComponentExists () Befehl gibt einen Wert zurück, der angibt, ob die angeforderte Komponente im Arbeitsraum vorhanden ist. Wenn ein normaler GetComponent()- oder ComponentExists()- Befehl die Komponente im Arbeitsraum nicht finden kann und es im zugeordneten Verlaufsserver eine Komponente mit der angegebenen Komponenten- und Versionskennurig gibt, initiiert der Arbeitsraum automatisch einen Wiederauffindevorgang und gibt die entsprechende Komponente vom zugeordneten Verlaufsserver zurück.
Ein zusätzliches Leistungsmerkmal von Waisenkomponenten ist, daß die zugeordneten Eigenschaften auf Verlangen wiederaufgefunden werden können, und zwar wahlweise durch die Verwendung des Befehls GetProperty() und Property- Exists(), die parallel zu den Befehlen GetComponent() und Component Exists() sind. Der Vorgang des Wiederauffindens einer Eigenschaft von seinem Verlaufsserver ist für den Benutzer ebenfalls unsichtbar; wenn ein normaler GetProperty()- oder PropertyExists()-Befehl die angeforderte Eigen schaft im Arbeitsraum nicht findet, holt der Arbeitsraum die angeforderte Eigenschaft automatisch vom zugeordneten Verlaufsserver.
Die bei der Verarbeitung eines RetrieveDraft-Befehls verwendeten Schritte sind in Fig. 9 dargestellt. Insbesondere beginnt die Routine bei Schritt 900 und geht zu Schritt 902 weiter, wo eine RetrieveDraft-Anforderung (Entwurf wiederauffinden) vom Projekt-Arbeitsraum zum Verlaufsserver gesandt wird, der die Projektwurzelkomponente speichert. Diese Anforderung umfaßt eine Komponentenkennung und die Entwurfskennung der Wurzelkomponente des Projekts. Als Reaktion auf diese Anforderung überprüft der Verlaufsserver bei Schritt 903 die Mitgliedseigenschaft der identifizierten Wurzelkomponente, um jene Komponenten zu bestimmen, welche die Projektkonfiguration umfassen. Wenn bei Schritt 903 eine Entscheidung getroffen wird, daß es weitere Mitglieder gibt, die verarbeitet werden müssen, geht die Routine zu Schritt 904 weiter und zum nächsten Mitglied, das zu verarbeiten ist.
Bei Schritt 906 wird das nächste Mitglied überprüft, um den Typ zu bestimmen. Wenn das Mitglied eine Komponente ist, geht die Routine zu Schritt 908 weiter, wo der Komponentenentwurf und zugeordnete Eigenschaften zum Projekt- Arbeitsraum zurückgegeben werden, und bei Schritt 912 werden die Komponente und ihre Eigenschaften im Projekt- Arbeitsraum erzeugt.
Wenn alternativ dazu bei Schritt 906 bestimmt wird, daß es sich bei dem Mitglied um ein Brückenobjekt handelt, geht die Routine zu Schritt 910 weiter, wo das Brückenobjekt zum Projekt-Arbeitsraum zurückgegeben wird, und bei Schritt 911 werden die Brückeninformationen im Projekt- Arbeitsraum verwendet, um eine Verbindung zu einem anderen Verlaufsserver herzustellen, um zusätzliche Komponenteninformationen aufzufinden.
Die Routine kehrt entweder bei Schritt 911 oder 912 zurück zu Schritt 903, wo die Mitgliedereigenschaft der Wurzelkomponente auf weitere zu verarbeitende Schritte überprüft wird. Wenn weitere Schritte zu verarbeiten sind, werden die Schritte 904-912 wiederholt. Wenn keine weiteren Mitglieder mehr zu verarbeiten sind, endet die Routine bei Schritt 914.
So wie bei den Verbindungs- und CreateDraft-Befehlen werden Informationen zwischen den Projekt-Arbeitsräumen und dem zugeordneten Verlaufsserver mit Hilfe von Vermittlerobjekten hin- und hergeleitet, die von einer Klasse erzeugt werden, die von der TAgent-Klasse mit dem Namen TRetrieve- DraftAgent-Klasse abstammt. Objekte, die von dieser Klasse erzeugt werden, finden einen Unterbaum von Komponenten von einem angegebenen Verlaufsserver auf, wo die Wurzel des Unterbaums durch eine Referenz festgelegt wird, die dem Vermittler vom Projekt-Arbeitsraum zur Verfügung gestellt wird, wenn der Vermittler erzeugt wird. Im Verlaufe des Auffindens kann es sich bei einigen der Knoten nicht um Komponenten, sondern um Brücken handeln, aber die Brücken ermöglichen das Auffinden anderer Unterbäume von Komponenten, die sich auf anderen Verlaufsservern befinden. Die Kopie des TRetrieveDraftAgent-Objektes, die zum Verlaufsserver geschickt wird, sammelt einfach alle gefundenen Brücken und gibt die Brückeninformationen an den Projekt- Arbeitsraum zurück. Wie zuvor beschrieben werden die Brükkeninformationen vom Projekt-Arbeitsraum verarbeitet. Wenn eine Komponente, die von einem Komponentenkennungs- und Entwurfskennungspaar definiert wird, wiederaufgefunden wird, sind die folgenden Ergebnisse im Projekt- Arbeitsraum möglich:
Σ (1) Es ist keine andere Komponente mit der Komponentenkennung vorhanden
Σ (2) es ist eine Komponente mit der selben Komponentenkennung, aber mit einer unterschiedlichen Entwurfskennung vorhanden, und sie ist Teil der aktuellen Konfiguration
Σ (3) es ist eine Komponente mit der selben Komponentenkennung und Entwurfskennung vorhanden, und sie ist Teil der aktuellen Konfiguration
S (4) es ist eine Komponente mit der selben Komponentenkennung und Entwurfskennung vorhanden, aber es ist eine Waisenkomponente
Σ (5) es ist eine Komponente mit der selben Komponentenkennung und Entwurfskennung vorhanden, aber sie ist gelöscht
In den Fällen (4) und (5) oben löscht das ursprüngliche TRetrieveDraftAgent-Objekt, das während der Retrieve- Draft-Transaktionen im Projekt-Arbeitsraum bleibt, die Komponente im Projekt-Arbeitsraum, bevor es eine neue Komponente erzeugt.
Im Fall (3) markiert das TRetrieveDraftAgent-Objekt die bestehende Komponente als "SameComponent" (selbe Komponente) und überspringt die wiederaufgefundene Komponente. Im Fall (2) markiert das TRetrieveDraftAgent-Objekt die bestehende Komponente als "OldDraftComponent" (altes Entwurfsobjekt) und ihre eventuell vorhandenen Unterkomponenten als "StaleComponents" (alte Komponenten).
Alle Komponenten, die als Teil eines RetrieveDraft- Befehls erzeugt werden, werden als "RetrievedComponent" (wiederaufgefundene Komponente) markiert, und standardmäßig werden alle anderen Komponenten als "NormalComponent" (normale Komponente) markiert.
Die aufgelisteten Zustände helfen dem Projekt- Arbeitsraum, zu entscheiden, welche Komponenten am Ende der Wiederauffindeoperation gelöscht werden sollen. Insbesondere werden alle Komponenten gelöscht, die als "StaleComponent" markiert wurden. Darüber hinaus werden alle Komponenten gelöscht, die als "OldDraftComponents" markiert wurden. Komponenten, die als "NormalComponents" markiert wurden, bleiben unverändert. Wenn während des Wiederauffindevorgangs ein Problem oder eine Ausnahme aufgetreten ist, kann der Projekt-Arbeitsraum einfach den Wiederauffindevorgang abbrechen und alle Komponenten löschen, die als "RetrievedComponent" markiert wurden, und alle Komponenten im System als "NormalComponent" zurücksetzen.
Ein anderes ähnliches Vermittlerobjekt wird ebenso während eines Wiederauffindevorgangs verwendet. Es wird von einer TRetrieveOrphanDraftAgent-Klasse erzeugt. Dessen Operation unterscheidet sich insoferne etwas vom TRetrieve- DraftAgent-Objekt, als daß das TRetrieveOrphanDraftAgent- Objekt in den Fällen (3) und (4) das Wiederauffinden der Komponente überspringt. In allen anderen Fällen wird das Wiederauffinden der Komponente übersprungen.

ENTWURF GEMEINSAM BENUTZTER PROJEKTE

Eine andere Möglichkeit, wie das System die Erstellungszeitkonsistenz beibehalten kann, besteht darin, zu verfolgen, welche Konfiguration der Komponenten eines Programms zur Erzeugung eines bestimmten ablauffähigen Programms verwendet wurde. Diese Konfigurationsinformationen werden sowohl am ausführbaren Programm als auch an einem speziellen Projekt markiert, das nur zum Kompilieren, Verknüpfen und Laden gegen das ausführbare Programm verwendet wird. Dieses spezielle Projekt wird als gemeinsam benutztes Projekt bezeichnet.
Wenn gemeinsam benutzte Projekte involviert sind, kommuniziert das System mit dem Benutzer und informiert ihn bezüglich der Gruppe gemeinsam benutzter Projekte, die in Verwendung standen, als ein bestimmter Entwurf der Projektkonfiguration erzeugt wurde. Der Hauptpunkt beim Entwurf gemeinsam benutzter Projekte ist die Beibehaltung einer konsistenten Betriebsumgebung hinsichtlich Operationen, die ein bestimmtes gemeinsam benutztes Projekt in einer bestimmten Erstellungsoperation erfordern. Nehmen wir zum Beispiel an, daß eine Projekterstellung einer Komponentenbibliothek ein bestimmtes gemeinsam benutztes Speicherbibliothek-Projekt verwendet, und die spezifische Instanz der Komponentenbibliothek entworfen wurde. In diesem Fall ist es für das System wesentlich, den Entwickler über die Verwendung jenes gemeinsam benutzten Speicherbibliothekprojekts bei einem darauffolgenden Wiederauffindevorgang jenes bestimmten Entwurfes der Komponentenbibliothek zu informieren.
Ein Entwurf der Projektkomponente verwaltet eine Liste der Brücken des gemeinsam benutzten Projektes als Teil ihrer entworfenen Mitgliedereigenschaft. Jede Brücke des gemeinsam benutzten Projektes verwaltet die Komponentenkennung der Wurzelkomponente des gemeinsam benutzten Projektes, die Entwurfskennung der Wurzelkomponente des gemeinsam benutzten Projektes, die Verlaufsserverdaten, die zum Auffinden und Verbinden mit dem Verlaufsserver des gemeinsam benutzten Projektes notwendig sind, und Informationen, die zur Erzeugung eines Dokumentenmodells erforderlich sind, das benötigt wird, um das aktuelle Dokument (Datenbank) des gemeinsam benutzten Projektes zu finden und darauf zuzugreifen.
Jedes gemeinsam benutzte Projekt enthält die folgenden Informationen: die Komponentenkennung der Wurzelkomponente, die Entwurfskennung der Wurzelkomponente, Dokumentmodelldaten, und die Verlaufsserverdaten, die den Server identifizieren, auf dem der Verlauf der Wurzelkomponente des gemeinsam benutzten Projektes verwaltet wird. Mit diesen Informationen im gemeinsam benutzten Projekt kann ein Entwickler die historischen Informationen bezüglich Komponenten des gemeinsam benutzten Projekts überprüfen. Zum Beispiel kann ein Entwickler eine Verbindung zum Verlaufsserver herstellen, von dem die Komponenten im gemeinsam benutzten Projekt abstammen, und den Verlauf betrachten. Umgekehrt ist das gemeinsam benutzte Projekt in der Lage, die Serverinformationen zu benutzen, um eine Verbindung zum Verlaufsserver herzustellen und den entsprechenden Verlaufsbetrachter zu aktivieren.
Mit Hilfe dieser Art von Querverweisen zwischen dem gemeinsam benutzten Projekt und dem Verlauf ist es möglich, daß das System (auf eine beratende Art und Weise) eine Konsistenz in der Umgebung durchsetzt.

Claims

1. Ein Verfahren zur Benutzung in einem Computernetzwerk, das ein Client-Terminal (206) und einen Server (200) aufweist, mit den Schritten des Assemblierens eines Softwareprogramms (506) in einem Projekt-Arbeitsraum (207, 500) am Client-Terminal (206) durch Verwendung einer Vielzahl von Programmkomponenten (508. 510, 512) und Anordnen einer Vielzahl von Programmkomponenten (508, 510, 512) in einer Baumstruktur (506),

das Verfahren ist dadurch gekennzeichnet, daß die Programm-Komponenten erhalten werden durch:

A. Erzeugen einer Komponenten-Datenbank (520) in dem Server (200) und Speichern (816) von Entwürfen (522, 524, 526, 528, 530) der Programmkomponenten (508, 510, 512) in der Komponenten-Datenbank (520), die einen Wurzelkomponenten-Entwurf (522) enthalten zum Identifizieren von mit dem Softwareprogramm verbundenen Programmkomponenten-Entwürfen;

B. Benutzen (902) von Informationen (502, 504) in dem Projekt-Arbeitsraum (500) zum Wiederauffinden des Wurzelkomponenten-Entwurfes (522) in der Komponenten-Datenbank (520);

C. Benutzen (906) von Mitgliedstypen-Informationen in der wiederaufgefundenen Wurzelkomponente (508) zum Identifizieren von Programmkomponenten-Entwürfen (522, 524, 526, 528, 530), die zu dem Softwareprogramm gehören;

D. Wiederauffinden (908) von identifizierten Programmkomponenten-Entwürfen (522, 524, 526, 528, 530); und

E. Erzeugen (912) der Programmkomponenten (510, 512) aus Informationen in den wiedergewonnenen Programmkomponenten-Entwürfen.

2. Ein Verfahren gemäß Anspruch 1, worin Schritt A den Schritt umfaßt:

A1. Speichern einer Vielzahl von Wurzelkomponenten- Entwürfen (522, 528) in der Komponenten-Datenbank (520);

und Schritt B den Schritt umfaßt:

B1. Auswählen von einem (508) der Vielzahl von Wurzelkomponenten-Entwürfen (522, 528) zum Wiederauffinden.

3. Ein Verfahren gemäß Anspruch 1, worin Schritt A die Schritte umfaßt:

A2. Erzeugen einer ersten Komponenten-Datenbank (520), die einen Wurzelkomponenten-Entwurf (522) enthält;

A3. Speichern (806, 810, 812, 814, 816) von einigen der Programmkomponenten-Entwürfe (524, 526, 530), die mit dem Softwareprogramm in der ersten Komponenten- Datenbank (520) verbunden sind;

A4. Erzeugen einer zweiten Komponenten-Datenbank (422); und

A5. Speichern (808) von einigen der Programmkomponenten- Entwürfe (424, 426), die mit dem Softwareprogramm in der zweiten Komponenten-Datenbank (422) verbunden sind.

4. Ein Verfahren gemäß Anspruch 3, worin Schritt A weiter den Schritt umfaßt:

A6. Hinzufügen (808) von Mitgliedstypen-Informationen zum Wurzelkomponenten-Entwurf (522), die in der ersten Komponenten-Datenbank (520) enthaltene Programmkomponenten-Entwürfe (524, 526, 530) und Brückenobjekt-Informationen zum Lokalisieren der zweiten Komponenten-Datenbank (422) identifizieren.

5. Ein Verfahren gemäß Anspruch 4, weiter die Schritte umfassend:

F. Wiederauffinden (910) der Brückenobjekt- Informationen zum Lokalisieren der zweiten Komponenten-Datenbank (422) von der Wurzelkomponente (508); und

G. Benutzen (911) der Brückenobjekt-Informationen zum Herstellen von Verbindungen zur zweiten Komponenten- Datenbank (422) und zum Wiederauffinden von Programmkomponenten-Entwürfen (424, 426).

6. Ein Verfahren gemäß Anspruch 1, worin die Softwareprogramm-Komponenten (510, 512) aus einer Vielzahl von Komponentenarten und Eigenschaftsarten betehen und worin das Verfahren weiter den Schritt umfaßt:

H. Speichern der Vielzahl von Komponentenarten und Eigenschaftsarten (502) in dem Projekt-Arbeitsraum (500).

7. Ein Verfahren gemäß Anspruch 6, das weiter den Schritt umfaßt:

I. Senden der Vielzahl von Komponentenarten und Eigenschaftsarten (502) von dem Projekt-Arbeitsraum (500) zu einer Datei (518) in dem Server (514).

8. Ein Verfahren gemäß einem jeden der vorhergehenden Ansprüche, worin Schritt B die Schritte umfaßt:

B2. Erzeugen (704) eines Vermittler-Objekts (604) im Projekt-Arbeitsraum (600), das Mittel zum Assemblieren (702) von Informationen, die sich auf das Softwareprogramm beziehen, Mittel zum Herstellen eines Kommunikationsweges von dem Client-Terminal zum Server (703), und Mittel zum Identifizieren und Wiederauffinden von Programmkomponenten-Entwürfen umfaßt;

B3. Erzeugen (708) einer Kopie des Vermittler-Objekts in dem Projekt-Arbeitsraum (600);

B4. Senden (710, 712, 714) der Kopie des vermittler- Objekts von dem Projekt-Arbeitsraum zum Server (602) zum Wiederauffinden der Programmkomponenten-Entwürfe (606); und

B5. Löschen der Kopie des Vermittler-Objekts im Server (602).

9. Ein Verfahren gemäß Anspruch 8, worin der Server (602) eine Vielzahl von Serverobjektmethoden umfaßt zur Ausführung von Aufgaben im Server (602) und worin Schritt B2 den Schritt umfaßt:

B2a. Erzeugen (704) des Vermittler-Objekts mit einer Vielzahl von Vermittlerobjektmethoden zum Aufrufen von wenigstens einer der Serverobjektmethoden.

10. Ein Verfahren gemäß Anspruch 9, worin Schritt B2 weiter den Schritt umfaßt:

B2b. Erzeugen (704) des Vermittler-Objekts mit Mitteln zum Empfangen von Resultaten (714) vom Server (602).

11. Ein Verfahren gemäß Anspruch 8, worin Schritt B4 den Schritt umfaßt:

B4a. Empfangen der Kopie des Vermittler-Objekts; und

B4b. Ausführen der Vermittlerobjektmethoden (712).

12. Einrichtung zur Benutzung in einem Computernetzwerk, das ein Client-Terminal (206) und einen Server (200) aufweist, mit Mitteln zum Assemblierens eines Softwareprogramms (506) in einem Projekt-Arbeitsraum (207, 500) am Client- Terminal (206), mit Mitteln zum Erlangen einer Vielzahl von Programmkomponenten (508, 510, 512) und mit Mitteln zum Anordnen einer Vielzahl von Programmkomponenten (508, 510, 512) in einer Baumstruktur (506)

die Einrichtung ist dadurch gekennzeichnet, daß die Mittel zum Erlangen umfassen:

Mittel zum Erzeugen einer Komponenten-Datenbank (520) in dem Server (200) und zum Speichern (816) von Entwürfen (522, 524, 526, 528, 530) der Programmkomponenten (508, 510, 512) in der Komponenten-Datenbank (520), die einen Wurzelkomponenten-Entwurf (522) enthalten zum Identifizieren von mit dem Softwareprogramm verbundenen Programmkomponenten-Entwürfen;

Mittel, die auf Informationen (502, 504) in dem Projekt-Arbeitsraum (500) ansprechen zum Wiederauffinden des Wurzelkomponenten-Entwurfes (522) in der Komponenten-Datenbank (520);

Mittel, die auf Informationen (Mitglieder) in der wiederaufgefundenen Wurzelkomponente (508) ansprechen zum Identifizieren von Programmkomponenten-Entwürfen (522, 524, 526, 528, 530), die zu dem Softwareprogramm gehören;

Mittel zum Wiederauffinden (908) von identifizierten Programmkomponenten-Entwürfen (522, 524, 526, 528, 530); und

Mittel zum Erzeugen (912) der Programmkomponenten (510, 512) aus Informationen in den wiedergewonnenen Programmkomponenten-Entwürfen.

13. Einrichtung gemäß Anspruch 12, worin die Mittel zum Erzeugen einer Komponenten-Datenbank Mittel umfassen zum Speichern einer Vielzahl von Wurzelkomponenten-Entwürfen (522, 528) in der Komponenten-Datenbank (520); und die Mittel zum Wiederauffinden des Wurzelkomponenten-Entwurfes Mittel umfassen zum Auswählen von einem (508) der Vielzahl von Wurzelkomponenten-Entwürfen (522, 528) für ein Wiederauffinden.

14. Einrichtung gemäß Anspruch 12, worin die Mittel zum Erzeugen einer Komponenten-Datenbank Mittel umfassen:

Mittel zum Erzeugen einer ersten Komponenten-Datenbank (520), die einen Wurzelkomponenten-Entwurf (522) enthält;

Mittel zum Speichern (806, 810, 812, 814, 816) von einigen der Programmkomponenten-Entwürfe (524, 526, 530), die mit dem Softwareprogramm in der ersten Komponenten-Datenbank (520) verbunden sind;

Mittel zum Erzeugen einer zweiten Komponenten-Datenbank (422); und

Mittel zum Speichern (808) von einigen der Programmkomponenten-Entwürfe (424, 426), die mit dem Softwareprogramm verbunden sind, in der zweiten Komponenten-Datenbank (422).

15. Einrichtung gemäß Anspruch 14, worin die Mittel zum Erzeugen einer Komponenten-Datenbank weiter Mittel umfassen zum Hinzufügen (808) von Informationen (Mitglieder) zum Wurzelkomponenten-Entwurf (522), die in der ersten Komponenten-Datenbank (520) enthaltene Programmkomponenten-Entwürfe (524, 526, 530) und Informationen (Brückenobjekte) zum Lokalisieren der zweiten Komponenten-Datenbank (422) identifizieren.

16. Einrichtung gemäß Anspruch 15, weiter umfassend

Mittel zum Wiederauffinden (910) der Informationen (Brückenobjekte) zum Lokalisieren der zweiten Komponenten-Datenbank (422) von der Wurzelkomponente (508); und

Mittel zum Benutzen (911) Informationen (Brückenobjekte) zur Herstellung von Verbindungen zur zweiten Komponenten-Datenbank (422) und zum Wiederauffinden von Programmkomponenten-Entwürfen (424, 426)

17. Einrichtung gemäß Anspruch 12, worin die Softwareprogramm- Komponenten (510, 512) aus einer Vielzahl von Komponentenarten und Eigenschaftsarten bestehen und worin die Einrichtung weiter Mittel umfaßt zum Speichern der Vielzahl von Komponentenarten und Eigenschaftsarten (502) in dem Projekt-Arbeitsraum (500).

18. Einrichtung gemäß Anspruch 17, das weiter Mittel umfaßt zum Senden der Vielzahl von Komponentenarten und Eigenschaftsarten (502) von dem Projekt-Arbeitsraum (500) zu einer Datei (518) in dem Server (514).

19. Einrichtung gemäß einem jeden der vorhergehenden Ansprüche, worin die Mittel zum Wiederauffinden des Wurzelkomponenten-Entwurfes umfassen:

Mittel zum Erzeugen (704) eines Vermittler-Objekts (604) im Projekt-Arbeitsraum (600), das Mittel zum Assemblieren (702) von Informationen, die sich auf das Softwareprogramm beziehen, Mittel zum Herstellen eines Kommunikationsweges von dem Client-Terminal zum Server (703) und Mittel zum Identifizieren und Wiederauffinden von Programmkomponenten-Entwürfen umfaßt;

Mittel zum Erzeugen (708) einer Kopie des Vermittler-Objekts in dem Frojekt-Arbeitsraum (600);

Mittel zum Senden (710, 712, 714) der Kopie des Vermittler-Objekts von dem Projekt-Arbeitsraum zum Server (602) zum Wiederauffinden der Programmkomponenten-Entwürfe (606); und

Mittel zum Löschen der Kopie des Vermittler-Objekts im Server (602).

20. Einrichtung gemäß Anspruch 19, worin der Server (602) eine Vielzahl von Serverobjektmethoden umfaßt zur Ausführung von Aufgaben im Server (602) und worin die Mittel zum Erzeugen einer Kopie des Vermittler-Objekts Mittel umfassen zum Erzeugen (704) des Vermittler-Objekts mit einer Vielzahl von Vermittlerobjektmethoden für einen Aufruf von wenigstens einer der Serverobjektmethoden.

21. Einrichtung gemäß Anspruch 20, worin die Mittel zum Erzeugen einer Kopie des Vermittler-Objekts weiter Mittel umfassen zum Erzeugen (704) des Vermittler-Objekts mit Mitteln zum Empfangen von Resultaten (714) vom Server (602).

22. Einrichtung gemäß Anspruch 19, worin die Mittel zum Senden der Kopie des Vermittler-Objekts Mittel umfassen zum Empfangen der Kopie des Vermittler-Objekts und Mittel zum Ausführen der Vermittlerobjektmethoden (712).