DE3855475T2

DE3855475T2 - Software-Verwaltungsstruktur

Info

Publication number: DE3855475T2
Application number: DE3855475T
Authority: DE
Inventors: Nathaniel Calvert; James Scott Effle; David Lowry Johnston; James Lee Naylor; Helen Marie Olsen-Williams; Robert Harry Satin; Dennis Lee Shaffer; Gary Albert Turk
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1987-11-18
Filing date: 1988-10-11
Publication date: 1997-02-06
Anticipated expiration: 2008-10-12
Also published as: EP0317477A3; BR8806033A; AU2431888A; US5553290A; CN1013619B; US5237688A; KR890008675A; AU622628B2; EP0317477B1; JP2531763B2; CA1304515C; KR940002235B1; DE3855475D1; JPH01161531A; CN1035375A; EP0317477A2

Description

Diese Erfindung betrifft das Gebiet der Datenverarbeitung. Genauer, diese Erfindung betrifft eine Verpackungsstruktur für Computersoftware, wobei das Softwareprogramm aus mehreren auswechselbaren Einheiten zusammengesetzt ist, die in einer mehrstufigen hierarchischen Form angeordnet sind.
Die Datenverarbeitung hat sich bis zu einem Punkt entwickelt, an dem die Benutzer erwarten, daß ihr Computer seine eigenen Betriebsmittel mit minimaler menschlicher Einmischung verwaltet. Es wurden Anstrengunqen unternommen, mit Hilfe von Verfahren zur automatischen Konfiguration und Problembestimmung, den Hardwareteil eines Computersystems zu verwalten, aber nur wenige Anstrengungen wurden unternommen, um den Softwareteil eines Computersystems wirksam zu steuern und zu verwalten.
Ein typischer Benutzer benötigt heutzutage mehrere verschiedene Programme, um seine spezielle Anwendung auszuführen. Diese Programme sind häufig von verschiedenen Programmentwicklern erstellt. Jedes Programm weist Abhängigkeiten sowohl von der Hardware als auch von der Software auf, und es wird für die Benutzer oder Anwendungsentwickler zunehmend schwieriger, ein funktionierendes System zusammenzufügen, bei dem alle Abhängigkeiten berücksichtigt sind. Zudem kann die korrekte Punktion eines Softwareprogramms davon abhängen, ob ein anderes Softwareprogramm in einem bestimmten Zustand oder in einem bestimmten Release-Level vorliegt. Häufig ist die einzige Möglichkeit für einen Benutzer, ein Abhängigkeitsproblem zu beheben, die empirische Fehlersuchmethode oder ein mühsames Studium einer Vielzahl von Referenz-Handbüchern.
Die Struktur eines Softwareprogramms wird häufig dem persönlichen Stil oder der Laune des jeweiligen Programmentwicklers überlassen. Es ist heutzutage selten, daß zwei Softwareprogramme eine übereinstimmende Struktur aufweisen, so daß ein Programm problemlos Informationen aus dem anderen Programm entnehmen kann, wie beispielsweise Level und Abhängigkeiten, selbst wenn beide Programme vom selben Hersteller entwickelt wurden.
Ein weiteres Problem, das sich Programmentwicklern und Benutzern heutzutage stellt, ist, daß Programme nach wie vor Fehler aufweisen, die behoben werden müssen. Üblicherweise muß der Programmentwickler ein vollständig neues Programm an jeden Benutzer schicken, um den Fehler zu beheben; es gibt keine effiziente Methode, einen kleinen Teil des Codes, der den Fehler aufweist, zu ersetzen.
Die Aufgabe eines Anwendungsentwicklers ist heutzutage mehr und mehr komplexer geworden. Wenn der Benutzer dem Anwendungsentwickler mitteilt, daß er ein Anwendungspaket wünscht, das seine spezifischen Erfordernisse abdeckt, kann der Anwendungsentwickler Probleme damit haben, die Erfordernisse des Benutzers abzudecken, und gleichzeitig die Flexibilität für zukünftige Erweiterungen zu erhalten. Häufig muß sich der Anwendungsentwickler für ein kostspielig-unstrukturiertes Konglomerat von Mehrzweckprogrammen entscheiden, das entweder Funktionen bereitstellt, die der Benutzer nicht benötigt, oder nicht alle Funktionen bereitstellt, die der Benutzer benötigt. Zusätzlich belegt das Konglomerat von Mehrzweckprogrammen durch die Speicherung von Funktionen, die der Benutzer nicht benötigt, uneffizienterweise mehr Speicherplatz als erforderlich. Dies kann ein besonderes Problem für Benutzer darstellen, die bereits ihren gesamten Speicher belegt haben und keine weiteren, benötigten Programme auf ihren Computern speichern können.
Die Programmentwickler möchten zweifelsfrei jeden einzelnen Benutzer mit seinem Programm zufriedenstellen. Es ist jedoch heutzutage viel zu kostspielig, ein kundenspezifisches Programm zu entwickeln, welches die Anforderungen jedes einzelnen Benutzers erfüllt. Die Programmentwickler möchten ein Programm entwickeln, welches die Anforderungen eines jeden Benutzers erfüllt, vom einen Benutzer, der alle Funktionen des Programmes benötigt, bis zum anderen Benutzer, der nur eine Funktion des Programmes benötigt. Wenn dies möglich wäre, könnte der Programmentwickler jedem Benutzer nur die Funktionen in Rechnung stellen, die er benutzt. Wenn die Anforderungen des Benutzers steigen, könnten dem Benutzer weitere Funktionen des gleichen Programmes für eine zusätzliche Gebühr zugänglich gemacht werden.
Ein Artikel von B. Nicolas u. a.: "VM/Software Engineering", ELECTRICAL COMMUNICATION, Vol 61, No. 4, 26.02.1986, Brüssel, Seite 453 - 458, betrifft ein VM/SE Hilfsmittel, welches es ermöglicht, die Inkompatibilität von traditionellen Softwareentwicklungen durch Bereitstellung einer Software-Verwaltung und Steuerumgebung zu überwinden, und welches unabhängig von individuellen Hilfsmitteln ist. Das VM/SE ist ein objektorientiertes und offenes System, ausgerichtet auf eine Architektur, die einen Host-Computer beinhaltet, an den mehrere Benutzer angeschlossen sind, die spezifische Funktionen benutzen. Dieser Artikel offenbart das Hauptkonzept eines VM/SE Objektes, welches aus einem Beschreibungsteil, der dessen individuellen Charakteristika und seine Beziehungen zu anderen Objekten beinhaltet, und einem Hauptteil besteht. Obwohl dieser Artikel sogar die verschiedenen Möglichkeiten von VM/SE beschreibt, erwähnt er nicht, wie die hierarchische Software- Verwaltungsstruktur zu organisieren ist, mit Ausnahme des Umstandes, daß VM/SE in einer Umgebung benutzt wird, in der die oberste Ebene mit einem bereitgestellten Softwareprodukt korrespondiert. Darüberhinaus basiert dieser Artikel im wesentlichen auf einer speziellen VM/SE Umgebung.
Es ist eine grundsetzliche Aufgabe der Erfindung eine effektive Verwaltung von Softwareprogrammen in einem Datenverarbeitungssystem bereitzustellen.
Es ist eine weitere Aufgabe der Erfindung, eine Packungsstruktur für Computersoftware bereitzustellen, wobei ein Anwendungspaket aus mehreren auswechselbaren Einheiten zusammengesetzt ist, die in einer mehrstufigen hierarchischen Form angeordnet sind.
Es ist noch eine weitere Aufgabe der Erfindung, für das Anwendungspaket selbst-identifizierende Informationen, wie etwa Wartungslevel und Abhängigkeiten von Hardware und anderer Software als einen integralen Teil seiner hierarchischen Struktur einzubinden.
Es ist noch eine weitere Aufgabe der Erfindung, Packungs- Hilfsmittel bereitzustellen, die von Programmentwicklern verwendet werden können, um ein Programmpaket zu bilden, und von Anwendungsentwicklern verwendet werden können, um ein Anwendungspaket zu bilden.
Diese und andere Aufgaben sind erfüllt durch die Software- Verwaltungsstruktur, wie sie im Patentanspruch 1 definiert ist, und durch das zugehörige Verfahren zum Organisieren einer Software-Verwaltungsstruktur, wie es im Patentanspruch 14 definiert ist.
Ein Software-Anwendungspaket wird aus verschiedenen, miteinander verbundenen, auswechselbaren Einheiten (Replaceable Units, RU) zusammengesetzt. Jede RU kann gewartet werden, ohne die anderen RUs nachteilig zu beeinflußen. Die RUs sind in einer hierarchischen Gestalt in einer Reihe von Ebenen angeordnet. In der bevorzugten Ausführungsform werden fünf Ebenen verwendet: Ebene der Anwendungsgruppe (Application Group level, AG), Ebene der ladbaren Codegruppen (Loadable Code Group level, LCG), Ebene der primären funktionellen Gruppe (Primary Functional Group level, PFG), Ebene der sekundären funktionellen Gruppe (Secondary Functional Group level, SFG) und Ebene der operationalen Codegruppen (Operational Code Group level, OCG) Die AG-Ebene definiert eine Gruppe von Computerprogrammen, die kombiniert werden, um eine High-Level-Anwendung zu bilden, die maßgeschneidert ist, um die Anforderungen des Benutzers zu erfüllen. Die LCG-Ebene definiert individuelle Programme, von denen jedes erstellt wurde, um eine allgemeine Aufgabe abzuarbeiten. Die PFG-Ebene verfeinert die gemeinsamen Programme, die in der LCG-Ebene definiert wurden, zu einem spezifischeren Satz von primären Funktionen. Die SFG-Ebene verfeinert die primären Funktionen, die in der PFG-Ebene definiert wurden, zu einem noch weiter spezifizierten Satz von sekundären Funktionen, maßgeschneidert, um die spezifischen Benutzeranforderungen zu erfüllen. Die OCG-Ebene enthält den operationalen Code, der erforderlich ist, um das spezialisierte Benutzer-Anwendungspaket, das in den vorangegangenen vier Ebenen definiert wurde, abzuarbeiten.
Ein AG-RU macht Verbindungen zu einer oder mehreren LCG-RUs, welche jeweils Verbindungen machen zu einer oder mehreren PFG-RUs, welche jeweils Verbindungen machen zu einer oder mehreren SFG-RUs, welche jeweils Verbindungen machen zu einer oder mehreren OCG-RUs. Auf diese Weise wird eine hierarchische Struktur mit fünf Ebenen definiert.
Jede RU wird aus einem Vorsatz bzw. Kopf-Teil und einem Haupt- Teil zusammengesetzt. Der Vorsatz einer jeden RU, der nachfolgend in der Beschreibung stets als Kopfteil bezeichnet wird, enthält ungeachtet der Ebene selbst-identifizierende und Wartungs-Information, und kann weiterhin eine Liste mit Hardware- und Software-Abhängigkeiten enthalten, die spezifisch für diese RU sind. Der Hauptteil der AG, LCG, PEG und SEG RUs enthält zusätzliche selbst-identifizierende und Wartungs- Informationen, zusätzlich zu einer Liste von RUs in der nächsten Ebene, die einen Teil der hierarchischen Kette bildet.
Die selbst-identifizierende, Wartungs- und Abhängigkeits- Informationen, die in den RUs enthalten sind, sind auch als vitale Produktdaten (Vital Product Data, VPD) bekannt. Der Hauptteil jeder RU in der OCG-Ebene enthält den operationalen Code, der verwendet wird, um das Programm abzuarbeiten.
Die hierarchische Struktur der Softwareanwendung, die Austauschbarkeit der RUs und die selbst-identifizierende, Wartungs- und Abhängigkeits-Information, die in den RUs enthalten ist, ermöglicht eine sehr hochentwickelte Software. Liese derart strukturierte Software kann verwendet werden, um eine Vielzahl von Problemen der heutigen Datenverarbeitung, von denen viele oben diskutiert wurden, zu lösen.
Programmentwickler verwenden das Programm-Packungs-Hilfsmittel der Erfindung, um Programme zu erstellen, die in vier Ebenen gepackt sind: LCG, PFG, SEG und OCG. Ein Anwendungsentwickler verwendet das Anwendungs-Packungs-Hilfsmittel der Erfindung, um verschiedene dieser Programme miteinander zu kombinieren, um ein Anwendungspaket zu erstellen.
Dies wird gemacht, durch Hinzufügen der AG-Ebene oberhalb der vier Ebenen der ausgewählten Programme. Weiterhin kann der Anwendungsentwickler bestimmte primäre und sekundäre Funktionen der ausgewählten Programme selektieren, und dabei andere primäre und sekundäre Funktionen der ausgewählten Programme unberücksichtigt lassen. Die Packungs-Struktur und das Packungs- Hilfsmittel der vorliegenden Erfindung gibt dem Anwendungsentwickler die Fähigkeit und die Flexibilität, ein maßgeschneidertes Anwendungspaket zu erstellen, das die Anforderungen eines bestimmten Benutzers erfüllt.
Figur 1 zeigt das Umfeld der Erfindung.
Figur 2 zeigt Programme, die gemäß der Erfindung gepackt sind, zusammengefaßt in einer Software-Bibliothek.
Figur 3 zeigt ein Anwendungspaket, das maßgeschneidert ist, um die Anforderungen eines bestimmten Benutzers zu erfüllen.
Figur 4 zeigt eine Darstellung der Ebenen eines Software- Anwendungspaketes, angeordnet in einer hierarchischen Form.
Figur 5 zeigt die hierarchischen Ebenen der Figur 1 mit mehr Details, um individuelle austauschbare Einheiten (RU) zu zeigen.
Figur 6A zeigt detailliert die auswechselbare Einheit, die verwendet wird, um die AG-, LCG-, PFG- und SFG-Ebenen zusammenzusetzen.
Figur 6B zeigt detailliert die auswechselbare Einheit, die verwendet wird, um die OCG-Ebene zusammenzusetzen.
Figur 7 zeigt detailliert den festen Kopfteil, der allen RUs gemeinsam ist.
Figur 8 zeigt detailliert den variablen Kopfteil, der allen RUs gemeinsam ist.
Figur 9 zeigt detailliert den festen AG-Informationsblock einer AG-RU.
Figur 10 zeigt detailliert den variablen AG-Informationsblock einer AG-RU.
Figur 11 zeigt detailliert den festen LCG-Informationsblock einer LCG-RU.
Figur 12 zeigt detailliert den variablen LCG-Informationsblock einer LCG-RU.
Figur 13 zeigt detailliert den festen PFG-Informationsblock einer PFG-RU.
Figur 14 zeigt detailliert den variablen PFG-Informationsblock einer PFG-RU.
Figur 15 zeigt detailliert den festen SFG-Informationsblock einer SFG-RU.
Figur 16 zeigt detailliert den variablen SFG-Informationsblock einer SFG-RU.
Figur 17 zeigt ein Menü des Programm-Packungs-Hilfsmittels, das einem Programmentwickler verfügbar ist.
Figuren 18 bis 30 zeigen detailliert das Programm-Paket Definitions-Hilfsmittel und das Anwendungs-Paket-Definitions-Hilfsmittel.
Figur 31 zeigt ein Beispiel von angezeigten Programmpaketen unter Verwendung des Programmpaket-Anzeige- Hilfsmittels.
Figur 32 zeigt ein Menü des Anwendungs-Packungs-Hilfsmittels, das einem Anwendungsentwickler verfügbar ist.
Figur 33 zeigt ein Beispiel, wie ein Anwendungs-Entwickler das Anwendungsgruppen-Auswahl-Funktions-Hilfsmittel benutzen könnte.
Figur 34 zeigt ein Beispiel eines angezeigten Anwendungs- Paketes unter Verwendung des Anwendungspaket-Anzeige- Hilfsmittels.
Die Figur 1 zeigt die Umgebung der Erfindung. Jeder der Programmentwickler 21 bis 24 entwickelt Programme, die gemäß der Packungsstruktur der Erfindung gepackt werden, wie dies nachfolgend detailliert erläutert wird. Die Programmentwickler 21 bis 24 arbeiten in der Regel unabhängig voneinander und konkurrieren häufig miteinander. Obgleich in der Figur 1 nur vier Programmentwickler dargestellt sind, entwickeln weltweit mehrere tausend Personen Programme und sind Programmentwickler, wenn sie der Packungsstruktur der vorliegenden Erfindung folgen
Die Programme, die durch die Programmentwickler 21 bis 24 entwickelt wurden, werden in eine Bibliothek 30 eingebracht. Die Bibliothek 30 stellt eine Sammlung von allen Programmen, die durch die Programmentwickler entwickelt wurden, dar. Beispielsweise kann die Bibliothek 30 Betriebssystem-Programme Textverarbeitungs-Programme, Tabellenkalkulations-Programme, Spiel-Programme, Bildungs-Programme, Kommunikations-Programme und Veröffentlichungs-Programme enthalten, um nur einige zu nennen. Jedes Programm führt primäre und sekundäre Funktionen aus, wie dies nachfolgend erläutert wird. Die Programme 31 bis 35 sind in der Bibliothek 30 dargestellt und sind in der Figur 2 weiter detailliert dargestellt.
Der Anwendungsentwickler 26 nimmt die Programme aus der Bibliothek 30 und repaketiert sie, um ein Anwendungspaket zu erstellen, das maßgeschneidert ist, um spezielle Benutzeranforderungen zu erfüllen. Programme, die der Benutzer benötigt, werden in einem Anwendungspaket kombiniert, und dieses Anwendungspaket wird dem Benutzer übergeben. Dabei werden nur die allgemeinen und die spezifischen Funktionen der Programme, die der Benutzer benötigt, ausgewählt, um in das Anwendungspaket eingebunden zu werden, das der Benutzer erhält.
In der Figur 1 ist dem Anwendungsentwickler 26 die Aufgabe zugewiesen, ein Anwendungspaket für die Benutzer 41 bis 44, die in einem Büro 50 arbeiten, zu erstellen. Das Büro 50 hat vier Computer 51 bis 54, die von den Benutzern benutzt werden. Die Computer 51 bis 54 enthalten jeweils Speicherbereiche 56 bis 59. Die Speicherbereiche 56 bis 59 enthalten jeweils die Anwendungspakete 61 bis 64. Obgleich in jedem Speicherbereich nur ein Anwendungspaket dargestellt ist, können mehrere gespeichert werden. Die Anwendungspakete 61 bis 64 wurden vom Anwendungsentwickler 26 aus den Programmen erstellt, die in der Bibliothek 30 enthalten sind und die von den Programmentwicklern 21 bis 24 geschrieben worden sind. Die Anwendungspakete 61 bis 64 sind jeweils maßgeschneidert, um die Bedürfnisse der Benutzer 41 bis 44 zu erfüllen.
Die Programmentwickler 21 bis 24 verwenden das Packungs- Hilfsmittel 80, um ihre Programme gemäß der Packungsstruktur der Erfindung zu verpacken. Ebenso verwendet der Anwendungsentwickler 26 das Packungs-Hilfsmittel 90, um die Programme, die durch die Programmentwickler 21 bis 24 erstellt wurden, in einem Anwendungspaket wiederzuverpacken, welches maßgeschneidert ist, die Bedürfnisse eines bestimmten Benutzers zu erfüllen. Die Packungsmittel 80 und 90 sind ganz ähnlich und werden detailliert in den Figuren 17 bis 34 beschrieben.
Die Figur 2 zeigt detaillierter die Programme 31 bis 35, die in der Bibliothek 30 enthalten sind. Es ist zu bemerken, daß die Programme 31 bis 35 bildhaft wie eine Pyramide ohne Spitze dargestellt sind. Dies symbolisiert, daß diese Programme gemäß einer Packungsstruktur geschrieben wurden, aber noch nicht Teil eines Anwendungspaketes sind.
Das Programm 31 ist ein Textverarbeitungsprogramm. Dieses spezielle Textverarbeitungsprogramm weist zwei primäre Funktionen auf: Dokument-Erstellung und Rechtschreib-Prüfung. Die primäre Funktion der Dokument-Erstellung hat drei sekundäre Funktionen: Inhaltsverzeichnis-Fähigkeit, Index-Generierungs- Fähigkeit und freiverfügbare Druck-Fähigkeit. Die primäre Funktion der Rechtschreib-Prüfung hat drei sekundäre Funktionen: Allgemeine Wörter, Rechtliche Wörter und Medizinische Wörter.
Jede sekundäre Funktion hat entsprechenden operationalen Code auf der Ebene 5000, der verwendet wird, um diese spezielle Funktion auszuführen.
Die Programme 32 bis 35 sind ein Kommunikations-Programm, ein Berechnungs-Programm, ein Betriebssystem und ein Schach- Programm. Es ist zu beachten, daß jedes dieser Programme, mit Ausnahme des Schach-Programmes 35, mehrere primäre und sekundäre Funktionen aufweist. Das Schach-Programm 35 ist so einfach, daß es nur eine primäre und eine sekundäre Funktion aufweist.
Die Programme 31 bis 35 stehen lediglich beispielhaft für Programme, die durch Programmentwickler unter Verwendung des Packungs-Hilfsmittels (80) erstellt werden könnten. Den Programmentwicklern ist eine hohe Flexibilität gegeben, auszuwählen, was auch immer sie als primäre und sekundäre Funktion wünschen. Um so mehr primäre und sekundäre Funktionen sie wählen, um so vielseitiger anwendbar wird das Programm sein, und um so wahrscheinlicher wird ein Anwendungsentwickler in der Lage sein, das Programm in ein Anwendungspaket einzubinden, das maßgeschneidert die Bedürfnisse eines bestimmten Benutzers erfüllt.
Bezugnehmend auf die Figuren 1 und 2 soll angenommen werden, daß das Büro 50 ein kleines Rechtsanwaltsbüro ist. Der Anwendunqsentwickler 26 kam nach Rücksprache mit dem Benutzer 41 zu dem Schluß, daß der Benutzer 41 das Textverarbeitungs-Programm 31, das Berechnungs-Programm 33 und das Betriebssystem 34 benötigt, nicht jedoch das Kommunikations-Programm 32 oder das Schach- Programm 35. Der Anwendungsentwickler kam weiterhin zu dem Schluß, daß der Benutzer 41 die primären Funktionen der Dokument-Erstellung und Rechtschreib-Prüfung des Textverarbeitungs-Programmes 31 benötigt und die sekundären Funktionen der Inhaltsverzeichnis-Erstellung, allgemeine Wörter und rechtliche Wörter benötigt, aber keine der anderen sekundären Funktionen benötigt. Ebenso wurden einige der primären und sekundären Funktionen des Berechnungs-Programmes 33 und des Betriebssystems 34 ausgewählt, und einige wurden weggelassen, basierend auf den Bedürfnissen des Benutzers 41. Der Anwendungsentwickler 26 wiederverpackt die Programme 31, 33 und 34 in ein Anwendungspaket 61 und übergibt dieses an den Benutzer 41, der es im Speicher 56 seines Computers 51 speichert. Die Anwendungspakete 62 bis 64 sind in einer ähnlichen Weise erstellt worden, basierend auf den Bedürfnissen der Benutzer 42 bis 44. Der Anwendungsentwickler 26 verwendet das Packungs-Hilfsmittel 90, um die Anwendungspakete 61 bis 64 zu erstellen, wie dies nachfolgend erörtert wird.
Die Figur 3 zeigt das Anwendungspaket 61, das der Anwendungsentwickler 26 für den Benutzer 41 geschaffen hat. Es ist zu beachten, daß das Anwendungspaket 61 bildhaft als eine Pyramide dargestellt ist, nun komplett mit einer Spitze. Das Anwendungspaket 61 beinhaltet nur die Programme, primären Funktionen und sekundären Funktionen, die der Benutzer 41 benötigt. Wenn die Bedürfnisse des Benutzers 41 sich ändern kann ein neues Anwendungspaket für ihn geschaffen werden.
Es ist zu beachten, daß das Anwendungspaket 61 aus fünf Ebenen besteht: 1000, 2000, 3000, 4000 und 5000. Die Fünf-Ebenen- Packungsstruktur des bevorzugten Ausführungsbeispieles ist detaillierter in den Figuren 4 bis 17 dargestellt.
Die Figur 4 zeigt die Software-Verwaltungsstruktur des bevorzugten Ausführungsbeispieles Es ist zu beachten, daß fünf Ebenen dargestellt sind und daß die Struktur in Form einer Pyramide dargestellt ist, um deren hierarchisches Wesen zu betonen. Die alleroberste Ebene, die Ebene der Anwendungsgruppe (AG) 1000, definiert eine Gruppe von Computerprogrammen, die kombiniert wurdenf um eine High-Level Benutzeranwendung zu bilden. Beispielsweise definiert das Anwendungspaket 61 der Figur 3 in seiner AG-Ebene eine Gruppe von Programmen für ein Rechtsanwaltsbüro. Die zweite Ebene, die Ebene der operationalen Codegruppen (LCG) 2000, definiert individuelle Programme, von denen jedes eine allgemeine Aufgabe ausführt. Beispielsweise hat das Anwendungspaket 61 der Figur 3 in seiner Ebene der operationalen Codegruppen (LCG) 2000 ein Textverarbeitungsprogramm, ein Berechnungsprogramm und ein Betriebssystem. Die dritte Ebene, die Ebene der primären funktionellen Gruppe (PFG) 3000, verfeinert die in der LCG-Ebene definierten gemeinsamen Programme zu einem spezifischeren Satz von primären Funktionen. Beispielsweise enthält die PFG-Ebene für das Textverarbeitungsprogramm der LCG-Ebene des Anwendungspaketes 61 der Figur 3 die primären Funktionen der Dokument-Erstellung und Rechtschreib- Prüfung. Die gleiche Art von Verfeinerung kann für die anderen Programme der LCG-Ebene vorkommen.
Die vierte Ebene, die Ebene der sekundären funktionellen Gruppe (SFG) 4000, verfeinert die primären Funktionen, die in der PFG-Ebene definiert wurden, zu einem noch weiter spezialisierten Satz von sekundären Funktionen, die noch maßgeschneiderter an die Bedürfnisse eines bestimmten Benutzers angepaßt sind. Beispielsweise enthält die SFG-Ebene für die primäre Funktion der Rechtschreib-Prüfung der PFG-Ebene des Anwendungspaketes 61 der Figur 3 die sekundären Funktionen von allgemeinen Wörtern und juristischen Wörtern. Die gleiche Art von Verfeinerung kann für die anderen primären Funktionen der PFG-Ebene vorkommen.
Die letzte Ebene, die Ebene der operationalen Codegruppen (OCG) 5000, enthält den operationalen Code, der erforderlich ist, um die spezialisierten Benutzeranwendungen ablaufen zu lassen, die durch die vorangegangenen vier Ebenen definiert wurden.
Die Figur 5 veranschaulicht detaillierter die hierarchische Struktur des bevorzugten Ausführungsbeispieles der Figur 4. Es ist zu beachten, daß die AG-Ebene 1000 aus der austauschbaren Einheit (RU) 1100 zusammensetzt ist. Der Inhalt der RU 1100 wird in den Figuren 6A und 7 bis 10 detaillierter beschrieben. Die RU 1100 ist mit mindestens einer RU auf der LCG-Ebene 2000 verbunden. Die Figur 5 zeigt die RU 1100 mit der RU 2100 auf der LCG-Ebene 2000 verbunden. Die Inhalte der RU 2100 werden in den Figuren 6A, 7, 8, 11 und 12 detaillierter beschrieben.
Die RU 2100 ist mit mindestens einer RU auf der PFG-Ebene 3000 verbunden. Die Figur 5 zeigt die RU 2100 mit der RU 3100 auf der PFG-Ebene 3000 verbunden. Die Inhalte der RU 3100 werden in den Figuren 6A, 7, 8, 13 und 14 detaillierter beschrieben.
Die RU 3100 ist mit mindestens einer RU auf der SFG-Ebene 4000 verbunden. Die Figur 5 zeigt die RU 3100 mit der RU 4100 verbunden. Die Inhalte der RU 4100 werden in den Figuren 6A, 7, 8, 15 und 16 detaillierter beschrieben. Die RU 4100 ist mit mindestens einer RU auf der OCG-Ebene 5000 verbunden. Die Figur 5 zeigt die RU 4100 mit der RU 5600 verbunden.
Die Inhalte der RU 5600 werden in den Figuren 68, 7, und 8 detaillierter beschrieben.
Die Figur 6A zeigt detaillierter die austauschbare Einheit, die verwendet wird, um die AG-, LCG-, PFG- und SFG-Ebenen zusammenzusetzen. Die austauschbare Einheit 100 ist aus einem Kopfteil 110 und einem Hauptteil 120 zusammengesetzt.
Der Kopfteil 110 ist aus einem unveränderlichen Kopfteil- Block 200 und einem veränderlichen Kopfteil-Block 300 zusammengesetzt. Der Hauptteil 120 ist aus einem Block 400 mit unveränderlicher Gruppeninformation und einem Block 500 mit veränderlicher Gruppeninformation zusammengesetzt. Der unveränderliche Kopfteil-Block 200 ist aus einem Teil mit Längeninformation 220, einem Teil mit RU-ID-Information 230 und eineni Teil mit Offsetinformation 260 zusammengesetzt. Der Teil mit Längeninformation 220 hält sich auf dem laufenden über die Gesamtlänge der RU 100 und die Länge des Haupteils 120 der RU 100. Der Teil mit RU-ID-Information 230 enthält selbstidentifizierende Information, die diese bestimmte auswechselbare Einheit eindeutig aus allen anderen auswechselbaren Einheiten der Figur 5 identifiziert. Weiterhin enthält der Teil mit RD-ID- Information 230 auch Wartungsinformation, die verwendet werden kann, um den Wartungs-Level dieser speziellen RD zu bestimmen.
Der Teil mit Offsetinformation 260 enthält Offsets zu Daten in dem veränderlichen Kopfteil 300 und zu Daten in dem Teil mit unveränderlicher Gruppeninformation 400. Der Teil mit Offsetinformation 260 hat insbesondere Offsets in den Teil mit systemspezifischen Daten 320, den Teil mit den Hardware- Abhängigkeiten 330 und den Teil mit Software-Abhängigkeiten 360 im veränderlichen Kopfteil 300. Die Offsetinformation 260 hat weiterhin einen Offset in den Block mit unveränderlicher Gruppeninformation 400. Die konkreten Felder, die im unveränderlichen Kopfteil 200 enthalten sind, werden detaillierter in der Figur 7 beschrieben und der veränderliche Kopfteil 300 wird detaillierter in der Figur 8 beschrieben.
Nochmals bezugnehmend auf die Figur 6A: Der Hauptteil 120 ist zusammengesetzt aus dem Block mit unveränderlicher Gruppeninformation 400 und dem Block aus veränderlicher Gruppeninformation 500. Der Block mit unveränderlicher Gruppeninformation 400 enthält einen Teil 420 mit Information über die Länge des Hauptteils, einen Teil 430 mit Gruppen-ID-Information und einen Teil 460 mit Gruppen-Offset-Information. Der Teil 420 mit Information über die Länge des Hauptteils hält sich auf dem laufenden über die Gesamtlänge des Hauptteils 120. Der Teil mit Gruppen-ID-Information 430 enthält zusätzliche selbst-identifizierende Information und Wartungsinformation. Der Teil (460) mit Gruppen-Offset-Information hat Offsets in den Block 500 mit veränderlicher Gruppeninformation. Der Teil (460) mit Gruppen- Offset-Information hat insbesondere Offsets zu Daten in den Teil 520 mit gruppenspezifischen Daten und zu der Liste des Teiles 540 mit den Zugängen in die nächste Ebene.
Die konkreten Felder, die in dem Block mit unveränderlicher Gruppeninformation 400 und in dem Block mit veränderlicher Gruppeninformation 500 enthalten sind, sind abhängig davon, ob die RU 100 sich in der AG-Ebene 1000, der LCG-Ebene 2000, der PFG-Ebene 3000 oder der SFG-Ebene 4000 befindet. Wenn die austauschbare Einheit 100 sich in der AG-Ebene 1000 befindet, ist der unveränderliche AG-Informationsblock 1400 detaillierter in der Figur 9 dargestellt, und der veränderliche AG-Informationsblock 1500 ist detaillierter in der Figur 10 dargestellt. Wenn die austauschbare Einheit 100 sich in der LCG-Ebene 2000 befindet, ist der unveränderliche LCG-Informationsblock 2400 detaillierter in der Figur 11 dargestellt, und der veränderliche LCG-Informationsblock 2500 ist detaillierter in der Figur 12 dargestellt. Ebenso, wenn die austauschbare Einheit 100 sich in der PFG-Ebene 3000 befindet, ist der unveränderliche PFG- Informationsblock 3400 detaillierter in der Figur 13 dargestellt, und der veränderliche PFG-Informationsblock 3500 ist detaillierter in der Figur 14 dargestellt. Schließlich, wenn die austauschbare Einheit 100 sich in der SFG-Ebene 4000 befindet, ist der unveränderliche SFG-Informationsblock 4400 detaillierter in der Figur 15 dargestellt, und der veränderliche SFG- Informationsblock 4500 ist detaillierter in der Figur 16 dargestellt.
Die austauschbare Einheit 600 aus der Figur 68 soll nun beschrieben werden. Die austauschbare Einheit 600 befindet sich nur in der OCG-Ebene 5000. Es ist zu beachten, daß die austauschbare Einheit 600 einen Kopfteil 110 besitzt, der mit dem Kopfteil 110 der austauschbaren Einheit 100 identisch ist, dargestellt in der Figur 6A. Die austauschbare Einheit 600 hat weiterhin einen Hauptteil 620, der sich von dem Hauptteil 120 der austauschbaren Einheit 100 unterscheidet. Insbesondere enthält der Hauptteil 620 operationalen Code 630. Der operationale Code 630 ist nicht-architektiert und stellt die Daten oder den ausführbaren Code des Programmes dar. Der operationale Code 630 enthält fakultativ zusätzliche, unbedingt erforderliche Daten (Selbstidentifikation-, Wartung- und Abhängigkeits- Information).
Wie voranstehend in Zusammenhang mit der Figur 6A diskutiert, enthält der Kopfteil 110 der austauschbaren Einheit 100 die gleichen Felder, unberücksichtigt der Ebene, in der sich die austauschbare Einheit 100 befindet. Die Figur 7 zeigt detaillierter den unveränderlichen Kopfblock 200. Der Teil der Längeninformation 220 besteht aus zwei Feldern. Das Feld 221 identifiziert die Gesamtlänge dieser bestimmten RU. Das Feld 222 identifiziert die Gesamtlänge des Hauptteils dieser RU. Diese Information wird verwendet, um die Verkettung von RUs zu gestatten. Der Teil mit ID-Information 230 enthält mehrere Felder mit selbstidentifizierender Information und mehrere Felder mit Wartungsinformation. Das Feld 231 mit dem RU Namen wird vom System verwendet, um eine RU zu verwalten. Der Name, der einer bestimmten RU gegeben wird, sollte einmalig sein, so daß die RU von allen anderen RUs im System unterschieden werden kann. Die Spalte 17400 der Figur 31 zeigt Beispiele von RU- Namen. Das RU-Referenzfeld 232 sieht die zusätzliche visuelle Identifikation einer RU vor. Das RU-Lade-Identifikationsfeld 233 identifiziert die RU als eine spezielle Ladung, die von einem Teil der Einrichtung benötigt wird, der eine entsprechende anfängliche Programm-Lade-ID besitzt. Dies stellt einen Mechanismus für das System dar, die BUS zu bestimmen, die während des anfänglichen Programm-Ladeprozesses geladen werden müssen. Es ist zu beachten, daß das RU-Lade-ID-Feld 233 optiona] ist. Das LCG- und AG-ID-Feld 234, das PFG-ID-Feld 236 und das SFG-ID-Feld 237 enthalten die IDs anderer RUs in der hierarchischen Kette.
Nun werden die Wartungsinformations-Felder in dem ID-Informationsteil 230 des unveränderlichen Kopfteils 200 beschrieben. Das RU-Instruktionssatz-Feld 241 identifiziert die Instruktionssätze der Maschine, für welche die Daten in dem RU-Hauptteil kompatibel sind. Dieses Feld ist optional. Das RU-Kontroll- Informationsfeld 242 enthält mehrere Anzeiger (flags), die verwendet werden, um die RU zu verwalten. Ein Anzeiger ist ein RU-Modifikations-Anzeiger, der gesetzt wird, wenn die RU modifiziert wurde. Ein zweiter Anzeiger ist ein RU-Abhängigkeits-Anzeiger, der gesetzt wird, wenn diese bestimmte RU irgendwelche Hardware- oder Software-Abhängigkeiten aufweist. Ein dritter Anzeiger ist ein RU-Typen-Anzeiger, der angibt, ob diese RU eine AG-, PFG-, SFG- oder OCG-RU ist.
Das RU-Entwicklungs-Informations-Feld 243 enthält Informationen betreffend der ursprünglichen Entwicklung dieser RU, wie beispielsweise die genaue Entwicklungsstätte, die diese RU entwickelt hat. Das RU-Erschaffungsdatum-Feld 244 und RU- Erschaffungszeitpunkt-Feld 246 enthalten Daten- und Zeitmarken, wann diese RU erschaffen wurde. Das RU-Installationsdaten- Feld 247 und das RU-Installationszeiten-Feld 248 enthalten Daten- und Zeitmarken, wann diese RU auf dem System installiert wurde. Das RU-Versionslevel-Feld 249 und das RU-Release- Nodifikationslevel-Feld 250 identifizieren den Wartungslevel dieser bestimmten RU. Das RU-vorübergehende-Umgehung (temporary fix)-ID-Feld 252 und das RU-Korrektur-ID-Feld 253 sind optional und verleihen jeder vorübergehenden Umgehung oder Korrektur, die an dieser RU vorgenommen wurde, einen Namen. Das RU- "Gemeinsamer-Name"-Feld 254 ist ein binärer Alias für das RU- Namensfeld 231 und kann optional durch die System-Software verwendet werden. Die Felder 257 und 258 identifizieren Informationen über die Compiler der RUs.
Nun werden die Felder besprochen, aus denen der Teil mit Offset Information 260 des unveränderlichen Kopfblocks 200 zusammengesetzt ist. Der Offset zu dem Hauptteil-Feld 261 der RU zeigt an den Anfang des Hauptteiles dieser RU. Der Offset zu dem Feld 262 mit den systemspezifischen Daten der RU zeigt an den Anfang aller systemspezifischen Daten des Systems, die in dem veränderlichen Kopfteil-Block der RU enthalten sind. Der Offset zu dem Feld 263 mit der Liste der Hardwareabhängigkeiten der RU zeigt an den Anfang einer Liste mit Hardwareabhängigkeiten, die in dem veränderlichen Kopfteil-Block der RU enthalten ist. Der Offset zu dem Feld 264 mit der Liste der Softwareabhängigkeiten der RU zeigt an den Anfang einer Liste mit Softwareabhängigkeiten, die in dem veränderlichen Kopfteil-Block der RD enthalten ist. Das Feld 265 zeigt an den Anfang von RU- spezifischer Information. Das Feld 267 zeigt zu eingebetteter VPD in einem OCG-Hauptteil, sofern vorhanden.
Der Name des Systembereiches, der das RU-Feld 266 enthält, enthält den Namen des Standortes im Systemspeicher, wo die RU sich befindet. Beispiele von Standortnamen sind in der Spalte 17600 der Figur 31 dargestellt. Die Felder 270 und 271 enthalten die Daten und Zeitpunkte, mit und zu denen die RU zuletzt modifiziert wurden. Das Feld 273 zeigt auf Kopfteil- Erweiterungsdaten, die in dem veränderlichen Kopfteil enthalten sind.
Die Figur 8 zeigt detaillierter die Felder des veränderlichen Kopfteil-Blockes 300. Der Teil 320 mit den systemspezifischen Daten besteht aus dem Feld 321 mit der Länge der systemspezifischen Daten und dem Feld 322 mit den systemspezifischen Daten.
Nun werden die Felder beschrieben, die in dem Teil 330 mit der Liste der Hardware-Abhängigkeiten des veränderlichen Kopfteil- Blockes enthalten sind. Das Feld 331 enthält die Anzahl der Eintragungen in die Hardware-Abhängigkeitsliste. Die Felder 332 bis 337 und 239 bilden eine Eintragung in die Hardware- Abhängigkeitsliste und sind für mehrfache Eintragungen in der Liste wiederholt. Das Feld 332 enthält eine Hardware- Korrelations-ID der RU. Mehreren verschiedenen Teilen der Hardware kann die gleiche Korrelations-ID gegeben werden, wenn diese Teile stets gemeinsam verwendet werden sollten. Die Felder 333, 335, 336 und 337 enthalten den Typ, die Modell- Nummer, die Level-ID-Nummer und Teile-Nummer des bestimmten Teiles der Hardware, von der diese RU abhängig ist.
Nun werden die Felder beschrieben, die in dem Teil 360 mit der Liste der Software-Abhängigkeiten des veränderlichen Kopfteilblockes enthalten sind. Das Feld 361 enthält die Größe der Software-Abhängigkeitsliste und das Feld 362 enthält die Anzahl der Eintragungen in die Software-Abhängigkeitsliste. Die Felder 363 bis 376 stellen eine Eintragung in die Software- Abhängigkeitsliste dar. Diese Felder werden für jede Eintragung in die Liste wiederholt. Das Feld 363 enthält die Größe dieser bestimmten Eintragung in der Liste der Software-Abhängigkeiten. Das Feld 364 enthält die Software-Korrelations-ID für diese Eintragung in die Software-Abhängigkeitsliste. Mehrere verschiedene Teile von Software können die gleiche Korrelations- ID erhalten, wenn diese Teile immer zusammen verwendet werden sollten.
Es wird angenommen, daß das Software-Programm, das in der Liste der Software-Abhängigkeiten enthalten ist, so strukturiert ist, wie in der vorliegenden Erfindung offenbart. Aus diesem Grund muß die hierarchische Kette von RUs dargestellt sein, aus denen das Software-Programm, von dem die RU abhängig ist, zusammengesetzt ist. Das LCG-ID-Feld 367, das LCG-PFG-ID-Feld 370 und das PFG-SFG-ID-Feld 373 stellen Informationen bereit, die diese hierarchische Kette definieren. Die Felder 368 und 369 zeigen den Versions-Level und Release-/Modifikations-Level der LCG des Software-Programmes, von der sie abhängig ist. Ebenso sind der Versions-Level und der Release-/Modifikations-Level der LCG-PFG Kette in den Feldern 371 und 372 dargestellt und der Versions- Level und der Release-/Modifikations-Level der PFG-SFG Kette ist in den Feldern 374 und 375 dargestellt. Die Felder 381 bis 384 bilden die Kopfteil-Erweiterung. Das Feld 382 enthält die Teil- Nummer der RU. Das Feld 383 enthält eine kurze Beschreibung der RU. Beispiele von kurzen Beschreibungen von RUs sind in der Spalte 17050 der Figur 31 dargestellt.
Nun werden die Felder des Hauptteils 120 der austauschbaren Einheit 100, wie in der Figur 6A dargestellt, detailliert beschrieben. Der Hauptteil 120 enthält den Block 400 mit unveränderlicher Gruppen-Information und den Block 500 mit veränderlicher Gruppen-Information, wie vorstehend beschrieben. Die Blöcke 400 und 500 enthalten verschiedene Felder, abhängig davon, auf welcher Ebene der hierarchischen Kette die RU sich befindet. Der Block 1400 mit unveränderlicher AG-Information findet sich in der austauschbaren Einheit 1100 auf dem AG- Ebene 1000 wieder und wird detaillierter in der Figur 9 beschrieben.
Der Teil 1420 mit der Längen-Information enthält ein Feld, das über die Gesamtlänge des AG-Hauptteils auf dem laufenden ist. Nun werden die Felder beschrieben, aus denen der Teil 1430 mit der Gruppen-ID-Information des Blockes 1400 mit unveränderlicher AG-Information der RU 1100 aufgebaut ist. Die Felder 1431 bis 1439 identifizieren den Namen des Lieferanten, der diese bestimmte AG-RU erstellt hat. Der Lieferant ist üblicherweise der Anwendungsentwickler, der das Anwendungspaket zusammengestellt hat. Das Feld 1441 ist eine Zeichenkonstante, die eine visuelle Identifikation, das diese RU eine AG-Typ-RU ist, bereitstellt. Die Felder 1443 bis 1446 beschreiben die Identifikations-Teil-Nummer, den Versions-Level und den Release/Modifikations-Level für diese AG-RU. Die Felder 1447 und 1448 enthalten Informationen über alle zwischenzeitlichen oder vorläufigen (zwischen den Leveln) Veränderungen, die an dieser AG-RU vorgenommen wurden. Das Feld 1449 enthält urheberrechtliche (Copyright) Informationen des Schöpfers und Eigentümers der RU.
Nun werden die Felder beschrieben, die den Teil 1460 der Offset- Information des Blockes 1400 der unveränderlichen AG-Information der RU 1100 bilden. Das Feld 1463 zeigt auf eine Liste von LCG- RUs, die in der hierarchischen Kette mit dieser AG-RU verbunden sind. Diese Liste ist in dem Block 1500 der veränderlichen AG- Information enthalten, der detaillierter in der Figur 10 dargestellt ist. Das Feld 1464 zeigt auf den Anfang der AG- spezifischen Daten, die in dem Block 1500 der veränderlichen AG- Information enthalten sind, der detaillierter in der Figur 10 dargestellt ist.
Nun werden die Felder beschrieben, die den Block 1500 der veränderlichen AG-RU-Information der Figur 10 bilden. Der Teil 1520 der AG-spezifischen Daten besteht aus dem Feld 1521, welches die Länge der AG-spezifischen Daten beinhaltet, und aus dem Feld 1522, welches die AG-spezifischen Daten beinhaltet.
Nun werden die Felder beschrieben, welche die LCG-Liste 1540 bilden. Das Feld 1541 definiert die Größe der LCG-Liste und das Feld 1543 definiert die Anzahl der Eintragungen in die LCG- Liste. Die Felder 1544 bis 1556 bilden einen Eintrag in die LCG- Liste und werden für jeden Eintrag in die LCG-Liste wiederholt. Das Feld 1545 ist das Auswahl/Weglassen (select/omit) Flag, welches, wenn gesetzt, diese LCG als ausgewählt für die AG identifiziert. Das Feld 1546 zeigt an, ob diese LCG für die Verwendung durch die AG verfügbar ist. Das Feld 1547 zeigt an, ob die verfügbare LCG auf dem System installiert ist. Das Feld 1548 zeigt an, ob die installierte LCG befähigt worden ist, auf diesem System abzulaufen. Die Felder 1546 bis 1548 ermöglichen den LCGs als Teil eines Anwendungspaketes, das an einen Benutzer gesandt wird, eingebunden zu werden, aber nicht zur Benutzung dieses Benutzers befähigt zu sein, bis der Benutzer sie zum Zwecke der Erweiterung oder des Upgrades benötigt. Beispielsweise kann eine kostenpflichtige Berechnungs LCG dem Benutzer übergeben werden, die aber nicht zur Ausführung befähigt (enabled) ist, solange, bis der Benutzer seine Anwendung verändert, und diese zusätzliche Funktion benötigt. Diese Felder können ebenfalls als Teil eines Kopierschutz- Systems für die Software verwendet werden.
Das Feld 1550 enthält den Standort im Systemspeicher, an dem diese besondere LCG abgelegt sind. Beispiele für System- Standort-Namen sind in der Spalte 17600 der Figur 31 dargestellt. Das Feld 1552 enthält den Namen der LCG, die von dem System verwendet wird, um diese besondere LCG eindeutig zu identifizieren. Beispiele von RU-Namen sind in der Spalte 17400 der Figur 31 dargestellt. Das Feld 1554 enthält eine Identifikation der LCG. Beispiele für LCG-IDs sind in der Spalte 17100 der Figur 31 dargestellt. Die Felder 1555 und 1556 enthalten den Versions-Level und den Release-/Modifikations-Level des LCG- Zugangs.
Die Figur 11 beschreibt die Felder, die den Block 2400 der unveränderlichen LCG-Information der RU 2100 bilden, lokalisiert in der LCG-Ebene 2000. Es ist zu beachten, daß viele dieser Felder ähnlich sind zu den Feldern in dem Block 1400 der unveränderlichen AG-Information, die in der Figur 9 dargestellt sind. Bezüglich der Beschreibung dieser Felder wird auf die Beschreibung der Figur 9 hingewiesen. Die Lieferanteninformation, die in den Feldern 2431 bis 2439 enthalten sind, weisen üblicherweise auf den Programmentwickler hin, der das Programmpaket geschaffen hat.
Das Feld 2463 zeigt auf die Liste von PFG-RUs, die mit dieser LCG-RU verbunden sind. Diese Liste ist in dem Block 2500 der veränderlichen LCG-Informationen enthalten, wie in der Figur 12 dargestellt. Das Feld 2464 zeigt auf LCG-spezifische Informationen, die ebenfalls in dem Block 2500 der veränderlichen LCG- Informationen der Figur 12 enthalten sind. Das Feld 2465 zeigt auf AG-Daten, die ebenfalls in dem Block 2500 der veränderlichen LCG-Informationen der Figur 12 enthalten sind. Das Feld 2467 zeigt auf die Ausgangs-Programme, die in dem Block 2500 lokalisiert sind.
Der Block 2500 der RU 2100 mit veränderlicher LCG-Information ist in der Figur 12 dargestellt. Es ist zu beachten, daß viele dieser Felder im Block 2500 der veränderlichen LCG-Information der Figur 12 ähnlich sind zu den Feldern im Block 1500 der veränderlichen AG-Information, der in der Figur 10 dargestellt ist. Bezüglich der Beschreibung dieser Felder wird auf die Beschreibung der Figur 10 hingewiesen. Die AG-Daten, auf die im Feld 2463 der Figur 11 Bezug genommen wird, sind in den Feldern 2531 bis 2533 der Figur 12 dargestellt. Die Information, die in diesen Feldern enthalten sind, erlauben es der LCG, die AG, an welche sie angeschlossen ist, zu identifizieren. Der Name und der Standort der Ausgangs-Programme sind in den Feldern 2561 bis 2569 dargestellt. Diese Programme werden im Falle eines Fehlers während der Erstellung eines Anwendungsprogrammes oder Programmpaketes aufgerufen.
Die Figur 13 zeigt den Block 3400 unveränderlicher PFG- Information der RU 3100 in der PFG-Ebene 3000. Es ist wiederum zu beachten, daß mehrere dieser Felder im Block 3400 der unveränderlichen PFG-Information der Figur 13 ähnlich sind zu den Feldern im Block 1400 der unveränderlichen AG-Information in der Figur 9. Bezüglich der Beschreibung dieser Felder wird auf die Beschreibung der Figur 9 hingewiesen. Es ist jedoch zu beachten, daß die Lieferanten-Information, die in den Blöcken 1400 und 2400 enthalten ist, in dem Block 3400 nicht weiterhin enthalten ist. Das Feld 3434 identifiziert die LCG-ID, die in der hierarchischen Kette dominant zu dieser PFG-RU ist. Das Feld 3463 zeigt auf die Liste von SFG-RUs, die mit dieser PFG-RU verbunden sind. Diese Liste ist in dem Block 3500 der veränderlichen PFG-Information enthalten, wie dies in der Figur 14 dargestellt ist. Das Feld 3464 zeigt auf PFG- spezifische Informationen, die ebenfalls in dem Block 3500 der Figur 14 der veränderlichen PFG-Information enthalten sind. Die Felder 3461 und 3462 zeigen auf Hardware- und Software- Abhängigkeitsdaten, die, soweit vorhanden, in dem Block 3500 der veränderlichen PFG-Information enthalten sind.
Die Figur 14 zeigt den Block 3500 der veränderlichen PFG- Information der RU 3100 in der Ebene 3000. Es ist zu beachten, daß mehrere der Felder des Blockes 3500 der Figur 14 ähnlich sind zu den Feldern im Block 1500 der Figur 10. Bezüglich der Beschreibung dieser Felder wird auf die Beschreibung der Figur 10 hingewiesen.
Die Figur 15 zeigt den Block 4400 der unveränderlichen SFG- Information der RU 4100 in der Ebene 4000. Es ist zu beachten, daß viele der Felder des Blockes 4400 der unveränderlichen SFG- Information ähnlich sind zu den Feldern des Blockes 1400 der unveränderlichen AG-Information der Figur 9. Bezüglich der Beschreibung dieser Felder wird auf die Beschreibung der Figur 9 hingewiesen. Die Felder 4433 und 4434 identifizieren die RUs, die zu dieser SFG-RU in den höheren Ebenen der hierarchischen Kette dominant sind.
Das Feld 4461 zeigt auf eine Liste von OCG-RUs, die mit dieser SFG-RU verbunden sind. Diese Liste ist in dem Block 4500 der veränderlichen SFG-Information enthalten, wie in der Figur 16 dargestellt. Das Feld 4462 zeigt auf vorübergehende Umgehungs(fix)-/Korrektur(patch)-Aktivitäten, die in dem Block 4500 der variablen SFG-Informationen enthalten sind. Das Feld 4463 zeigt auf SFG-spezifische Informationen, die ebenfalls in dem Block 4500 der variablen SFG-Informationen enthalten sind.
Die Figur 16 zeigt den Block 4500 der veränderlichen SFG- Information der RU 4100. Es ist zu beachten, daß mehrere der Felder des Blockes 4500 ähnlich sind zu den Feldern im Block 1500 der Figur 10. Bezüglich der Beschreibung dieser Felder wird auf die Beschreibung der Figur 10 hingewiesen. Die Felder 4561 bis 4570 definieren eine Liste von vorübergehenden Umgehungs(fix)-/Korrektur(patch)-Aktivitäten, die mit dieser RU verbunden sind.
Noch einmal bezugnehmend auf die Figur 1: Die Programm-Packungs- Hilfsmittel 80, die von den Programmentwicklern 21 bis 24 verwendet werden, um die Programmpakete zu erstellen, werden nun beschrieben. Die Programm-Packungs-Hilfsmittel 80 bestehen aus Software, die auf einem Computer für allgemeine Anwendungen laufen, beispielsweise einem Personal-Computer, der geeignet programmiert ist, wie in den Figuren 17 bis 34 dargestellt. Die Figur 17 zeigt ein Menü der Hilfsmittel, die ein Programmentwickler verwenden kann, um ein Programmpaket zu erstellen. Die Programmentwickler verwenden das Programm-Packungsmittel, wie in der Figur 17 dargestellt, um Programme zu erstellen, die in vier Ebenen gepackt sind: LCG, PFG, SFG und OCG.
Das Programm-Packungs-Hilfsmittel 11000 erlaubt dem Programmentwickler, das Programmpaket zu definieren. Das Programm- Packungs-Hilfsmittel 11000 ist detailliert in den Figuren 10 bis 30 dargestellt. Das Programm-Packungs-Hilfsmittel 17000 erlaubt dem Programmentwickler, die Programmpakete anzuzeigen, die durch das Programm-Packungs-Hilfsmittel 11000 definiert wurden. Ein Beispiel eines Programmpaketes, das dem Programmentwickler angezeigt wird, zeigt die Figur 31.
Die Figur 18 zeigt den Gesamtsteuerfluß des Packungs-Hilfsmittels 11000. Es ist zu beachten, daß die Figur 18 ebenfalls den Gesamtsteuerfluß des Definitions-Anwendungspaket-Hilfsmittels 21000 zeigt, aufgrund der Ahnlichkeit zwischen diesen beiden Hilfsmitteln. Die Abschnitte der Flußdiagramme 18 bis 30, die einzigartig für das Anwendungspaket-Hilfsmittel 21000 sind, sind mit den Bezugszeichen 21000 bis 21999 versehen. Diese Abschnitte werden später beschrieben, in Verbindung mit der Beschreibung des Definitions-Anwendungspaket-Hilfsmittels 21000. Der Entscheidungsblock 11010 fragt den Programmentwickler, ob er eine LCG definieren möchte. Wenn der Programmentwickler anzeigt, daß er eine LCG definieren möchte, ist der LCG-Hauptteil in dem Block 11100 definiert. Die Details des Blocks 11100 sind in der Figur 19 dargestellt. Der LCG-Kopfteil ist anschließend in dem Block 11200 definiert. Die Details des Blocks 11200 sind in der Figur 25 dargestellt. Der Entscheidungsblock 11020 fragt den Programmentwickler, ob er eine PFG definieren möchte. Wenn ja, wird ein PFG-Hauptteil in dem Block 11400 definiert. Die Details des Blocks 11400 sind in der Figur 26 dargestellt. Der PFG- Kopfteil ist anschließend in dem Block 11200 definiert.
Die Details des Blocks 11200 sind in der Figur 25 dargestellt. Es ist zu beachten, daß der Block 11200 für das Definieren der Kopfteile von LCG-, PFG-, SFG-, AG- und OCG-Ebenen gemeinsam ist.
Der Entscheidungsblock 11030 fragt den Programmentwickler, ob er eine SFG definieren möchte. Wenn ja, ist der SFG-Hauptteil in dem Block 11500 definiert. Die Details des Blocks 11500 sind detailliert in der Figur 27 dargestellt. Der SFG-Kopfteil ist anschließend in dem Block 11200 definiert, wie vorstehend beschrieben. Der Entscheidungsblock 11050 fragt den Programmentwickler, ob er eine OCG definieren möchte. Wenn ja, verbindet sich der Block 11060 mit dem OCG-Hauptteil, welcher den operationalen Code oder Daten des Programmes enthält. Der Block 11200 definiert den OCG-Kopfteil, wie vorstehend beschrieben.
Der Block 11070 fragt den Programmentwickler, ob er das Hilfsmittel 11000 noch weiter verwenden möchte. Es ist zu beachten, daß wenn ein Programmentwickler ein Programmpaket von Grund auf entwirft, würde er die OCGs zuerst, dann die SFGs, dann die PFGs und dann die LCGs definieren.
Die Figur 19 zeigt, wie der Block 11100 der Figur 18 den LCG- Hauptteil definiert. Der Block 11100 fragt bei dem Programmentwickler unverzüglich die Lieferanteninformation ab, die in den Feldern 2431 bis 2439 enthalten ist, wie in der Figur 11 dargestellt. Typischerweise ist der Lieferant, nach dem in diesen Feldern gefragt wird, der Programmentwickler selbst oder das Unternehmen, für das er arbeitet, wenngleich ein anderer Lieferant an dieser Stelle spezifiziert werden könnte.
Der Block 11110 fordert den Programmentwickler auf, die Zeichenkonstante für die LCG anzugeben. Diese Daten werden in dem Feld 2440 der Figur 11 aufgenommen. Der Block 11111 fordert den Programmentwickler auf, die LCG-ID und Teil-Nummer anzugeben. Diese Information wird in die Felder 2450 und 2451 der Figur 11 eingestellt. Der Block 11112 fordert den Programmentwickler auf, die LCG-Wartungslevel-Information und Copyright-Information anzugeben. Diese Information wird in den Feldern 2452 bis 2456 der Figur 11 eingestellt. Der Block 11120 definiert die PFG- Liste, die mit dieser LCG verbunden ist. Der Block 11120 ist detailliert in der Figur 20 dargestellt und wird später beschrieben. Die Blöcke 21113 und 21130 werden von Anwendungsentwicklern verwendet und werden später beschrieben.
Der Entscheidungsblock 11114 fragt den Programmentwickler, ob LCG-spezifische Daten erforderlich sind. Wenn ja, werden LCGspezifische Daten im Block 11140 definiert. Der Block 11140 ist detailliert in der Figur 22 dargestellt und wird später beschrieben. Der Block 11115 fragt den Programmentwickler, ob irgendeine Hardware vorhanden ist, von der die LCG abhängig ist. Wenn ja, wird im Block 11160 eine Hardware-Abhängigkeitsliste definiert. Der Block 11160 ist detailliert in der Figur 23 dargestellt und wird später beschrieben.
Der Entscheidungsblock 11116 fragt den Programmentwickler, ob irgendeine Software vorhanden ist, von der die LCG abhängig ist. Wenn ja, wird im Block 11180 eine Software-Abhängigkeitsliste definiert. Der Block 11180 ist detailliert in der Figur 24 dargestellt und wird später beschrieben. Der Block 11117 sichert die Definitionen des LCG-Hauptteils, die durch den Programmentwickler definiert wurden, siehe Figur 19. Der Block 11118 schiebt den Steuerfluß zu Block 11200 vor, wo der LCG-Kopfteil definiert wird. Der Block 11200 wird später detailliert in Verbindung mit der Figur 25 beschrieben.
Die Figur 20 zeigt detailliert, wie eine PFG-Liste im Block 11120 definiert ist. Der Block 11121 fragt den Programmentwickler nach dem PFG-Namen und der ID. Diese Information wird in die Felder 2550 und 2552 der Figur 12 eingestellt. Der Block 11122 fragt den Programmentwickler nach dem PFG- Wartungslevel. Diese Information wird in die Felder 2553 und 2554 der Figur 12 eingestellt. Der Block 11124 fragt, ob der Benutzer möchte, daß irgendwelche andere PFGs in diese Liste eingehen. Wenn nicht, werden die Blöcke 11121 bis 11123 wiederholt, bis alle die PFGs in der Liste definiert sind. Wenn alle PFGs in der Liste definiert sind, setzt der Block 11125 die Felder 2541 und 2543 für die PFG-Größe der Eintragungen und die Anzahl der Eintragungen, siehe Figur 12. Der Block 11126 kehrt zurück zum Block 21113 der Figur 19.
Die Details, wie der Block 11140 die LCG-spezifischen Daten definiert, sind in der Figur 22 dargestellt. Der Block 11141 fragt den Programmentwickler nach den LCG-spezifischen Daten. Die LCG-spezifischen Daten werden in das Feld 2522 der Figur 12 eingestellt. Der Block 11142 setzt die Länge der LCG- spezifischen Daten, basierend auf den Inhalten des Feldes 2522. Die Länge wird in das Feld 2521 der Figur 12 eingestellt. Der Block 11143 kehrt zum Block 11115 der Figur 19 zurück.
Die Details, wie der Block 11160 die LCG-Hardware-Abhängigkeitenliste definiert, ist weiter detailliert in der Figur 23 dargestellt. Der Entscheidungsblock 11161 fragt den Programmentwickler, ob eine Hardware-Korrelations-ID für diese Hardware- Abhängigkeitsliste erforderlich ist. Wenn ja, wird die Hardware- Korrelations-ID in das Feld 332 der Figur 8 eingestellt, wie im Block 11162 gezeigt. Der Block 11163 fragt den Programmentwickler unmittelbar nach dem Hardware-Typ und der Modell- Nummer. Diese Information wird in die Felder 333 und 335 der Figur 8 eingestellt.
Der Entscheidungsblock 11164 fragt den Programmentwickler, ob eine Lade-ID für diese Eintragung in die Hardware-Abhängigkeitsliste erforderlich ist. Wenn ja, wird die Hardware-Lade-ID in das Feld 336 der Figur 8 eingestellt, wie im Block 11165 gezeigt. Wenn nicht, wird der Block 11165 übersprungen. Der Block 11166 fragt den Programmentwickler unmittelbar nach der Hardware-Teile-Nummer. Diese Information wird in das Feld 337 der Figur 8 eingestellt. Der Entscheidungsblock 11167 fragt, ob es noch irgendwelche weiteren Hardware-Abhängigkeiten gibt, die in diese Liste aufzunehmen sind. Wenn ja, werden die Blöcke 11161 bis 11166 solange wiederholt, bis alle Hardware- Abhängigkeiten in dieser Liste enthalten sind. Wenn alle Hardware-Abhängigkeiten in dieser Liste enthalten sind, bringt der Block 11168 die Größe des Hardware-Abhängigkeits-Listen- Feldes 338 und das Feld 331 für die Anzahl der Eintragungen der Figur 11 auf den neuesten Stand, um die neuen Informationen einzubinden. Der Block 11169 gibt die Kontrolle wieder an den Block 11116 der Figur 19 zurück.
Die Details, wie der Block 11180 die LCGs-Software-Abhängigkeitenliste definiert, ist in der Figur 24 dargestellt. Der Block 11181 fragt den Programmentwickler, ob eine Software- Korrelations-ID für diese Software-Abhängigkeitsliste erforderlich ist. Wenn ja, wird die Software-Korrelations-ID in das Feld 364 der Figur 8 eingestellt, wie im Block 11182 gezeigt. Wenn nicht, wird der Block 11182 übersprungen. Der Block 11183 fragt den Programmentwickler nach dem Software- Abhängigkeitstyp. Diese Information wird in das Feld 366 der Figur 8 eingestellt. Der Block 11184 fragt den Programmentwickler nach der LCG-ID und dem Wartungslevel der Software, von der die Abhängigkeit besteht. Diese Information wird in den Feldern 367 bis 369 der Figur 8 eingestellt. Der Block 11185 fragt den Benutzer, ob die Software, von der die Abhängigkeit besteht, eine SFG-RU ist. Wenn ja, wird der Programmentwickler unmittelbar im Block 11186 nach der SFG-ID und dem Wartungslevel gefragt. Diese Information wird in die Felder 373 bis 375 der Figur 8 eingestellt.
Der Entscheidungsblock 11187 fragt, ob es irgendwelche Abhängigkeiten von einem SFG-Zwischenprogramm-Änderungslevel (SFG interim program change level) gibt. Wenn ja, fragt der Block 11188 unmittelbar den Programmentwickler nach der SFG- Programmieränderungs-Vorläufigen-ID (SFG programming change interim ID). Diese Information wird in das Feld 376 der Figur 8 eingestellt. Wenn nicht, wird der Block 11188 übersprungen. Der Block 11189 fragt den Programmentwickler, ob es irgendwelche Abhängigkeiten von einer PFG-RU gibt. Wenn ja, wird der Programmentwickler unmittelbar nach der PFG-ID und dem Wartungslevel gefragt. Diese Information wird in den Feldern 370 bis 372 der Figur 8 eingestellt, wie im Block 11190 dargestellt. Wenn nicht, wird der Block 11190 übersprungen. Der Block 11191 fragt den Programmentwickler, ob alle Software-Abhängigkeiten definiert worden sind. Wenn nicht, kehrt die Steuerung an den Anfang der Figur 24 zurück, und die Blöcke 11181 bis 11190 werden wiederholt, bis alle Software-Abhängigkeiten definiert worden sind. Wenn einmal alle Software-Abhängigkeiten definiert worden sind, bringt der Block 11192 die Größe des Software- Abhängigkeits-Listen-Feldes 361 und das Feld 362 für die Anzahl der Eintragungen der Figur 8 auf den neuesten Stand. Der Block 11193 kehrt an den Block 11117 der Figur 19 zurück.
Die Details, wie der Block 11200 der Figur 18 einen LCG-Kopfteil definiert, ist in den Figuren 25A bis 25C dargestellt. Es ist zu beachten, daß die Beschreibung, wie ein LCG-Kopfteil definiert ist, die gleiche ist, wie die Beschreibung, wie ein PFG-Kopfteil, ein SFG-Kopfteil, ein AG-Kopfteil oder ein OCG-Kopfteil in der Figur 18 definiert ist. Der Block 11211 fragt den Programmentwickler unmittelbar nach dem Namen und der Referenz-ID von dieser RU. Diese Information wird in den Feldern 231 und 232 der Figur 7 eingestellt. Der Block 11212 fragt den Programmentwickler nach dem Versionslevel und dem Releaselevel der RU. Diese Information wird in den Feldern 249 und 250 der Figur 7 eingestellt. Der Block 11213 fragt den Programmentwickler nach der Steuerinformation und der Entwicklungsinformation für diese RU. Diese Information wird in den Feldern 242 und 243 der Figur 7 eingestellt. Der Block 11214 setzt den Namen des Systembereiches fest, welcher diese RU beinhaltet. Diese Information wird in dem Feld 266 der Figur 7 eingestellt. Der Block 11215 setzt das Datum und die Uhrzeit fest, an welcher diese bestimmte RU erschaffen wurde. Diese Information wird in den Feldern 244 und 246 der Figur 7 eingestellt.
Der Block 11219 fragt nach, ob diese RU eine LCG-RU ist. Wenn ja, setzt der Block 11220 die LCG-ID in dem Feld 234 der Figur 7 fest. Der Block 11221 holt die LCG-Hauptteil-Definition zurück, wie in dem Block 11100 definiert.
Der Block 11222 fragt nach, ob diese RU eine PFG-RU ist. Wenn ja, werden die LCG-ID und die PFG-ID in den Feldern 234 und 236 der Figur 7 festgesetzt, wie dies in dem Block 11223 dargestellt ist. Die PFG-Hauptteil-Definition, die in dem Block 11400 definiert ist, wird im Block 11224 zurückgeholt.
Der Block 11225 fragt nach, ob diese RU eine SFG-RU ist. Wenn ja, setzt der Block 11226 in den Feldern 234, 236 und 237 der Figur 7 die LCG-, PFG- und SFG-IDs fest, die mit dieser SFG verbunden sind.
Anschließend nimmt sich der Block 11255 die SFG-Hauptteil- Definition, wie in dem Block 11500 beschrieben. Der Block 11227 (Figur 25B) fragt nach, ob eine Hardware-Abhängigkeitsliste für diese RU definiert worden ist. Wenn ja, bestimmt der Block 11228, ob der Hardware-Abhängigkeits-Offset in dem RU- Hauptteil oder in dem RD-Kopfteil ist. Der RU-Abhängigkeits- Offset kann entweder in dem RU-Hauptteil oder in dem RU-Kopfteil sein, aber er kann im bevorzugten Ausführungsbeispiel nicht iii beiden sein. Wenn die Hardware-Abhängigkeits-Offset-Liste in dem RD-Hauptteil ist, ist die Hardware-Abhängigkeitsliste dem RU- Hauptteil im Block 11230 beigefügt. Wenn die Hardware-Abhängigkeits-Offset-Liste in dem RD-Kopfteil ist, ist die Hardware- Abhängigkeitsliste dem RD-Kopfteil im Block 11229 beigefügt. Im letztgenannten Fall ist die Information in das Feld 263 der Figur 7 eingestellt, um den Offset zu der Hardware-Abhängigkeitsliste aufzuzeigen.
Der Block 11231 fragt nach, ob eine Software-Abhängigkeitsliste für diese RD definiert worden ist. Wenn ja, bestimmt der Block 11232, ob der Software-Abhängigkeits-Offset in dem RD- Hauptteil oder in dem RD-Kopfteil enthalten ist. Wenn der Software-Abhängigkeits-Offset in dem RD-Hauptteil ist, ist die Software-Abhängigkeitsliste dem RD-Hauptteil im Block 11234 beigefügt. Wenn die Software-Abhängigkeits-Offset-Liste in dem RD-Kopfteil ist, ist die Software-Abhängigkeitsliste dem RD- Kopfteil im Block 11233 beigefügt. Die Information, die diesen Offset betrifft, ist in das Feld 264 der Figur 7 eingestellt.
Der Block 11235 fragt nach, ob systenspezifische Daten für diese RU definiert worden sind. Wenn ja, fragt der Block 11236 nach, ob der Offset zu diesen systemspezifischen Daten in dem RD- Hauptteil oder dem RD-Kopfteil enthalten ist. Wenn der Offset für die systemspezifischen Daten in dem RD-Hauptteil enthalten ist, sind die systemspezifischen Daten dem RU-Hauptteil im Block 11238 beigefügt. Wenn der Offset für die systemspezifischen Daten in dem RD-Kopfteil enthalten ist, sind die systemspezifischen Daten dem RD-Kopfteil im Block 11237 beigefügt. Daten betreffend diesen Offset sind im Feld 262 der Figur 7 eingestellt.
Der Block 11239 fragt nach, ob RU-spezifische Informationen für diese RD definiert worden sind. Wenn ja, fragt der Block 11240 nach, ob der Offset zu diesen RU-spezifischen Informationen in dem RD-Hauptteil oder dem RD-Kopfteil enthalten ist. Wenn der Offset für die RD-spezifischen Informationen in dem RD-Hauptteil ist, sind die RD-spezifischen Informationen dem RD-Hauptteil im Block 11242 beigefügt. Wenn der Offset für die RD-spezifischen Informationen in dem RD-Kopfteil enthalten ist, sind die RD- spezifischen Informationen dem RD-Kopfteil beigefügt, wie im Block 11241 dargestellt. Informationen über diesen Offset sind im Feld 265 der Figur 7 eingestellt.
Der Block 11243 (Figur 25C) fragt nach, ob diese RD eine OCG-RD ist. Wenn ja, setzt der Block 11244 die LCG-, PFG- und SFG-IDs für diese bestimmte OCG. Diese Information ist in den Feldern 234, 236 und 237 der Figur 7 eingestellt. Der Block 11245 fragt nach, ob die OCG eine Lade-ID besitzt. Wenn ja, wird die OCG- Lade-ID in das Feld 233 der Figur 7 eingestellt, wie im Block 11246 dargestellt.
Der Block 11247 fragt nach, ob diese OCG einen gemeinsamen Nameii besitzt. Wenn ja, wird dieser gemeinsame Name für die OCG in das Feld 254 der Figur 7 eingestellt, wie im Block 11248 dargestellt. Der Block 11249 fragt nach, ob der OCG-Hauptteil irgendwelche unbedingt erforderlichen Produktdaten in sich eingebettet hat. Wenn er dies hat, so wird das Feld 267 der Figur 7 aktualisiert, um auf den Teil des OCG-Hauptteils hinzuweisen, in dem sich die eingebetteten, unbedingt erforderlichen Daten befinden, wie in dem Block 11250 dargestellt.
Der Block 11251 aktualisiert die Gesamtlänge des RD-Hauptteils in dem Feld 222 der Figur 7. Der Block 11252 aktualisiert die Länge des RD-Hauptteils in dem Feld 1420 der Figur 9, wenn dies eine AG-RD ist, in dem Feld 2420 der Figur 11, wenn dies eine LCG-RD ist, in dem Feld 3420 der Figur 13, wenn dies eine PFG-RD ist und in dem Feld 4420 der Figur 15, wenn dies eine SFG-RD ist. Der Block 11253 berechnet die Gesamtlänge der RD und stellt diese Information in das Feld 221 der Figur 7 ein. Die Gesamtlänge der RD schließt den Kopfteil und den Hauptteil ein. Der Block 11254 kehrt zum Block 11020 zurück.
Die Details, wie der Block 11400 der Figur 18 einen PFG-Hauptteil definiert, ist detailliert in der Figur 26 dargestellt. Der Block 11410 fragt den Programmentwickler unmittelbar nach der ID dieser PFG und auch nach der ID der LCG, die diese PFG besitzt. Diese Information ist in den Feldern 3432 und 3434 der Figur 13 eingestellt. Der Block 11411 fragt den Programmentwickler unmittelbar nach der PFG-Teil-Nummer, dem Wartungslevel und der Copyright-Information. Diese Information ist in den Feldern 3435 bis 3450 der Figur 13 eingestellt.
Der Block 11412 fragt den Programmentwickler, ob diese PFG von irgendeiner anderen Hardware abhängig ist. Wenn ja, wird eine Hardware-Abhängigkeitsliste definiert, wie in dem Block 11160 dargestellt. Der Block 11160 ist in der Figur 23 detaillierter dargestellt und wurde bereits beschrieben. Der Block 11413 fragt den Programmentwickler, ob diese PFG irgendwelche Software- Abhängigkeiten aufweist. Wenn die Antwort "JA" lautet, definiert der Block 11180 eine Software-Abhängigkeitsliste für diese PFG. Die Details des Blockes 11180 sind in der Figur 24 dargestellt und sind bereits beschrieben worden. Der Block 11120 definiert eine SFG-Liste von allen SFGs, die mit dieser PFG verbunden sind. Der Block 11120 ist in der Figur 20 detaillierter dargestellt und wurde bereits beschrieben. Der Block 11414 fragt den Programmentwickler, ob irgendwelche PFG-spezifischen Informationen erforderlich sind. Wenn ja, ist die PFG-spezifische Information im Block 11140 definiert. Die Details des Blockes 11140 sind in der Figur 22 dargestellt und sind bereits beschrieben worden. Ein Offset zu diesen PFG-spezifischen Informationen wird in dem Feld 3464 der Figur 13 eingestellt. Der Block 11415 speichert diese in der Figur 26 erstellten Informationen zum PFG-Hauptteil. Der Block 11416 reicht den Arbeitsfluß an den Block 11200 weiter, wie in der Figur 25 dargestellt, in der ein PFG-Kopfteil definiert ist.
Die Details, wie der Block 11500 einen SFG-Hauptteil, wie in der Figur 18 dargestellt, definiert, wird nun in der Figur 27 beschrieben. Der Block 11510 fragt den Programmentwickler unmittelbar nach der SFG-ID und auch nach der LCG-ID und der PFG-ID, die diese bestimmte SFG besitzen. Diese Informationen sind in den Feldern 4431, 4433 und 4434 der Figur 15 eingestellt. Der Block 11511 fragt den Programmentwickler unmittelbar nach der SFG-Teil-Nummer, dem Wartungslevel und der Copyright- Information. Diese Information ist in den Feldern 4435 bis 4450 der Figur 15 eingestellt. Der Block 11512 fragt den Programmentwickler, ob diese SFG von irgendeiner anderen Hardware abhängig ist. Wenn die Antwort "JA" lautet, wird eine SFG- Hardware-Abhängigkeitsliste in dem Block 11160 definiert.
Die Details des Blockes 11160 sind in der Figur 23 dargestellt und wurden bereits beschrieben. Der Block 11513 fragt den Programmentwickler, ob diese SFG irgendwelche Software- Abhängigkeiten aufweist. Wenn die Antwort "JA" lautet, wird eine Software-Abhängigkeitsliste für diese SFG im Block 11180 erstellt. Die Details des Blockes 11180 sind in der Figur 24 dargestellt und sind bereits beschrieben worden. Der Block 11520 erstellt eine OCG-Liste, die diese SFG mit allen ihren OCGs verbindet. Die Details, wie der Block 11520 diese OCG-Liste erstellt, sind in der Figur 28 dargestellt und werden später beschrieben. Ein Offset zu dieser OCG-Liste ist in das Feld 4461 der Figur 15 eingestellt. Der Block 11550 erstellt eine Liste der vorübergehenden Umgehungs-/Korrektur-Aktivitäten (temporary fix/patch activity list) für diese SFG. Diese Liste ist in den Feldern 4561 bis 4570 der Figur 16 enthalten. Ein Offset zu dieser Liste ist in dem Feld 4462 der Figur 15 eingestellt. Der Block 11514 fragt nach, ob irgendeine SFG-spezifische Informationen erforderlich sind. Wenn die Antwort "JA" lautet, werden die SFG-spezifischen Informationen im Block 11140 erstellt. Der Block 11140 ist detaillierter in der Figur 22 dargestellt und wurde bereits beschrieben. Die SFG-spezifischen Informationen werden in das Feld 4521 eingestellt, die Länge der SFG-spezifischen Informationen wird in das Feld 4520 eingestellt, und der Offset der SFG-spezifischen Informationen wird in das Feld 4563 der Figur 15 eingestellt. Der Block 11515 sichert die Definition des SFG-Hauptteils, wie in der Figur 27 definiert. Der Block 11516 gibt den Steuerfluß an den Block 11200 weiter, wo ein SFG-Kopfteil definiert ist.
Die Details, wie der Block 11520 eine OCG-Liste definiert, sind in der Figur 28 dargestellt. Der Block 11521 fragt den Programmentwickler unmittelbar nach dem Namen des System- Standortes, an dem sich die OCG befindet. Diese Information ist in dem Feld 4544 der Figur 16 eingestellt. Der Block 11522 erhält den Parameter, um diese OCG in einem System-Standort zu identifizieren. Dies kann dadurch erfolgen, daß entweder nach allen OCGs an einem Standort gefragt wird, nach allen OCGs mit einem bestimmten Namen an einem Standort oder durch manuelle Eingabe von allen diesen OCGs.
Der Block 11523 fragt nach dem Namen dieser OCG und der sekundären OCG-Identifikation. Der Block 11524 fragt, ob diese OCG zu einer anderen SFG gehört. Wenn die Antwort "JA" lautet, wird die OCG-Ausnahme-Liste im Block 11525 aktualisiert. Eine OCG sollte nur zu einer SFG gehören. Der Block 11526 stellt den Namen dieser OCG und die sekundäre ID dieser OCG in die Felder 4547 und 4548 der Figur 16. Der Block 11527 fragt, ob diese OCG an einem System-Standort existiert. Wenn nicht, weist der Block 11528 der Wartungslevel-Information den gleichen Inhalt zu wie die Definitions-Wartungslevel-Information der SFG, welcher diese bestimmte OCG gehört. Aus diesem Grund wird die Information in dem Feld 4436 der Figur 15 in das Feld 4549 der Figur 16 kopiert, und die Wartungslevel-Information in dem Feld 4437 der Figur 15 wird in das Feld 4550 der Figur 16 kopiert.
Der Block 11529 fragt nach der OCG-Wartungslevel-Information. Diese Information ist in den Feldern 4549 bis 4554 eingestellt. Der Block 11530 fragt, ob alle OCGs in dem Systemspeicher prozessiert worden sind. Wenn nicht, kehrt die Steuerung zum Block 11552 zurück. Wenn alle prozessiert worden sind, setzt der Block 11531 die Größe dieser System-Standort-Liste in das Feld 4543 der Figur 16 und die Anzahl der OCG-Eintragungen in die Liste im Feld 4546 der Figur 16. Der Block 11532 fragt, ob alle die System-Lokationen prozessiert worden sind. Wenn nicht, kehrt die Steuerung wieder ganz zum Block 11521 zurück. Wenn alle System-Lokationen prozessiert worden sind, setzt der Block 11533 die Größe der OCG-Liste in das Feld 4541 der Figur 16 und eine Anzahl von System-Standort-Eintragungen in das Feld 4542 der Figur 16. Der Block 11534 setzt den Benutzer von denjenigen OCGs in Kenntnis, die nicht auf der Liste vertreten sind. Der Block 11535 gibt die Steuerung zurück an den Block 11550 der Figur 27.
Nachdem ein Programmentwickler ein oder mehrere Programmpakete definiert hat, kann er das Packungs-Hilfsmittel 17000 verwenden, um die Programmpakete auf seinem Anzeige-Bildschirm anzeigen zu lassen. Wenn beispielsweise der Programmentwickler 21 die fünf Programmpakete in der Bibliothek 30 definiert, wie in der Figur 2 dargestellt, und dabei das Programmpaket-Definitions- Hilfsmittel 11000 verwendet, wäre das dem Programmentwickler angezeigte Schirmbild so, wie in der Figur 31 dargestellt. Die kurze Beschreibung ist in der Spalte 17050 angezeigt. Die LCG-ID ist in der Spalte 17100 angezeigt. Die PFG-ID ist, soweit vorhanden, in der Spalte 17200 angezeigt. Die SFG-ID ist, soweit vorhanden, in der Spalte 17300 angezeigt. Der Name der RD ist in der Spalte 17400 angezeigt. Der RD-Typ ist in der Spalte 17500 angezeigt. Der Name des System-Standorts, an dem die RD sitzt, ist in der Spalte 17600 angezeigt. Die Spalten 17700, 17800 und 17900 zeigen jeweils die verfügbaren, installierten und aktivierten Anzeiger (flags) für die RD an. Alle drei dieser Flags müssen gesetzt sein, bevor ein Benutzer die Funktion der RD verwenden kann. Es ist zu beachten, daß einige der RUs nur verfügbar sind, während andere verfügbar und installiert sind und noch andere verfügbar, installiert und aktiviert sind.
Nochmals bezugnehmend auf die Figur 1: Das Anwendungs-Packungs- Hilfsmittel 90 kann verwendet werden, um dem Anwendungsentwickler 26 zu ermöglichen, ein Anwendungspaket zu erstellen. Der Anwendungsentwickler 26 erstellt ein Anwendungspaket, indem er einige der Programmpakete auswählt, die in der Bibliothek 30 enthalten sind. Weiterhin werden einige der primären und sekundären Funktionen des Programmpaketes ausgewählt, während andere weggelassen werden. Der Anwendungsentwickler 26 verwendet das Anwendungs-Packungs-Hilfsmittel 90, um das obige zu erreichen, indem er eine Anwendung erstellt, die fünf Ebenen enthält: AG, LCG, SFG, PFG und OCG. Das Anwendungs-Packungs- Hilfsmittel 90 besteht aus Software, die auf einem Computer für allgemeine Anwendungen lauffähig ist, wie etwa ein Personal Computer, der, wie in den Figuren 17 bis 34 dargestellt, geeignet programmiert ist.
Die Figur 32 zeigt einen Menü-Bildschirm der möglichen Packungs Hilfsmittel, die der Anwendungsentwickler verwenden kann, um ein Anwendungspaket zu erstellen. Das Packungs-Hilfsmittel 21000 definiert ein Anwendungspaket. Das Packungs-Hilfsmittel 24000 wählt die primären und sekundären Funktionen jedes Programmpaketes aus, das in das Anwendungspaket aufgenommen werden soll. Das Packungs-Hilfsmittel 27000 zeigt das erstellte Anwendungspaket an.
Das Packungs-Hilfsmittel 21000 ist dem Packungs-Hilfsmittel 11000 sehr ähnlich, das vorstehend beschrieben wurde. Das Packungs-Hilfsmittel 21000 macht, zusätzlich zu den Funktionen des Hilfsmittels 11000, einem Anwendungsentwickler einige weitere Funktionen verfügbar, die im allgemeinen einem Programmentwickler nicht verfügbar gemacht werden. Diese zusätzlichen Funktionen sind in den Figuren 18 bis 30 mit Bezugszeichen 21000 bis 21999 dargestellt und werden nun beschrieben.
Zuerst mit Bezug auf die Figur 18: Der Entscheidungsblock 21040 fragt den Anwendungsentwickler, ob er eine AG definieren möchte. Wenn ja, wird ein AG-Hauptteil im Block 21600 definiert. Der Block 21600 ist detailliert in der Figur 29 dargestellt. Der AG-Kopfteil ist anschließend detaillierter im Block 11200 definiert, wie vorstehend beschrieben.
Nun mit Bezug auf die Figur 19: Der Block 21113 fragt den Anwendungsentwickler, ob AG-Informationen erforderlich sind, die mit dieser LCG gehen. Wenn ja, wird im Block 21130 eine AG-Liste definiert. Der Block 21130 ist detaillierter in der Figur 21 dargestellt und wird als nächstes beschrieben.
Der Block 21130 definiert eine AG-Liste und ist detaillierter in der Figur 21 dargestellt. Der Block 21131 fragt den Anwendungsentwickler unmittelbar nach der ID für die AG. Diese Information wird in das Feld 2531 der Figur 12 eingestellt. Der Block 21132 fragt den Anwendungsentwickler unmittelbar nach dem Namen der AG. Diese Information wird in das Feld 2532 der Figur 12 eingestellt. Der Block 21133 fragt den Anwendungsentwickler unmittelbar nach dem Standort im Systemspeicher, an dem die AG- RU lokalisiert ist. Diese Information wird in das Feld 2533 der Figur 12 eingestellt. Der Block 21136 kehrt zum Block 21115 der Figur 19 zurück.
Bezugnehmend nun auf die Figur 25A: Der Block 21216 fragt, ob diese RD eine AG-RD ist. Wenn ja, wird die AG-ID für diese RD im Feld 234 der Figur 7 gesetzt, wie im Block 21217 dargestellt. Der Block 21218 holt die AG-Hauptteil-Definition zurück, wie im Block 21600 der Figur 29 definiert.
Die Details, wie der Block 21600 den AG-Hauptteil definiert, sind in der Figur 29 dargestellt. Der Block 21610 fragt den Anwendungsentwickler unmittelbar nach der AG-Lieferanten- Information und Zeichenkonstante. Diese Information wird in die Felder 1431 bis 1439 der Figur 9 eingestellt. Der Block 21611 fragt den Anwendungsentwickler unmittelbar nach der AG-ID und der AG-Teil-Nummer. Diese Information wird in die Felder 1443 bis 1444 der Figur 9 eingestellt. Der Block 21612 fragt den Anwendungsentwickler unmittelbar nach der AG-Wartungs- und Copyright-Information. Diese Information wird in die Felder 1445 bis 1449 der Figur 9 eingestellt. Der Block 21620 definiert die LCG-Liste für alle LCGs, die mit dieser AG verbunden sind. Die Details, wie der Block 21620 eine LCG-Liste definiert, sind in der Figur 30 dargestellt und werden nachfolgend beschrieben. Der Block 21613 fragt bei dem Programmentwickler unmittelbar nach, um zu sehen, ob irgendeine AG-spezifische Information erforderlich ist. Wenn ja, wird die AG-spezifische Information im Block 11140 definiert. Die Details, wie der Block 11140 die AG-spezifischen Daten definiert, sind in der Figur 22 dargestellt und sind bereits beschrieben worden. Der Block 21614 sichert die Definition des AG-Hauptteils, die in der Figur 29 erstellt wurde. Der Block 11615 übergibt den Steuerfluß an den Block 11200, wo ein AG-Kopfteil definiert ist. Die Details, wie der Block 11200 ein AG-Kopfteil definiert, sind in der Figur 25 dargestellt und sind bereits beschrieben worden.
Die Details, wie der Block 21620 eine LCG-Liste definiert, sind in der Figur 30 dargestellt. Der Block 21621 fragt den Anwendungsentwickler unmittelbar nach dem Namen und der ID der LCG. Diese Information wird in die Blöcke 1552 und 1554 der Figur 10 eingestellt. Der Block 21622 fragt den Programmentwickler nach der LCG-Wartungslevel-Information. Diese Information wird in die Felder 1555 und 1556 der Figur 10 eingestellt. Der Block 21623 setzt das LCG-Verfügbarkeits-Feld und fragt den Programmentwickler unmittelbar nach dem System-Standort, welcher die LCG beinhaltet. Diese Information wird in die Felder 1546 und 1550 der Figur 10 eingestellt. Der Block 21624 fragt, ob alle der LCGs für die Liste definiert worden sind. Wenn nicht, werden die Blöcke 21621 bis 21623 wiederholt. Wenn alle der LCGs definiert worden sind, setzt der Block 21625 die Anzahl der LCG-Eingaben in das Feld 1541 und die Größe der LCG-Liste in das Feld 1543 der Figur 10. Der Block 21626 kehrt zum Block 21613 der Figur 29 zurück.
Nachdem der Anwendungsentwickler das Anwendungspaket unter Verwendung des Hilfsmittels 21000 durch die Auswahl der LCGs, die in das Paket aufgenommen werden, definiert hat, verwendet der Anwendungsentwickler anschließend das Hilfsmittel 24000, um die Anwendungspaket-Funktionen auszuwählen. Wenn beispielsweise der Anwendungsentwickler 26, wie in der Figur 1 dargestellt, ein Anwendungspaket 61 für den Benutzer 41 erstellen wollte, so würde die Figur 33 ein Menü der ausgewählten Programmpakete anzeigen. Es ist zu beachten, daß die Spalten 24050 bis 24900 die gleichen sind, wie die Spalten 17050 bis 17900 der Figur 31. Die Spalte 24010 stellt einen Platz für den Anwendungsentwickler bereit, um die gewünschten primären Funktionen und sekundären Funktionen für das Anwendungspaket auszuwählen. Dm das Anwendungspaket 61 der Figur 3 zu definieren, würde ein Anwendungsentwickler für jede ausgewählte primäre Funktion und sekundäre Funktion, die in der Figur 3 dargestellt ist, ein "X" in die Spalte 24010 machen. Die nicht ausgewählten primären Funktionen und sekundären Funktionen werden von den Hauptteilen der LCGs und PFGs entfernt, bevor das Anwendungspaket an den Benutzer gesandt wird.
Das Packungs-Hilfsmittel 27000 zeigt das Anwendungspaket an, das durch die Hilfsmittel 21000 und 24000 erstellt wurde. Die Figur 34 stellt die Anzeige dar, die der Anwendungsentwickler nach Erstellung des Anwendungspaketes 61 der Figur 3 sehen würde.
Wie beschrieben worden ist, enthält das bevorzugte Ausführungsbeispiel der Erfindung fünf Ebenen, wie in der Figur 4 dargestellt. Jedoch sind nicht alle diese Ebenen erforderlich, um dennoch von der Lehre dieser Erfindung Gebrauch zu machen. Ein alternatives Ausführungsbeispiel ist erwägt worden, welches ein Programmpaket mit gerade zwei Ebenen aufweist: Die Ebene der ladbaren Codegruppen (Loadable Code Group level, LCG) 2000 und die Ebene der operationalen Codegruppen (Operational Code Group level, OCG) 5000. Wenngleich diese Ausführungsform die Erfordernisse eines Benutzers nicht im gleichen Maß erfüllt wie das Fünf-Ebenen-Schema der bevorzugten Ausführungsform, sind weiterhin viele der Vorteile der bevorzugten Ausführungsform offensichtlich. In diesem Ausführungsbeispiel sind die Figuren 9, 10, 13, 14, 15 und 16 nicht enthalten. Das Feld 2463 der Figur 11 wäre "Offset zur OCG-Liste" ("Ofset to OCG list") und das Feld 2465 wäre "Reserviert" ("Reserved"). Ebenso würde die PFG-Liste, dargestellt in der Figur 12, durch eine OCG-Liste ersetzt werden, und das Auswahl/Weglassen-Feld 2544 wäre "Reserviert". Die Felder 2531 bis 2533 wären in dieser alternativen Ausführungsform nicht enthalten. Ebenso sind viele der Abschnitte der Flußdiagramme der Figuren 18 bis 30 nicht erforderlich, um ein Programmpaket mit nur zwei Ebenen zu definieren.

