DE10006417A1

DE10006417A1 - Computersystem mit Einzelverarbeitungsumgebung für die Ausführung von mehreren Anwendungsprogrammen

Info

Publication number: DE10006417A1
Application number: DE10006417A
Authority: DE
Inventors: Charles K Keyes
Original assignee: Hewlett Packard Co
Current assignee: Hewlett Packard Development Co LP
Priority date: 1999-04-26
Filing date: 2000-02-14
Publication date: 2000-11-02
Also published as: US6453460B1; JP2000322261A

Abstract

Ein Computersystem umfaßt eine Umgebung mit einem Einzelverarbeitungsraum, der nicht für eine Multiverarbeitung mit einem Prozeßschalter versehen ist. Bei einer solchen Umgebung können mehrere Anwendungsprogramme ohne Konflikt auf gemeinsame Bibliotheksprogrammspezifikationen verweisen. Wenn beispielsweise ein erstes Anwendungsprogramm eine Instanziierung eines Bibliotheksobjekts anfordert, wird das Bibliotheksobjekt durch ein Factory-Objekt der Bibliothek instanziiert. Instanzvariablen eines Einzelgegenstand-Factory-Objekts für jedes Anwendungsprogramm liefern gemeinsam verwendete Daten zwischen Bibliotheksobjekten. Ein Verfahren zum Integrieren von Programmspezifikationen kann das Überarbeiten von Bibliotheksklassen, das Ändern von statistischen Klassenvariablen in Factory-Instanzvariablen und das Umkompilieren der Bibliothek, um alle Verweise auf statistische Klassenvariablen durch Verweise auf Factory-Instanzvariablen zu ersetzen, aufweisen. Mehrere Anwendungsprogramme, die vielleicht unabhängig entwickelt wurden, können dann in einer Einzelverarbeitungsumgebung, beispielsweise einer virtuellen JAVA-Maschine, die für ein einzelnes Anwendungsprogramm entworfen ist, ausgeführt werden.

Description

Ausführungsbeispiele der vorliegenden Erfindung beziehen sich auf Verfahren zum Entwickeln von objektorientierten Programmen und von Systemen, die objektorientierte Programme ausführen.

Ein objektorientiertes Programm ist ein Computerprogramm, das in einer Computerprogrammiersprache geschrieben wurde, die eine Semantik besitzt, um Softwarekomponenten zu be schreiben, die entworfen sind, um durch das Übermitteln von Nachrichten zwischen denselben zusammenzuarbeiten. Ein sol ches Computerprogramm definiert das Gesamtprogrammverhalten als eine Kombination des Verhaltens sogenannter "Objekte". Ein Objekt ist eine Zuordnung einer Datenstruktur und eines Verhaltens. Ein objektorientiertes Programm kann ein Mehr aufgaben-Programmverhalten verwenden (Multitasking-Program Behavior).

Obwohl es möglich ist, daß der Computer, der ein objekt orientiertes Programm durchführt, nur eine Zentralverarbei tungseinheit für die Ausführung jeweils nur eines Befehls zu einer Zeit aufweist, können bestimmte der Befehle jedes Ob jekts der Reihe nach scheibchenweise gemäß bekannten Techni ken eines Zeitteilungsverfahrens (Time-Sharing-Betrieb) aus geführt werden.

Ein objektorientiertes Programm kann scheinbar auf einen größeren Bereich von Eingangssignalen ansprechen als ein herkömmliches nicht-objektorientiertes Programm, um das gleiche Gesamtverhalten zu liefern. Programmierer haben he rausgefunden, daß für ein komplexes Verhalten ein Programm, das unter Verwendung von objektorientierten Programmiertech niken entwickelt wird, mit größerer Wahrscheinlichkeit das richtige Verhalten ansprechend auf eine spezielle Sequenz von Eingangssignalen aus einem großen Bereich von Eingangs signalen, die zu zahlreich sind, um alle Kombinationen der selben zu testen, liefert.

Die Semantik einer objektorientierten Programmiersprache er möglicht die Beschreibung eines Programms, das mehrere Ob jekte aufweist, von denen jedes mit seinen eigenen Werten arbeitet. Beispielsweise kann eine Anzeige mehrerer Kreise, die kontinuierlich und scheinbar gleichzeitig zu zufälligen Zeitpunkten an zufälligen Positionen und mit zufälligen Größen neu gezeichnet werden, durch ein objektorientiertes Programm mit mehreren Objekten definiert werden, wobei jedes Objekt die Funktion hat, einen Kreis zu zeichnen, und wobei jedes Objekt mit einem ausschließlichen Zugriff auf seine eigenen Variablen arbeitet. Aus der Sicht der Zentralverar beitungseinheit (CPU; CPU = Central Processing Unit) kann das Verhalten eines Objekts als eine Sequenz von Befehlen in dem ausführbaren Befehlscode, der für die CPU geeignet ist, der von spezifischen Adressen in einem Speicher geholt wird, ausgedrückt werden. Derartige Befehle bewirken, daß die CPU die Werte zahlreicher Variablen an spezifischen Adressen in dem Speicher liest und modifiziert. Um das scheinbar gleich zeitige Neuzeichnen von Kreisen zu erreichen, ist die Aus führung jedes Objekts auf eine Zeitscheibe begrenzt. Da eine Zeitscheibe zu jedem Moment enden kann, während die Sequenz durch eines der Kreiszeichnungsobjekte durchgeführt wird, müssen Daten, die die Position in der Befehlssequenz (einen Teilprozeß (thread)) beschreiben, gesichert werden, wobei später durch die CPU darauf Bezug genommen wird, um einen speziellen Kreis fortzusetzen, wenn diesem speziellen Objekt eine weitere Zeitscheibe gegeben wird.

Jedes Objekt besitzt ein Verhalten und einen Zustand. Die Funktionen (d. h. Operationen oder Dienste) eines Objekts werden als sein Verhalten bezeichnet. Die Daten, die Werte von Variablen beschreiben, und die Daten, die die Position in der Befehlssequenz beschreiben, werden gemeinsam als der Objektzustand bezeichnet. Ein objektorientiertes Programm definiert in einer Programmspezifikation das Verhalten jedes einzigartigen Objekts und die Variablen, die für seine Funk tionen benötigt werden. Diese Definition wird bei einigen Programmiersprachen als eine Klasse bezeichnet, aus der ein oder mehrere Instanzen (instances; Spezialfälle) des Objekts in Gang gebracht werden (d. h. instanziiert werden (instan tiated)).

Komplexe Programme sind typischerweise in Modulen geschrie ben, die manchmal als Pakete bezeichnet werden. Die Defini tion, die durch den Programmierer in allen Modulen zusammen genommen gegeben wird, wird modulweise kompiliert, wobei nachfolgend die Ergebnisse des Kompilierens verknüpft wer den, um einen ausführbaren Code mit spezifischen Bezugnahmen auf Speicheradressen zu erzeugen. Das Verknüpfen kann auf einen Zeitpunkt verzögert werden, gerade bevor die Objekte eines speziellen Moduls benötigt werden.

Im Gebrauch wird Speicher für jeden Zustand jeder Instanz jedes Objekts zugeteilt. Fortsetzend mit dem obigen Anzeige beispiel kann, da alle der Kreiszeichnungsobjekte das glei che Verhalten besitzen, der Speicher zu einem speziellen Zeitpunkt eine Kopie des Kreiszeichnungsverhaltens (bei spielsweise des Befehlscodes für eine Verfahrensspezifika tion einer Klasse), das von allen Kreiszeichnungsobjekten verwendet wird, enthalten; und eine Kopie des Kreiszeich nungszustands (der beispielsweise durch den Prototyp der Klasse definiert ist) für jede Instanz des Kreiszeichnungs objekts.

Wenn Programmiererteams über Zeiträume von Jahren Produkte entwickeln, die Computerprogramme enthalten, ist es er wünscht, bei einem nächsten Produkt die getesteten Verhalten bestimmter der vorher entwickelten Objekte einzubinden. Je doch können derartige Objekte Funktionen aufweisen, die nicht unabhängig definiert wurden, da beispielsweise die ge meinsame Verwendung von Daten zwischen Funktionen mit Bezug nahmen auf eine oder mehrere Variablen außerhalb des Objekt zustands implementiert wurde. Ohne ein einfaches Verfahren zum Festlegen einer Unabhängigkeit zwischen Modulen ist ein aufwendiges Neuschreiben jedes Verhaltens jedes Moduls, das in das nächste Produkt eingebunden werden soll, unvermeid lich. Die Zeit und der Aufwand für ein solches Unterfangen kann verhindern, daß einige Produkte auf den Markt gebracht werden. Folglich sind das Ausmaß und der Gang des Wettbe werbs beschränkt und Vorteile für die Gesellschaft kommen nicht zustande.

Die Aufgabe der vorliegenden Erfindung besteht darin, Vor richtungen und Verfahren zu schaffen, die die Ausführung mehrerer Anwendungsprogramme in einer Einzelverarbeitungsum gebung ermöglichen.

Diese Aufgabe wird durch eine Speichervorrichtung nach An spruch 1, eine Druckervorrichtung nach Anspruch 7 und ein Verfahren nach Anspruch 16 gelöst.

Ein Speicher gemäß verschiedenen Aspekten der vorliegenden Erfindung umfaßt Indizien eines objektorientierten Pro gramms, das im Betrieb Indizien eines Zustands liefert. Der Zustand umfaßt zwei Instanzen einer Factory (wobei der Aus druck Factory auf dem Gebiet der objektorientierten Program mierung verwendet wird, um ein Objekt zu bezeichnen, das an dere Objekte bzw. Instanzen von Objekten erzeugt) und zwei Instanzen eines Objekts. Die erste Instanz der Factory um faßt eine Erste-Instanz-Variable. Die zweite Instanz der Factory umfaßt eine Zweite-Instanz-Variable. Die Erste-In stanz-Variable spricht auf entweder die Instanziierung (In stantiation; Spezialisierung) des ersten Objekts durch die Factory an oder spricht auf eine Operation des ersten Ob jekts an. Die Zweite-Instanz-Variable spricht auf entweder die Instanziierung des zweiten Objekts durch die zweite Factory an, oder spricht auf eine Operation des zweiten Ob jekts an. Die Erste-Instanz-Variable ist unabhängig von sowohl der Instanziierung des zweiten Objekts als auch der Operation des zweiten Objekts.

Wenn beispielsweise die Erste-Instanz-Variable und die Zwei te-Instanz-Variable der jeweiligen Factorys auf die Instan ziierung des ersten und des zweiten Objekts ansprechen, hält jede Factory einen Zählwert der Anzahl von Objekten, die dieselbe instanziiert hat. Jedes Objekt kann die jeweilige Anzahl von Instanzen lesen, die für seine Factory gelten. Durch das Implementieren eines Zählwerts von Instanzen als eine Instanzvariable einer jeweiligen Factory, im Gegensatz zu einer statischen Variable der Objektklasse, können das erste und das zweite Objekt unabhängig voneinander ausge führt werden. Wenn die Ausführungsumgebung eine virtuelle JAVA-Maschine (JVM; JVM = JAVA virtual machine) aufweist, die einen Einzelverarbeitungsraum unterstützt, ermöglicht als ein weiteres Beispiel eine unabhängige Ausführung, wie sie oben beschrieben wurde, daß mehrere Anwendungsprogramme gleichzeitig durch die JVM ausgeführt werden.

Ein Drucker umfaßt gemäß verschiedener Aspekte der vorlie genden Erfindung eine Druckmaschine, einen Prozessor und ei nen Speicher. Der Prozessor liefert Daten zu der Druckma schine. Der Speicher besitzt Indizien eines objektorientier ten Programms, das durch den Prozessor ausgeführt wird, um wie oben erläutert Indizien eines Zustands zu liefern. Wenn beispielsweise die Erste-Instanz-Variablen und die Zweite- Instanz-Variablen der jeweiligen Factorys jeweils auf Opera tionen der Objekte ansprechen, kann jedes Objekt die In stanzvariable seiner Factory unabhängig von den Operationen des anderen Objekts verwenden. Wenn die Ausführungsumgebung eine virtuelle JAVA-Maschine (JVM) umfaßt, die einen Einzel verarbeitungsraum unterstützt, ermöglicht eine unabhängige Ausführung, wie sie oben beschrieben ist, daß mehrere Anwen dungsprogramme unabhängig das Verhalten des gleichen Biblio theksobjekts mit unabhängigen Zuständen verwenden.

Ein Verfahren zum Integrieren einer ersten Programmspezifi kation mit Anwendungsprogrammspezifikationen umfaßt gemäß verschiedenen Aspekten der vorliegenden Erfindung zwei Schritte, die in einer beliebigen Reihenfolge durchgeführt werden. Die erste Spezifikation umfaßt Bezugnahmen auf sta tische Daten. Die resultierende Integration ist in einer Um gebung, beispielsweise einer JVM, wie sie oben erläutert ist, wirksam. Bei einem der Schritte wird eine überarbeitete erste Spezifikation vorbereitet, wobei die überarbeitete er ste Spezifikation eine Factory-Spezifikation umfaßt; die Factory ist spezifiziert, um eine Instanziierung eines Ob jekts gemäß der überarbeiteten ersten Spezifikation durchzu führen; ferner definiert die Factory-Spezifikation Factory- Instanzdaten. Bei dem anderen Schritt wird eine erste Bezug nahme auf die statischen Daten durch eine zweite Bezugnahme auf die Factory-Instanzdaten ersetzt; ferner wird jede An wendungsspezifikation vorbereitet, derart, daß ein Factory- Objekt, das gemäß der Factory-Spezifikation instanziiert ist, auf jede Anforderung für eine Instanziierung eines je weiligen Objekts der ersten überarbeiteten Spezifikation an spricht.