Claims

1. Eine hierarchische Software-Verwaltungsstruktur für ein Computerprogramm, die aufweist:

eine erste austauschbare Einheit (100), die aufweist

einen ersten Vorsatz (110) und einen ersten Hauptteil (120), der erste Vorsatz enthält erste Wartungsinformationen (220, 260) und erste Identifikationsdaten (230);

eine zweite austauschbare Einheit (100), die aufweist

einen zweiten Vorsatz (110) und einen zweiten Hauptteil (120), der zweite Vorsatz enthält zweite Wartungsinformationen (220, 260) und zweite Identifikationsdaten (230); und

der erste Hauptteil (120) die zweiten Identifikationsdaten (430) aufweist und damit der ersten austauschbaren Einheit ermöglicht, eine Verbindung zu der zweiten austauschbaren Einheit in hierarchischer Form zu erstellen; wobei

die Verwaltungsstruktur dadurch gekennzeichnet ist, daß

die ersten und zweiten Vorsätze jeweils eine erste Liste und eine zweite Liste von Hardware (330) aufweisen, von der das korrekte Funktionieren der ersten und zweiten austauschbaren Einheit jeweils abhängig ist.

2. Die hierarchische Software-Verwaltungsstruktur nach Patentanspruch 1, wobei der erste Vorsatz (110) weiterhin eine erste Liste von Software (360) aufweist, von der das korrekte Funktionieren der ersten austauschbaren Einheit abhängig ist.