Die Überarbeitung der ersten Spezifikation und die Kriterien zur Überarbeitung (oder zum anfänglichen Schreiben) von An wendungsspezifikationen liefert eine gleichzeitige Anwen dungsausführung auf eine Art und Weise, die beträchtlich einfacher ist als beispielsweise eine Modifizierung der Aus führungsumgebung, um mehrere getrennte Verarbeitungsräume zu ermöglichen. Die Fähigkeit, mehrere Anwendungsprogramme durchzuführen, wird ohne Änderung der Verarbeitungsumgebung unterstützt. Wenn dieselbe auf die Spezifikationen von ob jektorientierten Programmen, die wie oben erläutert durch eine JVM auszuführen sind, angewendet wird, arbeitet die re sultierende Integration beispielsweise auf einer unmodifi zierten JVM, die für eine Einzelprozeßausführung bestimmt ist. Der Aufwand des Lieferns einer JVM für jede Anwendungs spezifikation kann vermieden werden.

Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend bezugnehmend auf die beiliegenden Zeich nungen, in denen gleiche Bezugszeichen gleiche Elemente be zeichnen, näher erläutert. Es zeigen:

Fig. 1 ein funktionelles Blockdiagramm eines Computersy stems gemäß verschiedenen Aspekten der vorliegenden Erfindung;

Fig. 2 ein Datenflußdiagramm einer Rechenumgebung, die durch das Computersystem von Fig. 1 geliefert wird;

Fig. 3 ein Datenflußdiagramm von zwei Anwendungsprogram men, die in der Umgebung von Fig. 2 arbeiten;

Fig. 4 eine Speichertabelle des Inhalts eines Speichers während eines Betriebs der zwei Anwendungsprogram me, die in Fig. 2 gezeigt sind;

Fig. 5 ein funktionelles Blockdiagramm eines Druckers ge mäß einem Ausführungsbeispiels der vorliegenden Er findung; und

Fig. 6 ein Verfahren, das durch den Drucker von Fig. 5 durchgeführt wird.

Ein Computersystem gemäß verschiedenen Aspekten der vorlie genden Erfindung erhält einen unabhängigen Betrieb mehrerer Anwendungsprogramme in einem Einzelverarbeitungsraum. Ein solches Computersystem umfaßt einen beliebigen herkömmlichen Schaltungsaufbau oder ein Netzwerk von Geräten, der oder das eine Ausführungsumgebung für ein objektorientiertes Programm liefert. Ein automatisiertes Gerät (beispielsweise ein Drucker) kann ein Teil eines solchen Computersystems sein, und kann intern ein solches Computersystem beinhalten. All gemein wird eine Ausführungsumgebung durch ein herkömmliches Betriebssystem geliefert. Zum Ausführen von Plattform-unab hängigen objektorientierten Programmen kann die Verarbei tungsumgebung durch eine herkömmliche virtuelle Maschine oder einen Interpretierer (beispielsweise eine JAVA Virtual Machine, wobei JAVA eine Marke von Sun Microsystems Inc. ist) geliefert werden. Beispielsweise kann ein Computersy stem 100 gemäß Fig. 1 oder ein Drucker 500 gemäß Fig. 5 eine Ausführungsumgebung 200 gemäß Fig. 2 liefern. Ein Computer system 100 kann eine beliebige Anzahl von Prozessoren 120, eine beliebige Anzahl von Speichern 130 und eine beliebige Anzahl von Eingabe/Ausgabe-Teilsystemen 150, die für eine Datenübertragung und eine Steuerung durch einen Bus 140 mit einander gekoppelt sind, aufweisen.

Ein Speicher gemäß verschiedenen Aspekten der vorliegenden Erfindung umfaßt Indizien von mehreren Programmspezifikatio nen und umfaßt im Betrieb Datenstrukturen zum Aufzeichnen des Zustands von Objekten, die aus den Programmspezifikatio nen instanziiert sind. Beispielsweise werden Spezifikationen in bestimmten Programmiersprachen als "Klassen" bezeichnet und können in einer oder mehreren Datenstrukturen angeordnet sein, um hierarchische Beziehungen zwischen Programmspezifi kationen zu zeigen. Physikalisch kann der Speicher 130, 518 eine beliebige Kombination herkömmlicher Datenspeicherungs- und Wiedergewinnungs-Vorrichtungen aufweisen, einschließlich beispielsweise eines Plattenspeichers oder eines Halbleiter speichers. Der Speicher kann mit einem oder mehreren Prozes soren auf einem einzelnen Substrat integriert sein, oder kann als ein Schaltungsmodul für eine geeignete Speicherung von Informationen, eine geeignete Handhabung und einen Ein bau in Computersysteme und/oder automatisierte Geräte ge häust sein. Beispielsweise kann eine JVM in einem oder meh reren physikalisch getrennten Gehäusen vorgesehen sein (bei spielsweise integrierten Schaltungssubstraten, Chipsätzen oder Modulen), wobei Anwendungsprogramme zur Ausführung durch die JVM in dem gleichen oder anderen Gehäusen vorge sehen sein können. Unterschiedliche Organisationen können ein oder mehrere Gehäuse für einen Einbau in ein Computersy stem 100 oder einen Drucker 500 durch den ursprünglichen Ge rätehersteller oder durch einen Techniker oder Benutzer am Einsatzort liefern.

Wie oben erläutert wurde, kann eine Umgebung für eine ob jektorientierte Ausführung durch einen oder mehrere Prozes soren geliefert werden, die mit Speicher in einem oder meh reren Gehäusen gekoppelt sind. Im Betrieb steuert eine sol che Umgebung das Verhalten von Programmschritten und unter stützt Programmschritte, die ein dynamisches Laden von Pro grammspezifikationen zusätzlich zu der Programmspezifika tion, die momentan durchgeführt wird, und eine dynamische Zuteilung von zusätzlichem Speicher aufrufen, und die eine Ausführung von mehr als einem Teilprozeß der Programmausfüh rung unterstützen können. Beispielsweise umfaßt die Umgebung 200 fünf zusammenarbeitende Prozesse: einen Ausführungspro zeß 202, einen Speicherverwaltungsprozeß 212, einen Teilpro zeßverwaltungsprozeß 222, einen Ladeprozeß 232 und einen Programmschritt, der den Prozeß 242 durchführt.

Ein Ausführungsprozeß umfaßt jeglichen Prozeß, der für Plattform-spezifische Verhalten verantwortlich ist, ein schließlich einer Hochfahr-Initialisierung, einer Vorrich tungs-, Bus- und Speicher-Schaltungssteuerung, Vorrich tungs-bezogener Fehlerbedingungen und Abschalt-Prozeduren. Beispielsweise umfaßt der Ausführungsprozeß 202 alle Proze duren, die notwendig sind, um eine Ausführung vorzubereiten, und um eine herkömmliche Programmspezifikation eines objekt orientierten Programms auszuführen.

Ein Speicherverwaltungsprozeß umfaßt alle Prozesse, die für das Zuteilen von Speicher, das Freimachen von zugeteiltem Speicher und eine Speicherbereinigung verantwortlich sind. Die Zuteilung umfaßt allgemein das Identifizieren eines spe ziellen Adreßbereichs eines Speichers zu einer Speicherungs deklaration einer Programmspezifikation. Ein Speicher kann für eine Speicherung von Programmspezifikationen, gemeinsam verwendeten (statischen) Variablen und/oder des Zustands ei nes Objekts zugeteilt werden. Eine Instanziierung eines Ob jekts umfaßt allgemein das Zuteilen von Speicher, der für eine Datenstruktur ausreicht, die den Zustand des Objekts beschreibt, und kann dynamisch gebundene Verknüpfungen zu Befehlen für die Objektverhalten umfassen. Die Datenstruktur für einen Objektzustand ist typischerweise in der jeweiligen Programmspezifikation beschrieben.

Ein Teilprozeß-Verwaltungsprozeß umfaßt alle Prozesse, die für das Realisieren der Ausführung von einem oder mehreren Ausführungsströmen verantwortlich sind. Abschnitte einer Programmspezifikation, die für eine Mehr-Teilprozeßverarbei tung geeignet sind, sind notwendigerweise entworfen, um ab laufinvariant zu sein. Um ablaufinvariant zu sein, darf sich ein Objekt unter anderem allgemein nicht auf Informationen beziehen, die sich nicht in der Datenstruktur zum Speichern des Zustands dieses Objekts beziehen. Diese Bedingung ist allgemein nicht erfüllt, wenn sich ein Objekt auf gemeinsam verwendete (statische) Variablen bezieht. Eine Mehr-Teilpro zeß-Verarbeitung unterscheidet sich von einer Mehr-Verarbei tung dahingehend, daß bei der Mehrverarbeitung üblicherweise die gleichen Speicheradressen durch mehr als ein Anwendungs programm verwendet werden. Daher wird während eines Prozeß umschaltens eine Kopie des Speichers typischerweise anderswo gespeichert, oder eine Änderung bezüglich der Speicheradres sierung wird durchgeführt. Ein Prozeßumschalten wird nicht durchgeführt (und kann daher aus dem Systementwurf weggelas sen werden), wenn ein Prozessor einen Einzelverarbeitungs raum verwendet. Bei einer Mehr-Teilprozeß-Verarbeitung spei chern die Objekte, die in unterschiedlichen Teilprozessen durchgeführt werden, jeweilige Zustandsinformationen nicht an den gleichen Adressen; daher kann ein Einzelverarbei tungsraum durch alle Objekte aller Teilprozesse verwendet werden.

Beispielsweise zeichnet ein Teilprozeß-Verwaltungsprozeß 222 einen Teilprozeßstatus für alle aktiven Teilprozesse in ei ner Teilprozeßtabelle 264, die auf irgendeine herkömmliche Art und Weise angeordnet ist, auf. Wenn durch den Ausfüh rungsprozeß 202 ein Teilprozeßumschalten angefordert wird, wechselt der Teilprozeß-Verwaltungsprozeß 222 Prozessorzu standsinformationen (beispielsweise den Inhalt eines inter nen Registers) bezüglich der Teilprozeßtabelle 264 und über trägt die Steuerung in geeigneter Weise zu dem nächsten Teilprozeß. Der Teilprozeß-Verwaltungsprozessor 222 kann ei ne beliebige herkömmliche Teilprozeß-Prioritätsbestimmung und Zeitablaufsteuerungsprozeduren enthalten.

Ein Ladeprozeß umfaßt alle Prozesse, die für das Kopieren zumindest eines Teils einer Programmspezifikation in den ausführbaren Speicherraum eines Prozessors und das Verfüg barmachen der geladenen Informationen für eine Bezugnahme oder eine Durchführung durch einen Programmdurchführungspro zeß verantwortlich sind. Wenn der ausführbare Speicherraum begrenzt ist, kann beispielsweise ein erster Teil einer An wendungsprogrammspezifikation anfänglich für das Beginnen einer Anwendungsprogrammausführung geladen werden (oder be findet sich in dem Speicher). Eine Bezugnahme auf einen wei teren nicht-geladenen Abschnitt der Anwendungsprogrammspezi fikation kann eine Übertragung der Steuerung von dem Pro grammdurchführungsprozeß zu einem Ladeprozeß aufrufen, um einen Speicher für zusätzliche Programmspezifikationsinfor mationen zuzuteilen, wobei eine geeignete Programmspezifi kation (teilweise oder vollständig) in den zugeteilten Spei cher kopiert wird und die geladenen Informationen für eine nachfolgende Ausführung dynamisch gebunden werden (was auch als spätes Binden oder spätes Verknüpfen bezeichnet wird). Beispielsweise arbeitet der Ladeprozeß 332 mit dem Ausfüh rungsprozeß 202 und dem Speicherverwaltungsprozeß 212 zusam men, um einen Speicher zuzuteilen, arbeitet mit dem Ausfüh rungsprozeß 202 zusammen, um Klassen von einem Sekundärspei cher (beispielsweise einem Seitenspeicher oder einem Plat tenspeicher) zu erhalten, und führt ein dynamisches Binden durch, um die geladenen Klassen in die Klassenhierarchie, die in geeigneter Weise in einer Klassentabelle 266 gespei chert ist, einzubringen. Die geladenen Klassen können in ei nem Teilbaum der Klassenhierarchie gespeichert werden. Teil bäume können für eine geordnete Bezugnahme auf Namen verwen det werden, was beispielsweise eine unzweideutige Bezugnahme auf jeden Namen von doppelten Namen in der Hierarchie ermög licht. Der Ladeprozeß 232 kann als ein vorbereitender Schritt Abschnitte der Klassentabelle 266 in einem Sekundär speicher speichern, um Speicher für eine nachfolgende Zutei lung freizumachen.

Eine Klassentabelle umfaßt jegliche Datenstruktur, die ge eignet ist, um Programmspezifikationsinformationen zu spei chern. Beispielsweise umfaßt die Klassentabelle 266 eine oder mehrere Datenstrukturen zum Beibehalten einer einzigen Klassenhierarchie, wie sie typischerweise in einer JVM ver wendet wird. Eine solche Klassenhierarchie kann, wie oben erläutert wurde, Teilbäume aufweisen.