3. Die hierarchische Software-Verwaltungsstruktur nach irgendeinem der Patentansprüche 1 bis 2, wobei

der zweite Vorsatz weiterhin eine zweite Liste von Software (360) aufweist, von der das korrekte Funktionieren der zweiten austauschbaren Einheit abhängig ist.

4. Die hierarchische Software-Verwaltungsstruktur nach Patentanspruch 1, wobei

der erste Hauptteil (120) weiterhin eine Vielzahl von Identifikations-Informationen (430) aufweist, die einer Vielzahl von austauschbaren Einheiten entsprechen.

5. Die hierarchische Software-Verwaltungsstruktur nach Patentanspruch 1, wobei

in der zweiten austauschbaren Einheit (600) der zweite Hauptteil (620) einen operationalen Code (630) aufweist, um das Computerprogramm auszuführen.

6. Die hierarchische Software-Verwaltungsstruktur nach irgendeinem der Patentansprüche 1 bis 4, wobei

die erste austauschbare Einheit (100) sich in einer Ebene der Anwendungsgruppen (1000) befindet.

7. Die hierarchische Software-Verwaltungsstruktur nach Patentanspruch 6, wobei

die zweite austauschbare Einheit (100) sich in einer Ebene der Gruppe der ladbaren Codes (2000) befindet.