Ein Programmierschritt-Durchführungsprozeß umfaßt alle Pro zesse, die eine Programmspezifikation ausführen oder inter pretieren, um Operationen (oder Dienste) eines Objekts durchzuführen. Jeder Objektzustand (wie er während der Aus führung der jeweiligen Programmspezifikation modifiziert wird) wird in einer jeweiligen Datenstruktur in einem Verar beitungsraum gespeichert. Wenn ein Objekt mehr als einmal instanziiert wird (beispielsweise für eine Rekursion oder mehrere Teilprozesse), wird eine Kopie der Datenstruktur zum Speichern des Objektzustands für eine exklusive Bezugnahme durch jeden Objekt-Instanz in dem Verarbeitungsraum beibe halten. Beispielsweise arbeitet der Programmschritt-Durch führungsprozeß 242 mit dem Teilprozeß-Verwaltungsprozeß 222 zusammen, um Verarbeitungszustandsinformationen zu erhalten, die einen nächsten Schritt identifizieren, der für den mo mentan aktiven Teilprozeß auszuführen ist. Dann führt der Programmschritt-Durchführungsprozeß den identifizierten Schritt (die identifizierten Schritte) mit sich ergebenden Änderungen der Instanzvariablen betroffener Objektzustände und von gemeinsam verwendeten (statischen) Variablen außer halb dieser Zustände durch. Wenn der Ausführungsstrom unter brochen wird oder endet, informiert der Programmschritt- Durchführungsprozeß 242 in geeigneter Weise den Ausführungs prozeß 202 und den Teilprozeß-Verwaltungsprozeß 222 für eine geeignete Aktion oder eine Fehlermeldung. Die Ausführung kann unterbrochen werden, bis der Ladeprozeß 232 ein dynami sches Binden weiterer Schritte, die ausgeführt werden sol len, abschließt.

Das Erhalten einer Unabhängigkeit zwischen Anwendungspro grammen in einem Einzelverarbeitungsraum wird gemäß ver schiedenen Aspekten der vorliegenden Erfindung teilweise durch eine indirekte Instanziierung jedes gemeinsam verwen deten ablaufinvarianten Objekts erreicht. Eine indirekte In stanzüerung wird aus einem Beispiel einer Sequenz von Ak tionen, die durch ein Computersystem 100, wie es in den Fig. 1 bis 4 und in Tabelle 1 gezeigt ist, durchgeführt werden, besser verständlich. In Tabelle 1 lädt der Ausführungsprozeß 202 ein erstes Anwendungsprogramm APPL_A 340 und beginnt die Ausführung desselben, und lädt nachfolgend ein zweites An wendungsprogramm APPL_B 360 und beginnt die Ausführung des selben. Die Ausführung beginnt mit einem Objekt, das einen vorbestimmten Namen aufweist, beispielsweise START, das in anderen Programmiersprachen MAIN oder ein Äquivalent dessel ben sein kann. Jedes Anwendungsprogramm instanziiert seine einzigartigen Objekte, die zur Bequemlichkeit der Darstel lung als OBJECT_A und OBJECT_B identifiziert sind. Jede An wendung nimmt dann für Dienste, die durch ein Objekt mit dem Namen FACTORY_C und ein oder mehrere Objekte mit der Be zeichnung OBJECT_C geliefert werden, Bezug auf eine Pro grammspezifikation LIBRARY_C. Bei diesem Beispiel werden al le Instanzen von FACTORY_C und OBJECT_C von der gleichen Programmspezifikation abgeleitet, obwohl das Verhalten gemäß den getrennt gehaltenen Zuständen 346, 348, 366 und 368 va riieren kann, wie in Fig. 4 gezeigt ist.

Tabelle 1

Während der Initialisierung wird die Umgebung 200 in dem Speicher 130 festgelegt. Zu diesem Zeitpunkt umfaßt der Speicher 130 eine Beschreibung der Umgebung 200, wie es durch Abschnitte in Fig. 4 dargestellt ist, die Befehle für den Ausführungsprozeß 202, Befehle für den Speicherverwal tungsprozeß 212, Befehle für den Teilprozeß-Verwaltungspro zeß 222, Befehle für den Ladeprozeß 232, Befehle für den Programmschritt-Durchführungsprozeß 242, Umgebungsvariablen 402, eine Zuteilungstabelle 262, eine Minimal-Teilprozeß-Ta belle 264, eine Minimal-Klassentabelle 266 und einen Mini malverarbeitungsraum 268 umfaßt. Bestimmte dieser Gegenstän de sind minimal, da gerade nach der Initialisierung der Aus führungsprozeß 202 noch keine Programmspezifikationen für den Betrieb geladen hat. Beispielsweise kann die Klassenta belle 266 Umgebungsklassen 404 als eine Anwendungsprogramm schnittstelle (API; API = Application Program Interface) für die Verwendung durch Anwendungsprogramme umfassen.

Es sei bemerkt, daß der relevante Inhalt des Speichers 130 in Fig. 4 ohne Bezugnahme auf physikalische Aspekte von Speicheradressen logisch beschrieben ist. Der logische Ent wurf ist für die Darstellung geeignet. Eine physikalische Speichertabelle der Funktionen der verschiedenen Adreßberei che kann tatsächlich irgendeine vermischte Konfiguration aufweisen, die für eine Verarbeitung geeignet ist. Bei spielsweise können kompilierte und verknüpfte Codeblöcke für die Befehle 202, 212, 222, 232 und 242 eine beliebige Anord nung von fragmentierten Adreßbereichen zur Folge haben; fer ner kann die Zuteilung von Adreßbereichen für die Variablen 402, die Tabellen 262, 264, 266 und den Verarbeitungsraum 268 eine beliebige Anordnung von fragmentierten Adreßräumen zur Folge haben. Der Speicher 130 kann jede Funktion (Be fehl, Block, Tabelle, usw.) mit mehreren, physikalisch nicht zusammenhängenden Bereichen unterstützen. Wenn Speicher für zusätzliche Umgebungsvariablen, Zusätze zu Tabellen und Zu sätze zu dem Verarbeitungsraum zugeteilt wird, kann bei spielsweise eine weitere Fragmentierung die Folge sein, ohne von der logischen Beschreibung, die in Fig. 4 dargestellt ist, oder den verschiedenen funktionellen Aspekten der vor liegenden Erfindung abzuweichen. Ferner kann ein physikali scher Entwurf des Inhalts des Speichers 130 die Wirkungen von Zugriffsbegrenzungen, wie bei einem segmentierten Spei cher, einem ausgedehnten Speicher, einem Speicher mit be darfsweisem Seitenabruf von einer Platte, Umlagerungstabel len (swap tables), einem gemeinsamen Speicher für parallele Prozessoren, Cache-Speichern, usw., enthalten.

Nach der Initialisierung kann die Ausführung von APPL_A und APPL_B gleichzeitig fortgesetzt werden (beispielsweise ein Mehrprogrammbetrieb durch einen einzelnen Prozessor), durch Aktionen durch den Ausführungsprozeß 202, wie sie oben be schrieben sind. Das Laden von APPL_A hat das Hinzufügen von APPL_A-Klassen 311 zu der Klassentabelle 266 und die Zutei lung des Verarbeitungsraums für den APPL_A-Zustand 340 in dem Verarbeitungsraum 268 zur Folge, wie in Fig. 4 gezeigt ist. Zu einem beliebigen Zeitpunkt, nachdem APPL-A geladen ist, lädt der Ausführungsprozeß 202 APPL_B 360. Das Laden von APPL_B hat das Hinzufügen der APPL_B-Klassen 313 zu der Klassentabelle 266 und die Zuteilung des Verarbeitungsraums für den APPL_B-Zustand 360 in dem Verarbeitungsraum 268 zur Folge. Wenn APPL_A und APPL_B unabhängig entwickelt wurden, werden die APPL_A-Klassen ausschließlich durch APPL_A ver wendet und umgekehrt. Konflikte unter gemeinsam verwendeten Identifizierern (die beispielsweise durch Duplikate in der Klassentabelle 266 bewirkt werden) können durch eine belie bige herkömmliche Technik vermieden werden, beispielsweise ein eindeutiges Identifizierer-Präfix (Dateianfangs-Eti kett).

Eine indirekte Instanziierung wird wie folgt veranschau licht. Der OBJECT_C-Zustand 348 wird wie folgt als ein Er gebnis einer indirekten Instanziierung zugeteilt. OBJECT_A 344 erhält eine Bezugnahme auf eine neue Instanz von OB- JECT_C gemäß verschiedenen Aspekten der vorliegenden Erfin dung, indem eine Meldung zu FACTORY_C geleitet wird, und nicht direkt zu OBJECT_C. FACTORY_C erzeugt ansprechend auf die Meldung eine Instanz des OBJECT_C-Zustands 348 und gibt einen Verweis auf diesen Zustand zu OBJECT_A 344 zurück.

Ein Factory-Objekt schließt jegliches Objekt ein, dessen Verhalten eine Instanziierung eines anderen Objekts eines vorbestimmten Typs umfaßt. Ein Factory-Objekt kann auch Instanzvariablen in seinem Zustand umfassen. Ein Factory-Ob jekt kann ein Einzelgegenstandobjekt im Zusammenhang mit ei nem Anwendungsprogramm sein. Durch die Verwendung eines Ein zelgegenstand-Factory-Objekts mit Instanzvariablen in seinem Zustand können mehrere Bibliotheksobjekte auf eine Art und Weise auf die Factory-Instanzvariablen verweisen, die analog zu Verweisen auf statische Bibliothekvariablen ist.

Obwohl OBJECT_A hätte entworfen werden können, um direkt OB- JECT_C zu instanziieren, wird die Verantwortung für die In stanzüerung stattdessen durch FACTORY_C getragen, wobei ei ne direkte Instanziierung von OBJECT_C durch die Entwurfs taktik verhindert ist. Auf eine gleichartige Weise kann je der Typ eines Bibliotheksobjekts, das von APPL_A benötigt wird, über das gleiche oder ein anderes Einzelgegenstand- Factory-Objekt für APPL_A indirekt instanziiert werden.

Bei einem Verfahren gemäß verschiedenen Aspekten der vorlie genden Erfindung können mehrere Anwendungsprogramme, die sich andernfalls aufgrund von nicht unabhängigen Bezugnahmen auf gemeinsam verwendete Daten falsch verhalten würden, in einer Einzelverarbeitungsumgebung ohne Konflikt ausgeführt werden. Es sei beispielsweise ein erstes Anwendungsprogramm betrachtet, das Kreise an zufälligen Positionen und mit zu fälligen Größen auf einer Anzeige zeichnet. Während jeder neue Kreis gezeichnet wird, wird die mittlere Größe aller Kreise berechnet. Es sei nun berücksichtigt, daß die Anzeige in zwei Abschnitten verwaltet werden soll; das erste Anwen dungsprogramm soll für die linke Hälfte der Anzeige verant wortlich sein, während ein zweites Anwendungsprogramm, das identisch zu dem ersten Anwendungsprogramm ist, für die rechte Hälfte der Anzeige verantwortlich sein soll. Ein un abhängiger Betrieb jedes Anwendungsprogramms soll von einer Einzelverarbeitungsumgebung geliefert werden. Beide Anwen dungsprogramme wurden ursprünglich geschrieben, um eine ge meinsame Bibliothek für ein Kreiszeichnungsobjekt zu verwen den. Ungünstigerweise umfaßt die Bibliotheksprogrammspezifi kation Anweisungen, die mehrere Variablen in einem gemeinsa men (statischen) Speicher deklarieren. Diese Variablen um fassen die momentane Anzahl von instanziierten Bibliotheks objekten und die momentane Gesamtfläche aller Graphiken, die durch die Bibliotheksobjekte gezeichnet sind. Ohne Modifika tion können das erste und das zweite Anwendungsprogramm nicht unabhängig ohne, unter anderem, unabhängige Werte die ser Variablen arbeiten. Es ist erwünscht, Änderungen bezüg lich der Anwendungsprogramme und der Bibliothek zu minimie ren, um Kosten zu sparen.

Eine Modifikation der Anwendungs- und Bibliotheks-Programm spezifikationen bei dem obigen Beispiel kann gemäß einem Verfahren der vorliegenden Erfindung durchgeführt werden, das in beliebiger Reihenfolge folgende Schritte aufweist: (a) Vorbereiten einer überarbeiteten Bibliotheks-Programm spezifikation, wobei (a.1) die überarbeitete Bibliothek eine Programmspezifikation für ein Factory-Objekt mit Factory-In stanzvariablen, wie oben beschrieben ist, enthält; und (a.2) jede Bezugnahme auf eine Variable in einem statischen Spei cher durch eine jeweilige Bezugnahme auf eine Factory-In stanzvariable ersetzt wird; und (b) Vorbereiten jeder Anwen dungsspezifikation, so daß ein Factory-Objekt entsprechend der Factory-Spezifikation instanziiert wird; wobei jede je weilige Factory in dem Zusammenhang mit dem jeweiligen An wendungsprogramm auf jede Anforderung für eine Instanziie rung eines Bibliotheksobjekts anspricht.

Bei einer Anwendung auf das Kreiszeichnungs-Anwendungspro grammbeispiel wird dieses Verfahren, wie es in Tabelle 2 veranschaulicht ist, besser verständlich. Tabelle 2 ver gleicht relevante Abschnitte von JAVA-Programmspezifikatio nen für die Bibliothek und jedes Anwendungsprogramm vor ei ner Modifikation (abhängig) und nach einer Modifikation (un abhängig).