8. Die hierarchische Software-Verwaltungsstruktur nach Patentanspruch 7, weiterhin aufweisend

eine Ebene der primären funktionalen Gruppen (3000), die eine dritte austauschbare Einheit (100) beinhaltet.

9. Die hierarchische Software-Verwaltungsstruktur nach Patentanspruch 8, weiterhin aufweisend

eine Ebene der sekundären funktionalen Gruppen (4000), die eine vierte austauschbare Einheit (100) beinhaltet.

10. Die hierarchische Software-Verwaltungsstruktur nach Patentanspruch 9, weiterhin aufweisend

eine Ebene der Gruppe der operationalen Codes (5000), die eine fünfte austauschbare Einheit (600) beinhaltet.

11. Die hierarchische Software-Verwaltungsstruktur nach Patentanspruch 10, wobei

die dritte austauschbare Einheit (100) und vierte austauschbare Einheit (100) jeweils dritte und vierte Vorsätze (110) und dritte und vierte Hauptteile (120) aufweisen, wobei

die dritten und vierten Vorsätze jeweils dritte und vierte Wartungsinformationen und dritte und vierte Identifikationsdaten enthalten.

12. Die hierarchische Software-Verwaltungsstruktur nach Patentanspruch 10 oder 11, wobei

die fünfte austauschbare Einheit (600) weiterhin einen fünften Vorsatz (110) und einen fünften Hauptteil (620) aufweist, wobei

der fünfte Vorsatz fünfte Wartungsinformationen und fünfte Identifikationsdaten enthält.

13. Die hierarchische Software-Verwaltungsstruktur nach Patentanspruch 12, wobei

die zweiten, dritten und vierten Hauptteile jeweils die dritten, vierten und fünften Identifikationsdaten aufweisen, und damit den zweiten, dritten und vierten austauschbaren Einheiten ermöglichen, Verbindungen zu den dritten, vierten und fünften austauschbaren Einheiten in hierarchischer Form zu erstellen; und wobei

der fünfte Hauptteil (620) operationalen Code (630) aufweist, um das Computerprogramm auszuführen.

14. Ein Verfahren zum Organisieren einer hierarchischen Software-Verwaltungsstruktur auf einem Speichermedium eines Computerprogrammes, wobei

das Verfahren die Schritte aufweist:

Generieren und Speichern einer ersten austauschbaren Einheit (100), die aufweist

einen ersten Vorsatz (110) und einen ersten Hauptteil (120), wobei der erste Vorsatz erste Wartungsinformationen (220, 260) und erste Identifikationsdaten (230) enthält, und

der erste Vorsatz weiterhin eine erste Liste von Hardware (330) aufweist, von der das korrekte Funktionieren der ersten austauschbaren Einheit abhängig ist;