Tabelle 2

Ein automatisiertes Gerät kann gemäß verschiedenen Aspekten der vorliegenden Erfindung ein Computersystem, wie es oben beschrieben ist, umfassen. Einige Beispiele eines solchen Gerätes umfassen Computer, Computerzubehörgeräte, Telekommu nikationsgeräte, Prozeßsteuergeräte und Meßgeräte. Bei spielsweise umfaßt ein Drucker 500 von Fig. 5 einen Prozes sor 514 und einen Speicher 518, die durch einen Bus 512 ge koppelt sind, auf eine Art und Weise, die allgemein der des Prozessors 120, des Speichers 130 und des Busses 140 von Fig. 1 entspricht. Der Drucker 500 umfaßt ferner Steuerungen und Anzeigen 516, eine I/O-Schnittstelle 510 und eine Druck maschine 520, die jeweils mit dem Bus 512 gekoppelt sind und gemeinsam allgemein Eingabe/Ausgabe-Teilsystemen 150 ent sprechen.

Der Prozessor 514 und der Speicher 518 arbeiten zusammen, um ein Verfahren 600 nach Fig. 6 durchzuführen, wobei eine Um gebung 200 in einem Schritt 604 wie oben beschrieben festge legt wird. Eine Mehr-Teilprozeß-Verarbeitung wird in einem Schritt 606 festgelegt und in einem Schritt 608 für eine gleichzeitige Durchführung (beispielsweise über einen Mehr programmbetrieb durch einen einzelnen Prozessor) von Schrit ten 610 bis 620 in vier Teilprozessen freigegeben. Wenn die Leistung abgeschaltet werden soll, springt die Steuerung zu einem Schritt 622, in dem der Zustand aller Objekte in einem nicht-flüchtigen Abschnitt des Speichers 518 zurückgehalten werden kann.

Die Funktionen des Druckers 500 sind gemäß verschiedenen As pekten der vorliegenden Erfindung erweiterbar. Beispielswei se können die Programmspezifikationen für den Schritt 612 durch Programmspezifikationen 614 ergänzt und/oder ersetzt werden. Der Schritt 612 kann eine beliebige herkömmliche Prozedur zum Verwalten einer I/O-Schnittstelle 510 und zum Verwalten von Daten in einer Seitenbeschreibungssprache (PDL; PDL = Page Description Language) enthalten. Eine PDL kann ein beliebiges Protokoll und/oder Format zum Definieren eines Bilds, das gedruckt werden soll, einschließlich einer PDL des Typs, der beispielhaft durch die Printer Control Language (PCL), die von der Hewlett Packard Company vermark tet wird, oder der Sprache POSTSCRIPT, die von Adobe Systems Incorporation vermarktet wird, gegeben ist. PCL und POST- SCRIPT sind Marken des jeweiligen Unternehmens. Im Schritt 612 können PDL-Daten, wie sie über die Schnittstelle 508 empfangen werden, verwendet werden, um Ergänzungs- oder Er setzungs-Daten bezüglich der gleichen PDL zum Drucken zu sätzlich zu den PDL-Daten, wie sie ursprünglich empfangen wurden, oder statt derselben, zu liefern.

Als ein weiteres Beispiel einer Erweiterbarkeit können die Programmspezifikationen für einen Schritt 618 durch Pro grammspezifikationen 620 ergänzt, ersetzt oder überschrieben werden. Der Schritt 618 kann jegliche herkömmliche Prozedur zum Verwalten der Formatierung von Daten, die gedruckt wer den sollen, und/oder zum Verwalten des Druckens durch eine spezielle Druckmaschine enthalten. Der Schritt 620 kann eine Unterstützung für verbesserte Bildformatierungstechniken, eine Emulierung alternativer Druckmaschinen, oder das Unter bringen einer anderen Druckmaschine, als sie durch den Schritt 618 unterstützt wird, liefern.

Die Programmspezifikationen für die Schritte 614 und/oder 620 können auf eine beliebige Art und Weise in die Umgebung 200 des Druckers 500 geladen werden, einschließlich des Emp fangs über die Schnittstelle 508, einer Übertragung von se kundären oder Seitenwechsel-Abschnitten des Speichers 518 zu primären Abschnitten desselben, oder durch eine Installation eines zusätzlichen Speichers 518 während der Herstellung oder am Einsatzort, wie oben beschrieben wurde. Wenn die Schritte 610, 612, 616 und 618 ein erstes (beispielsweise standardmäßiges, eingebautes, usw.) Anwendungsprogramm bil den, kann der Schritt 614 ein zweites Anwendungsprogramm bilden, während der Schritt 620 ein drittes Anwendungspro gramm darstellt. Gemäß den verschiedenen Aspekten der vor liegenden Erfindung, wie sie allgemein bezugnehmend auf die Fig. 1 bis 4 beschrieben wurden, können die Schritte 612 und 614 unabhängig auf eine gemeinsame Bibliothek von Objekten verweisen (beispielsweise für Fonds, Liniengraphiken, Hin tergrundbilder, eine PDL-Interpretation usw.), während die Schritte 618 und 620 unabhängig auf die gleiche oder eine andere gemeinsame Bibliothek von Objekten verweisen können (beispielsweise für eine Kantenverbesserung, eine Farbsteue rung, eine Bildverarbeitung, eine Druckmaschinensteuerung usw.). Für existierende Bibliotheks- und Anwendungspro gramm-Spezifikationen kann sich die Modifikation des Schritts 612, um den Schritt 614 aufzunehmen, und die Modi fikation des Schritts 618, um den Schritt 620 aufzunehmen, gemäß den verschiedenen Aspekten der Erfindung, die oben be schrieben sind, fortsetzen.

Claims

1. Speichervorrichtung (130) mit Indizien eines objekt orientierten Programms, wobei das Programm im Betrieb Indizien eines Zustands liefert, wobei der Zustand fol gende Merkmale aufweist:

a) eine erste Instanz (346) einer Factory, wobei die er ste Instanz eine Erste-Instanz-Variable aufweist;
b) eine zweite Instanz (366) der Factory, wobei die zweite Instanz eine Zweite-Instanz-Variable aufweist:
c) eine erste Instanz (348) eines Objekts, wobei die Erste-Instanz-Variable auf eine erste Operation aus einem ersten Satz anspricht, der aus dem Bilden der ersten Instanz des Objekts durch die erste Instanz der Factory und einer Operation des Objekts mit der ersten Instanz des Objekts besteht; und
d) eine zweite Instanz (368) des Objekts, wobei die Zweite-Instanz-Variable auf eine zweite Operation aus einem zweiten Satz anspricht, der aus dem Bilden der zweiten Instanz des Objekts durch die zweite Instanz der Factory und einer Operation des Objekts mit der zweiten Instanz des Objekts besteht, wobei
e) die Erste-Instanz-Variable unabhängig von der zweiten Operation ist.