Generieren und Speichern einer zweiten austauschbaren Einheit (600), die aufweist

einen zweiten Vorsatz (110) und einen zweiten Hauptteil (620), der zweite Vorsatz zweite Wartungsinformationen (220, 260) und zweite Identifikationsdaten (230) enthält; und

der zweite Vorsatz weiterhin eine zweite Liste von Hardware (330) aufweist, von der das korrekte Funktionieren der zweiten austauschbaren Einheit abhängig ist; und

Verbinden der ersten austauschbaren Einheit mit der zweiten austauschbaren Einheit in hierarchischer Form durch die Einbindung der zweiten Identifikationsdaten (430) in den ersten Hauptteil (120).

15. Das Verfahren zum Organisieren einer hierarchischen Software-Verwaltungsstruktur nach Patentanspruch 14, weiterhin aufweisend die Schritte:

Generieren und Speichern einer ersten Liste von Software (360), von der das korrekte Funktionieren der ersten austauschbaren Einheit abhängig ist, in dem erstern Vorsatz (110); und

Generieren und Speichern einer zweiten Liste von Software (360), von der das korrekte Funktionieren der zweiten austauschbaren Einheit abhängig ist, in dem zweiten Vorsatz (110).

16. Das Verfahren zum Organisieren einer hierarchischen Software-Verwaltungsstruktur nach Patentanspruch 15, weiterhin aufweisend den Schritt

Speichern einer Vielzahl von Identifikations-Informationen, entsprechend einer Vielzahl von austauschbaren Einheiten, in dem ersten Hauptteil (120).

17. Das Verfahren zum Organisieren einer hierarchischen Software-Verwaltungsstruktur nach Patentanspruch 16, weiterhin aufweisend die Schritte:

Speichern eines operationalen Codes (630) in dem zweiten Hauptteil (120), um das Computerprogramm auszuführen; und

Speichern einer Beschreibung der Funktionen des operationalen Codes in dem ersten Hauptteil (110).

18. Das Verfahren zum Organisieren einer hierarchischen Software-Verwaltungsstruktur nach Patentanspruch 17, um für das Erstellen eines Software Anwendungspaketes verwendet zu werden, wobei das Verfahren weiterhin die Schritte aufweist:

Anzeigen von ersten textförmigen Beschreibungen einer Vielzahl von ersten Funktionen eines ersten Programmpaketes, das eine erste Vielzahl von austauschbaren Einheiten aufweist, auf dem Computer-Bildschirm;

Auswählen einiger dieser ersten textförmigen Beschreibungen aus der Vielzahl der ersten Funktionen;

Anzeigen von zweiten textförmigen Beschreibungen einer Vielzahl von zweiten Funktionen eines zweiten Programmpaketes, das eine zweite Vielzahl von austauschbaren Einheiten aufweist, auf dem Computer-Bildschirm;

Auswählen einiger dieser zweiten textförmigen Beschreibungen aus der Vielzahl der zweiten Funktionen; und

Erstellen des Anwendungspaketes aus

den Einigen der Vielzahl von ersten Funktionen und den Einigen der Vielzahl von zweiten Funktionen, ausgewählt in den Auswahl-Schritten,

durch Kombinieren

der ersten Vielzahl von austauschbaren Einheiten, die den Einigen der Vielzahl der ersten Funktionen entsprechen,

mit

der zweiten Vielzahl von austauschbaren Einheiten, die den Einigen der Vielzahl der zweiten Funktionen entsprechen.