2. Speichervorrichtung nach Anspruch 1, bei der die Indi zien des Programms Indizien einer Klassenhierarchie (266) umfassen.

3. Speichervorrichtung nach Anspruch 2, bei der die Hierar chie (266) folgende Merkmale aufweist:

a) einen ersten Teilbaum, der eine erste Spezifikation (344) aufweist, die im Betrieb die erste Instanz der Factory leitet, um die erste Instanz des Objekts zu bilden; und
b) einen zweiten Teilbaum, der eine zweite Spezifikation (364) aufweist, die im Betrieb die zweite Instanz der Factory leitet, um die zweite Instanz des Objekts zu bilden.

4. Speichervorrichtung nach Ansprüch 3, bei der die Hierar chie ferner eine Spezifikation der Factory und eine Spe zifikation des Objekts aufweist.

5. Speichervorrichtung nach einem der Ansprüche 1 bis 4, die ferner Indizien einer virtuellen Maschine zum Durch führen des Programms aufweist.

6. Speichervorrichtung nach einem der Ansprüche 1 bis 5, bei der die Indizien des Programms einen JAVA-Byte-Code aufweisen.

7. Druckervorrichtung (500) mit folgenden Merkmalen:

a) einer Druckmaschine (520);
b) einem Prozessor (514), der Daten zu der Druckmaschine (520) liefert; und
c) einer Speichervorrichtung (518) mit Indizien eines objektorientierten Programms, das durch den Prozessor ausgeführt wird, um Indizien eines Zustands zu lie fern, wobei der Zustand folgende Merkmale aufweist:
- 1. eine erste Instanz (346) einer Factory, wobei die erste Instanz eine Erste-Instanz-Variable auf weist;
- 2. eine zweite Instanz (366) der Factory, wobei die zweite Instanz eine Zweite-Instanz-Variable auf weist;
- 3. eine erste Instanz (348) eines Objekts, wobei die Erste-Instanz-Variable auf eine erste Operation aus einem ersten Satz anspricht, der aus dem Bil den der ersten Instanz des Objekts durch die er ste Instanz der Factory und einer Operation des Objekts mit der ersten Instanz des Objekts be steht; und
- 4. eine zweite Instanz (368) des Objekts, wobei die Zweite-Instanz-Variable auf eine zweite Operation aus einem zweiten Satz anspricht, der aus dem Bilden der zweiten Instanz des Objekts durch die zweite Instanz der Factory und einer Operation des Objekts mit der zweiten Instanz des Objekts besteht; wobei
- 5. die Erste-Instanz-Variable unabhängig von der zweiten Operation ist.

8. Druckervorrichtung (500) nach Anspruch 7, bei der die Indizien des Programms Indizien einer Klassenhierarchie (266) aufweisen.

9. Druckervorrichtung (500) nach Anspruch 8, bei der die Hierarchie (266) folgende Merkmale aufweist:

10. Druckervorrichtung (500) nach Anspruch 9, bei der die Hierarchie (266) ferner eine Spezifikation der Factory und eine Spezifikation des Objekts aufweist.

11. Druckervorrichtung nach Anspruch 9 oder 10, bei der die Speichervorrichtung (518) ferner folgende Merkmale auf weist:

a) ein erstes Paket, das Indizien der ersten Spezifika tion aufweist; und
b) ein zweites Paket, das Indizien der zweiten Spezifi kation aufweist.

12. Druckervorrichtung (500) nach einem der Ansprüche 9 bis 11, bei der:

a) die erste Spezifikation folgende Merkmale aufweist:
- 1. eine Schnittstellensteuerung zum Empfangen erster Daten gemäß einer Seitenbeschreibungssprache; und
- 2. einen Formatierer zum Steuern der Druckmaschine; und
b) eine zweite Spezifikation einen Modifizierer zum Lie fern zweiter Daten ansprechend auf die ersten Daten aufweist, wobei die zweiten Daten von der Schnitt stellensteuerung empfangen werden, wobei die zweiten Daten entsprechend der Seitenbeschreibungssprache zu dem Formatierer geliefert wird.

13. Druckervorrichtung (500) nach Anspruch 9, bei der:

a) die erste Spezifikation einen ersten Formatierer zum Steuern der Druckmaschine in einem ersten Betriebs modus aufweist, wobei der erste Formatierer zum Vor bereiten erster Daten für die Druckmaschine gemäß ei ner Seitenbeschreibungssprache dient; und
b) die zweite Spezifikation einen zweiten Formatierer zum Steuern der Druckmaschine in einem zweiten Be triebsmodus aufweist, wobei der zweite Formatierer zum Vorbereiten zweiter Daten für die Druckmaschine gemäß der Seitenbeschreibungssprache dient.

14. Druckervorrichtung (500) nach einem der Ansprüche 7 bis 13, bei der die Speichervorrichtung (518) ferner Indi zien einer virtuellen Maschine zum Durchführen des Pro gramms aufweist.

15. Druckervorrichtung (500) nach einem der Ansprüche 7 bis 14, bei der die Indizien des Programms einen JAVA-Byte- Code aufweisen.

16. Verfahren zum Integrieren einer ersten Spezifikation mit einer zweiten Spezifikation, wobei die erste Spezifika tion bezugnehmend auf statische Daten wirksam ist, wobei die Integration in einer Umgebung wirksam ist, wobei das Verfahren folgende Schritte aufweist:

a) Vorbereiten einer dritten Spezifikation gemäß der er sten Spezifikation, wobei die dritte Spezifikation eine Factory-Spezifikation aufweist, wobei die Fac tory zur Objekt-Instanziierung dient, wobei die Fac tory-Spezifikation Factory-Instanzdaten aufweist; und
b) Vorbereiten einer vierten Spezifikation gemäß der zweiten Spezifikation, wobei die vierte Spezifikation im Betrieb:
- 1. ein Factory-Objekt gemäß der Factory-Spezifika tion instanziiert;
- 2. eine Objekt-Instanziierung über das Factory-Ob jekt anfordert; und
- 3. bezugnehmend auf die Factory-Instanzdaten und nicht die statischen Daten wirksam ist.

17. Verfahren nach Anspruch 16, bei dem der Aufbau gemäß der Factory-Spezifikation ein Einzelgegenstand-Factory-Ob jekt liefert.

18. Verfahren nach Anspruch 16 oder 17, das ferner das Spei chern der dritten Spezifikation und der vierten Spezifi kation in einem Speicher aufweist, wobei der Speicher ein Paket aufweist.

19. Verfahren nach einem der Ansprüche 16 bis 18, das ferner das Liefern eines Zugriffs durch eine virtuelle Maschine auf die dritte Spezifikation aufweist.

20. Verfahren nach Anspruch 19, das ferner das Liefern der dritten Spezifikation in einem JAVA-Byte-Code aufweist.