-
Diese
Erfindung bezieht sich auf ein Verfahren für eine Datenkommunikation zwischen
Objekten in einem objektorientierten Programmiersystem, wie einem
objektorientierten Betriebssystem (BS).
-
Unter
jüngeren
Systemverfahren gibt es ein sogenanntes objektorientiertes Verfahren.
Bei einem System, das die Systemverfahren anwendet, sind verschiedene
Funktionen in dem System als Objekte in Module gebildet.
-
Die
WO 95/27248 , auf der der
Oberbegriff des beigefügten
Anspruchs 1 basiert, beschreibt ein objektorientiertes nachrichtbeförderndes
System zum Übertragen
von Nachrichten zwischen einer Client-Aufgabe (engl.: client task)
und einer Server-Aufgabe
(engl.: server task), das eine Objektdatenbank, eine Objektverwaltungseinheit,
eine Nachrichtenabwicklungseinheit und eine Verriegelungseinheit
aufweist. Die Objektverwaltungseinheit erzeugt ein Torobjekt (engl.:
port object) und ein oder mehrere zugeordnete Nachrichtenobjekte.
Die Nachrichtenabwicklungseinheit vergleicht eine Sendenachrichtenanfrage,
die durch eine Client-Aufgabe ausgegeben wird, mit einer Annahmefunktion
oder mit einer Empfangsnachrichtenanfrage, die durch eine Server-Aufgabe ausgegeben
wird. Ansprechend auf eine Sendenachrichtenanfrage erzeugt die Nachrichtenabwicklungseinheit
einen Sendenachrichten-Steuerblock. Ansprechend auf eine Empfangsnachrichtenanfrage
erzeugt die Nachrichtenabwicklungseinheit, wenn die Empfangsnachrichtenanfrage
mit dem Sendenachrichten-Steuerblock übereinstimmt, einen Lieferungsnachrichten-Steuerblock,
oder erzeugt einen Empfangsnachrichten-Steuerblock, wenn die Empfangsnachrichtenanfrage
mit dem Sendenachrichten-Steuerblock nicht übereinstimmt. Die Verriegelungseinheit
verriegelt ein Nachrichtenobjekt derart, dass Sendenachrichtenanfragen,
die an das Nachrichtenobjekt gerichtet sind, nicht berechtigt sind,
um mit Empfangsnachrichtenanfragen verglichen zu werden, bis das
Nachrichtenobjekt entriegelt wird. Ein objektorientiertes nachrichtbeförderndes
Verfahren weist folgende Schritte auf: Erzeugen eines Torobjekts;
Erzeugen eines Nachrichtenobjekts, das dem Torobjekt zugeordnet
ist; Erzeugen einer eindeutigen Nachrichten-ID ansprechend auf eine
Nachrichtenabwicklung, die durch eine Sendenachrichtenanfrage initialisiert
wird; Erzeugen eines Sendenachrichten-Steuerblocks; und Vergleichen
des Sendenachrichten-Steuerblocks mit einer entsprechenden Empfangsnachrichtenanfrage.
-
Zum
Realisieren der Funktionen des Systems als Ganzes hat jedes Objekt
eine Kommunikation mit einem anderen Objekt(en).
-
Im
Hinblick auf Synchronisation- oder Nachrichtenverwaltungsverfahren
kann an verschiedene Kommunikationssysteme zwischen Objekten gedacht
werden. Diese Systeme müssen
ansprechend auf verschiedene Anfragen von speziellen Anwendungen übernommen
werden. Zum Erfüllen
dieser Anfragen ist es notwendig, eine Kommunikationseinrichtung
zwischen Objekten mit Eigenschaften, die den Anwendungen zugeordnet
sind, wie Semantik, und zugeordnete Schnittstellen (Anwendungsprogrammierschnittstellen
oder APIs; API = Application Programming Interface) vorzusehen.
Die eben erörterten
APIs bedeuten unterdessen Schnittstellen, die die BS-Funktionen
verwenden, oder Schnittstellen als Programmiersystemfunktionen.
-
Auf
die Anwesenheit einer Kommunikationseinrichtung zwischen Objekten
mit Eigenschaften oder Schnittstellen wird als eine Anwesenheit
einer „Umgebung" Bezug genommen.
In einer Ausrüstung oder
einem Host kann lediglich eine Umgebung realisiert sein oder mehrere
unterschiedliche Umgebungen können
gleichzeitig realisiert sein. Vor allem ist die Kommunikation zwischen
Objekten, die in unterschiedlichen Umgebungen existieren, bei einer
Realisierung von einander entsprechenden Operationen von unterschiedlichen
Umgebungen entscheidend.
-
Es
gibt zwei wesentliche Konzepte, die die Funktionen eines Sendens
von Nachrichten zu Objekten, die in unterschiedlichen Umgebungen
existieren, einrichten. Das heißt,
- 1. das Konzept, dass Schnittstellen oder Prozeduren,
die eingerichtet sind, um Nachrichten zu einem Objekt(en), das (die)
in unterschiedlichen Umgebungen anwesend ist (sind), zu senden, sich
von denen, die bei einem Senden von Nachrichten zu einem Objekt(en),
das (die) in der gleichen Umgebung anwesend ist (sind), unterscheiden;
und
- 2. das Konzept, das die gleichen Schnittstellen oder Prozeduren,
die eingerichtet sind, um Nachrichten zu einem Objekt(en), das (die)
in unterschiedlichen Umgebungen anwesend ist (sind), zu senden,
bei einem Senden von Nachrichten zu einem Objekt(en), das (die)
in der gleichen Umgebung anwesend ist (sind), verwendet werden können.
-
Das
erstere Verfahren kann relativ leicht realisiert werden, da ein
Programmierer sich nicht über alle
Umgebungen bewusst sein muss, derart, dass Unterschiede bei den
Schnittstellen oder den Prozeduren durch Einrichten von unterschiedlichen
Funktionen abhängig
von den Unterschieden in Umgebungen getilgt sein können.
-
Eine
sogenannte Transparenz, das heißt eine
Indifferenz eines Programmcodes von unterschiedlichen Umgebungen,
ist jedoch für
Programmierer wünschenswerter.
-
Eine
Aufgabe der vorliegenden Erfindung besteht daher darin, ein Datenkommunikationsverfahren,
das ermöglicht,
dass eine Transparenz für unterschiedliche
Umgebungen für
Programmierer eingerichtet wird, zu schaffen.
-
Gemäß der vorliegenden
Erfindung ist ein Datenkommunikationsverfahren zum Realisieren der Kommunikation
zwischen einer Mehrzahl von Objekten eines objektorientierten Systems
geschaffen, dadurch gekennzeichnet, dass die Kommunikation zwischen
Objekten von jeweiligen Umgebungen stattfindet, wobei die Umgebungen
eine Kommunikationseinrichtung, die auf entweder Zukünften oder Fortsetzungen
basiert, verwenden, wobei das Verfahren folgende Schritte aufweist:
Erzeugen
von Markierungen für
jeweilige Kommunikationsnachrichten zwischen Objekten, wobei jede Markierung
die Umgebung gemäß der verwendeten Kommunikationseinrichtung
identifiziert, um eine Synchronisation einer Ausführung der
Kommunikation zwischen den Objekten, die in unterschiedlichen Umgebungen
existieren, durch die Lieferung der jeweiligen Markierungen zu steuern;
und Senden von jeweiligen Markierungen zusammen mit den Kommunikationsnachrichten.
-
Das
System kann ein Software-System sein, derart, dass eine Kommunikation
zwischen Software-Elementen mit einer Transparenz realisiert sein kann.
-
Durch
Einführen
der Markierung sind ein System, das eine Kommunikationseinrichtung
mit einer Transparenz zwischen unterschiedlichen Umgebungen realisiert
hat, und ein System zur Realisierung desselben realisiert. Gemäß der vorliegenden Erfindung
wird eine Kommunikation möglich,
selbst wenn sich ein Gegenstand, der zum Steuern der Synchronisation
oder der Parallelität
der Kommunikation zwischen Objekten, die einer Kommunikationseinrichtung
eigen ist, notwendig ist, von Umgebungen ohne die Notwendigkeit,
dass sich die Objekte, die in den unterschiedlichen Umgebungen anwesend
sind, der Unterschiede bewusst werden, unterscheidet.
-
Durch
Einführen
der Markierung zum Steuern der Synchronisation oder der Parallelität der Kommunikation
zwischen Objekten, die der Kommunikationseinrichtung mit unterschiedlichen
Eigenschaften oder Schnittstellen eigen ist, kann insbesondere die
Kommunikation zwischen Objekten zwischen unterschiedlichen Umgebungen
mit einer Transparenz ohne Weiteres realisiert werden.
-
KURZE BESCHREIBUNG DER ZEICHNUNGEN
-
1 ist
ein Blockschaltungsdiagramm, das eine schematische Struktur einer
VCR-Vorrichtung zeigt,
die auf ein Datenkommunikationsverfahren, das die vorliegende Erfindung
ausführt,
angewendet ist.
-
2 stellt
die Art und Weise einer Kommunikation durch eine VCR-Vorrichtung,
die die vorliegende Erfindung ausführt, ein BS für eine Kommunikation,
ein BS für
ein AV und eine API dar.
-
3 stellt
eine Metaraum-(mLokal-)Kommunikationseinrichtung (bei einem Fall,
bei dem ein WartenAuf vor einer Antwort ausgeführt wird) dar.
-
4 stellt
eine Metaraum-(mLokal-)Kommunikationseinrichtung (bei einem Fall,
bei dem eine Antwort vor einem WartenAuf ausgeführt wird) dar.
-
5 stellt
die Art und Weise einer Kommunikation der Anwendungssoftware mit
Versenderobjekten oder Zeitplanerobjekten über eine API dar.
-
6 stellt
Zukunfts-Attribute dar.
-
7 stellt
eine Metaraum-(mAnsteuer-)Kommunikationseinrichtung dar.
-
8 stellt
Attribute einer Fortsetzung dar.
-
9 stellt
den Fluss einer Prozedur der Beziehung zwischen dem Metaobjekt (mLokalerVersender)
und dem Zeitplaner (für
eine Realisierung eines Sendens in einem Metaraum (mLokal)) dar.
-
10 stellt
den Fluss einer Prozedur der Beziehung zwischen dem Metaobjekt (mLokalerVersender)
und dem Zeitplaner (für
eine Realisierung einer Antwort in einem Metaraum (mLokal)) dar.
-
11 stellt
den Fluss einer Prozedur der Beziehung zwischen dem Metaobjekt (mLokalerVersender)
und dem Zeitplaner (bei einem Fall, bei dem eine Antwort vor einem
WartenAuf in einem WartenAuf in dem Metaraum (mLokal) ausgeführt wird)
dar.
-
12 stellt
den Fluss einer Prozedur der Beziehung zwischen dem Metaobjekt (mLokalerVersender)
und dem Zeitplaner (bei einem Fall, bei dem ein WartenAuf vor einer
Antwort in einem WartenAuf in dem Metaraum (mLokal) ausgeführt wird)
dar.
-
13 stellt
eine Nachrichtenwarteschlange dar.
-
14 stellt
den Fluss einer Prozedur eines Sendens in einem Metaobjekt (MAnsteuerVersender) dar.
-
15 stellt
den Fluss einer Prozedur eines Startens in einem Metaobjekt (MAnsteuerVersender) dar.
-
16 stellt
den Fluss einer Prozedur dar, die aufgerufen wird, wenn ein Basisobjekt
in einem Metaraum (mAnsteuer) zu der Zeit einer Beendigung (Ausstieg)
des Metaobjekts (MAnsteuerVersender) ein Verarbeiten beendet.
-
17 stellt
den Fluss eines Verarbeitens der Prozedur, die bei einem Fall eines
Senden des Metaobjekts (MAnsteuerVersender) in einer Tabelle einer
verzögerten
Ausführung
(VerzögerungsAusführungsTabelle)
registriert wird, dar.
-
18 stellt
den Fluss eines Verarbeitens der Prozedur, die bei einem Fall eines
Anstoßes
des Metaobjekts (MAnsteuerVersender) in einer Tabelle einer verzögerten Ausführung (VerzögerungsAusführungsTabelle)
registriert wird, dar.
-
19 stellt
die Struktur einer MetaNachricht dar.
-
20 stellt
die Operation bei einem Fall einer Unterbrechung eines Objekts II
während
einer Ausführung
eines Basisobjekts I dar.
-
21 stellt
die Beziehung zwischen einer Markierung, einer Zukunft und einer
Fortsetzung und dieselbe zwischen einer Markierung (Markierung) und
der Markierungs-ID (MID) durch ein Objektmodell des OMT-Verfahrens
dar.
-
22 stellt
den Fluss eines Vorwärtsweges bei
einem Fall einer Kommunikation zwischen unterschiedlichen Metaräumen über ein
Objekt (einen Lieferanten) (bei einem Fall einer Kommunikation von dem
Metaraum (mLokal) zu einem Metaraum (mAnsteuer)) dar.
-
23 stellt
den Fluss eines Rückwärts- oder
Rückweges
bei einem Fall einer Kommunikation zwischen unterschiedlichen Metaräumen über ein Objekt
(einen Lieferanten) (bei einem Fall einer Kommunikation von dem
Metaraum (mLokal) zu dem Metaraum (mAnsteuer)) dar.
-
24 stellt
den Fluss eines Vorwärtsweges bei
einem Fall einer Kommunikation zwischen unterschiedlichen Metaräumen über ein
Objekt (einen Lieferanten) (bei einem Fall einer Kommunikation von dem
Metaraum (mAnsteuer) zu dem Metaraum (mLokal)) dar.
-
25 stellt
den Fluss eines Rückwärts- oder
Rückweges
bei einem Fall einer Kommunikation zwischen unterschiedlichen Metaräumen über ein Objekt
(einen Lieferanten) (bei einem Fall einer Kommunikation von dem
Metaraum (mAnsteuer) zu einem Metaraum (mLokal)) dar.
-
26 stellt
ein Beispiel eines Systems zum Verifizieren von Markierungstypen
durch die Markierungs-ID dar.
-
27 stellt
ein OMT, das Markierungsattribute in dieser Markierungs-ID (MID)
umfasst, dar.
-
28 zeigt
ein Statusübergangsdiagramm eines
Programmfadens.
-
BESCHREIBUNG DES BEVORZUGTEN
AUSFÜHRUNGSBEISPIELS
-
Bezug
nehmend auf die Zeichnungen ist ein bevorzugtes Ausführungsbeispiel
der vorliegenden Erfindung detailliert erklärt.
-
Das
Datenkommunikationsverfahren, das die vorliegende Erfindung ausführt, kann
auf ein Software-System, das fähig
ist, mehrere unterschiedliche Umgebungen zu realisieren, angewendet
sein. Bei dem Ausführungsbeispiel
der vorliegenden Erfindung ist auf jede Umgebung als ein Metaraum
Bezug genommen. Bei dem Ausführungsbeispiel
der vorliegenden Erfindung können
Metaräume
unterschiedliche „Umgebungen" in Verbindung mit
anderen Funktionen als die Kommunikationseinrichtung zwischen Objekten
einrichten. Ein Beispiel eines Software-Systems, das fähig ist,
die im Vorhergehenden erwähnten
unterschiedlichen Umgebungen zu realisieren, ist das Datenverarbeitungsverfahren
und die Datenverarbeitungsvorrichtung, die in der
japanischen Patentanmeldung 8-67881 beschrieben
sind. Das Datenverarbeitungsverfahren wird durch ein Datenverarbeitungssystem
ausgeführt,
das ein Anwendungsprogramm, das durch eine Mehrzahl von Objekten
gebildet ist, eine Ausführungsumgebung,
die den Betrieb des Anwendungsprogramms, das durch die Mehrzahl
von Objekten gebildet ist, vorschreibt, einen Server mit einer Anwendungsprogrammschnittstelle,
die die Schnittstelle zwischen dem Anwendungsprogramm und der Ausführungsumgebung vorschreibt,
und einen Client, der das Anwendungsprogramm von dem Server herunterlädt, umfasst.
Bei einem Herunterladen des Anwendungsprogramms in den Client prüft der Server,
ob der Client die Ausführungsumgebung
für das
heruntergeladene Anwendungsprogramm hat oder nicht, und spricht
auf die Resultate dieser Prüfungen,
um das Programm in den Client herunterzuladen, an.
-
1 zeigt
ein Beispiel einer Vorrichtungsstruktur zum Ausführen des Datenkommunikationsverfahrens,
das die vorliegende Erfindung ausführt.
-
Die
Vorrichtung von 1 ist ein Videokassettenrekorder
(eine VCR-Vorrichtung) zum Aufzeichnen/Wiedergeben von Signalen
unter Verwendung einer Videokassette, die eine Kassette und ein Videoband,
das in derselben gehaust ist, aufweist. Die vorliegende Erfindung
kann selbstverständlich auf
eine andere audiovisuelle Ausrüstung
(AV-Ausrüstung)
als die VCR-Vorrichtung, Büroausrüstungen oder
auf eine Computervorrichtung allgemein angewendet sein.
-
Bei
der VCR-Vorrichtung von 1 hat eine VCR-Funktionseinheit 14 die
Hauptfunktionen eines Videokassettenrekorders zum Aufzeichnen/Wiedergeben
von Daten unter Verwendung der Videokassette. Die Daten, die durch
die VCR-Funktionseinheit 14 auf
der Videokassette aufgezeichnet/wiedergegeben werden, werden über eine
Bus-/IO-Brücke 15 zu anderen
Komponenten der Vorrichtung gesendet und werden ferner über einen
Anschluss 23 nach außen ausgesendet.
Die Zentralverarbeitunsgeinheit (engl.: Central Processing Unit;
CPU) 12 ist eine Steuerung, die über eine Bus-/Speicher-Brücke 13 verschiedene Teile
steuert. Ein Direktzugriffspeicher (engl.: Random Access Memory;
RAM) 10 hat eine kleinere Kapazität und hat einen Arbeitsbereich.
In einem Nur-Lese-Speicher (engl.: Read-Only Memory; ROM) 11 ist
ein Programm betreffend die Basisfunktionen und ein Programm für das BS,
wie es so bei der vorliegenden Erfindung bezeichnet ist, gespeichert
sind. Das heißt,
die CPU 12 steuert verschiedene Teile basierend auf dem
Programm, das in dem ROM 11 gespeichert ist, und verwendet
den RAM 10 als einen Arbeitsbereich.
-
Das
IC-Kartenlaufwerk 16 hat einen Schlitz, in den eine IC-Karte
als ein Aufzeichnungsmedium mit einer integrierten Schaltung (engl.:
Integrated Circuit; IC) in einem kartenförmigen Gehäuse eingeführt wird, und eine IC-Karten-Ansteuereinheit
zum Schreiben/Lesen von Daten auf oder von der IC-Karte. Ein Laufwerk
für eine
flexible Platte umfasst eine Drehantriebseinheit zum drehenden Antreiben
der flexiblen Platte und eine Kopfeinheit zum Aufzeichnen/Wiedergeben
von Daten auf oder von der flexiblen Platte. Das Laufwerk 17 für eine flexible
Platte (engl.: floppy disc) ist für ein Aufzeichnen von verschiedenen
Daten und eine Installation einer Anwendungssoftware verantwortlich.
Das Festplattenlaufwerk 18 umfasst eine Drehantriebseinheit
zum drehenden Antreiben der Festplatte und einen Kopf zum Aufzeichnen/Wiedergeben
von Daten auf oder von der Festplatte. Ein Busschlitz 19 ist
ein Erweiterungsanschluss zum Hinzufügen einer Erweiterungsplatine,
während
ein serielles Tor 20 ein Eingang/Ausgang zum Vorsehen einer
Datenkommunikation mit dem Äußeren über ein
MODEM ist.
-
Die
VCR-Vorrichtung ist entworfen, um eine zusätzliche Anwendungssoftware
zusätzlich
zu den üblichen
VCR-Funktionen zu geben. Wenn beispielsweise ein Benutzer beabsichtigt,
die Version zu erweitern, das heißt der VCR-Vorrichtung neue
Funktionen hinzuzufügen,
können
zusätzliche
Funktionseinheiten über
eine IC-karte, eine flexible Platte oder ein Netz, wie das Internet,
installiert werden. Dies gestattet dem Benutzer, die Vorrichtungsfunktion
zu erweitern, ohne ein Hauptkörper-Bauglied
der VCR-Vorrichtung neu zu erwerben. Das Anwendungsprogramm wird
durch den Programmierer vorbereitet, um dem Benutzer zugeführt zu werden.
Es wird angenommen, dass die vorhergehende Software durch eine sogenannte
objektorientierte Programmier-Software aufgebaut wird.
-
Bei
dem vorhergehenden Fall ist gelegentlich eine Kommunikation zwischen
mehreren unterschiedlichen Umgebungen (Metaräumen) erforderlich.
-
Bezug
nehmend auf 2 sind die Anwendungssoftwareelemente,
die über
ein MODEM und ein serielles Tor von außen gesendet werden, in einer Umgebung
(einem Metaraum) platziert, die sich von der Anwendungssoftware,
die in der VCR-Vorrichtung
von Anfang an anwesend ist, unterscheidet. Diese Anwendungssoftware-Elemente können über ein Kommunikation-BS
(einen Metaraum (mLokal) oder einen Metaraum (mAnsteuer), wie im
Folgenden erklärt
ist), ein BS für
ein AV und eine API (Senden oder Antwort, wie im Folgenden erklärt ist)
miteinander kommunizieren.
-
Zu erklärende Themen
-
Zuerst
ist ein Fall erklärt,
bei dem die „zwei spezifizierten
Beispiele der unterschiedlichen Kommunikationseinrichtungen", die im Vorhergehenden beschrieben
sind, mit dem Datenkommunikationsverfahren der vorliegenden Erfindung
realisiert wurden. Die vorliegenden Beispiele sind auf einen Metaraum
(mLokal), der eine Kommunikationssemantik (Eigenschaften oder eine
Struktur von Bedeutungen) realisiert hat, die einen Gegenstand verwendet,
der als eine Zukunft bezeichnet ist, und einen Metaraum (mAnsteuer),
der eine Kommunikationssemantik realisiert hat, die einen Gegenstand
verwendet, der als eine Fortsetzung bezeichnet ist, gerichtet.
-
Bei
dem vorliegenden Ausführungsbeispiel sind
die im Vorhergehenden erwähnten „spezifizierten
Beispiele der unterschiedlichen Kommunikationseinrichtungen" in der Folge von
„Metaraum-(mLokal-)Kommunikationseinrichtung";
„Metaraum-(mAnsteuer-)Kommunikationseinrichtung";
„Vergleich
zwischen einer Metaraum-(mLokal-)Kommunikationseinrichtung und einer
Metaraum-(mAnsteuer-)Kommunikationseinrichtung";
„System zum Realisieren der
Kommunikationseinrichtung bei dem erfinderischen Verfahren";
„System
zum Realisieren einer Zukunft und einer Metaraum-(mLokal-)Kommunikationseinrichtung” und
„System
zum Realisieren einer Fortsetzung und einer Metaraum-(mAnsteuer-)Kommunikationseinrichtung"
erklärt.
-
Als
Nächstes
ist die „Basiserklärung der Kommunikationseinrichtung,
die eine Markierung verwendet," vorgenommen.
Der Metaraum (mLokal) und der Metaraum (mAnsteuer) sind hier wieder
als Beispiele genommen. Der Metaraum (mLokal) und der Metaraum (mAnsteuer)
können
unterdessen als ein BS oder ein Programmiersystem begriffen werden.
Bei dem vorliegenden Ausführungsbeispiel
sind, indem die vorhergehende „Basiserklärung der
Kommunikationseinrichtung, die die Markierung verwendet," angegeben wird,
ein
Fall, bei dem ein Objekt A, Verfahren (A::A1), ein Senden und ein
Warten-Auf (Senden + WartenAuf) an dem Objekt B, Verfahren B1 (B::B1),
durchführt, und
ein
Fall, bei dem das Objekt B, Verfahren B1 (B::B1), ein Senden an
dem Objekt A, Verfahren (A::A1), durchführt und das Objekt B, Verfahren
B2 (B::B2), als ein Fortsetzungsverfahren bestimmt,
in dieser
Reihenfolge erklärt.
-
Ein
Fall eines Realisierens der Kommunikationseinrichtung bei dem Verfahren
der vorliegenden Erfindung ist dann detailliert erklärt. Bei
dem vorliegenden Ausführungsbeispiel
ist der „Fall
eines Realisierens der Kommunikationseinrichtung, die eine Markierung
verwendet, bei dem Verfahren der vorliegenden Erfindung" in der Reihenfolge
von
„Zukunft,
Fortsetzung und Markierung";
„Ein System
zum Verwalten einer Markierungs-ID und eines Objekts, das die Markierungs-ID
liefert (eines Lieferanten)";
und
„Tatsächliche
Kommunikation zwischen unterschiedlichen Metaräumen"
erklärt.
-
Schließlich sind „andere
denkbare Systeme, die sich in unbedeutender Hinsicht unterscheiden,” erklärt. Bei
dem vorliegenden Ausführungsbeispiel sind
diese „anderen
denkbaren Systeme" in
der Reihenfolge „eines
Systems eines Erkennens des Markierungstyps durch die Markierungs-ID"; und „eines Markierungsverwaltungssystems" erklärt.
-
„Spezifizierte
Beispiele von unterschiedlichen Kommunikationseinrichtungen"
-
Diese
Beispiele bei dem Verfahren der vorliegenden Erfindung sind nun
erklärt.
-
In
dem vorliegenden Kapitel sind als die „spezifizierten Beispiele
von unterschiedlichen Kommunikationseinrichtungen" spezifizierte Entwurfsanweisungen
und das System für
eine Realisierung der Kommunikation zwischen unterschiedlichen Objekten
bei dem Datenkommunikationsverfahren der vorliegenden Erfindung
erklärt.
Bei einem spezifizierten Beispiel der vorliegenden Erfindung, das
auf das vorliegende Kapitel folgt, ist das System zum Realisieren
der Kommunikation zwischen Objekten zwischen zwei unterschiedlichen
Umgebungen (die die Kommunikationseinrichtung einrichten), die in
dem vorliegenden Kapitel erörtert
sind, erklärt.
-
„Metraraum-(mLokal-)Kommunikationseinrichtung"
-
Der
Metaraum (mLokal) ist eine Umgebung und unterstützt die Kommunikationseinrichtung,
die auf einer Zukunft (Zukunft) (Kommunikationseinrichtung zwischen
Objekten) basiert. Dieser Metaraum (mLokal) beschriebt die Anwendung.
Von den Entwurfsanweisungen der Metaraum-(mLokal-)Kommunikationseinrichtung
ist im Folgenden die Schnittstelle erklärt.
-
Der
Basisbetrieb der Kommunikation zwischen Objekten ist hierin erörtert. Das
System zum Realisieren dieser Kommunikationseinrichtung und die
in der Erklärung
verwendeten Attribute einer Zukunft sind anschließend erklärt.
-
3 und 4 stellen
den Basisbetrieb einer Kommunikation zwischen Objekten, die die
Metaraum-(mLokal-)Kommunikationseinrichtung verwendet, dar. 3 zeigt
einen Fall, bei dem in der mLokal-Metaraum-Kommunikationseinrichtung
ein WartenAuf vor einer Antwort ausgeführt wurde, während 4 einen
Fall zeigt, bei dem in der mLokal-Metaraum-Kommunikationseinrichtung
eine Antwort vor einem WartenAuf ausgeführt wurde. In diesen Figuren
geben A, B Objekte an, und A::A1 und B::B1 geben ein Verfahren A1
des Objekts A beziehungsweise ein Verfahren B1 des Objekts B an.
Vertikale Volllinienpfeile geben eine Ausführung der Verfahren an, vertikale
Strichlinienpfeile geben Wartezustände der Verfahren an, und schräge Volllinienpfeile geben
eine Nachrichtenlieferung an. Ein WartenAuf ist unterdessen eine
der APIs (Anwendungsprogrammschnittstellen) in dem Metaraum mLokal
und wird für
einen Fall, bei dem das Objekt A auf das Resultat des Objekts B
wartet, verwendet. Bei einem WartenAuf sind als Argumente eine Zukunfts-ID,
eine Antwortnachricht (&Nrt),
die von der Antwort (Antwort) gesendet wird, und ihre Größe (Größevon(Nrt)) vorgesehen.
Die Antwort (Antwort) ist eine der APIs in dem Metaraum mLokal und
wird bei dem vorliegenden Ausführungsbeispiel
für das
Objekt B verwendet, um ein Ansprechen auf das Objekt A durchzuführen. In
einer Antwort ist als ein Argument die Antwortnachricht (Nrt), die
als das Resultat einer Ausführung
des Verfahrens B1 erhalten wird, und ihre Größe (Größevon(Nrt)) vorgesehen.
-
In 3 und 4 sendet
das Objekt A eine Nachricht zu dem Objekt B und empfangt eine Antwort
von demselben. Das Objekt A sendet zuerst unter Verwendung eines
Senden eine Nachricht zu dem Objekt B. Das Verfahren B1 (B::B1)
ist ein Verfahren, das dadurch gestartet wird. In der Zeichnung
ist eine Nrt eine gelieferte Nachricht, genauer gesagt, ihr Zeiger.
Dies startet das Verfahren B1 (B::B1). Die Verfahren A::A1 und B::B1
sind parallel in Betrieb. Es ist nicht sicher, welches/welcher von
einem WartenAuf des Verfahrens A1 (A::A1) und einer Antwort des
Verfahrens B1 (B::B1) zuerst ausgeführt wird. Ein Senden ist eine
der APIs in dem mLokal-Metaraum
und wird bei dem momentanen Ausführungsbeispiel
zum Senden einer Post verwendet. In einem Senden sind als Argumente
eine Adresse (B), ein Auswahlverfahren (B1), eine Nachricht (Nrt)
und ihre Größe (Größevon(Nrt))
und eine Zukunfts-ID (ZukunftsID) vorgesehen.
-
Wenn
das Objekt A eine Nachricht zu dem Objekt B sendet, empfangt das
Objekt A eine Zukunfts-ID (ZukunftsID). Die ZukunftsID ist eine
ID, die einem Gegenstand entspricht, der als eine Zukunft bezeichnet
ist und der in dem Betriebssystem (BS), das eine Nachricht liefert,
intern erzeugt wird. Die Bezeichnung „Erzeugen" bedeutet Sichern eines Speicherbereichs,
der für
Attribute, die ein Objekt bilden, notwendig ist, und Initialisieren
des Attributs. Bezug nehmend auf 5 ist die
Anwendungssoftware angepasst, um über eine API mit einem Versenderobjekt
(beispielsweise einem Objekt eines Metaobjekts, das mLokalerVersender
genannt ist, wie im Folgenden erklärt ist, oder einem Objekt eines
Zeitplaners, ähnlich
im Folgenden erklärt)
zu kommunizieren. Der Versender wird basierend auf dem Ausführungscode
in dem Objekt durch die CPU ausgeführt. Die CPU sichert einen
Speicherbereich, der für eine
Zukunft in dem BS-Bereich erforderlich ist. Wenn das Objekt A später eine
Antwort auf die Lieferung der Nachricht empfangt, wird die Zukunfts-ID (ZukunftsID)
zum Identifizieren, welche Nachrichtensendung der empfangenen Antwortnachricht
zugeordnet ist, verwendet.
-
6 zeigt
die Attribute einer Zukunft. Diese Attribute umfassen eine ID zum
Spezifizieren des Objekts, das eine Zukunft erzeugt hat (des ProgrammfadenID-Erzeugers), eine
Flag zum Prüfen,
ob eine Antwort gegeben wurde oder nicht (Bool istAntwortGegeben),
und einen Bereich zum Aufbewahren einer Antwortnachricht (Leerraum·AntwortNachricht). Bei
den Beispielen von 3 und 4 ist das
Objekt A in der ID (dem ProgrammfadenID-Erzeuger) aufbewahrt, und
die Nachricht (Nrt) von einem Objekt B ist in der Antwortnachricht
(Leerraum* AntwortNachricht) aufbewahrt.
-
3 zeigt
einen Fall, bei dem ein WartenAuf vor einer Antwort ausgeführt wurde.
Bei diesem Fall ist eine ZukunftsID als ein Argument eines WartenAuf
angegeben. Da das Verarbeiten eines Verfahrens B1, das auf eine
bestimmte ZukunftsID antworten muss, nicht durchgeführt wurde,
befindet sich eine Ausführung
des Verfahrens A1 (A::A1) in dem Bereitschaftszustand. Während dieser
Zeit fährt
das Verfahren B1 (B::B1) mit einem Verarbeiten fort. Das Verfahren
B1 führt
eine Antwort aus, wenn dasselbe die Prozedur zum Geben einer Antwort
nimmt. Wenn eine Antwort ausgeführt
wird, wird der Zustand einer Zukunft, die bei einem Starten des
Verfahrens B1 (B::B1) durch das BS erzeugt wird, beobachtet. Da das
BS einschließen
kann, dass es ein Verfahren in dem Bereitschaftszustand für eine Zukunft
gibt, wird das Verfahren A1 (A::A1) wieder in den Ausführzustand
versetzt. Die Verfahren A1 (A::A1) und B1 (B::B1) sind wieder parallel
in Betrieb.
-
4 zeigt
einen Fall, bei dem eine Antwort vor einem WartenAuf ausgeführt wird.
Wenn eine Antwort ausgeführt
wird, wird der Zustand einer Zukunft, die erzeugt wird, wenn das
Verfahren B1 (B::B1) durch das BS gestartet wird, beobachtet. Da das
BS umfassen kann, dass sich der Sender der Nachricht, die einer
Zukunft (hierin dem Objekt A) entspricht, noch nicht in dem Bereitschaftszustand befindet,
fügt das
BS ein Zeichen für
eine Zukunft bei, dass eine Antwort gegeben wurde. Das Verfahren
B1 (B::B1) fährt
mit einem Ausführen
des verbleibenden Anschnitts fort. Benötigt das Verfahren A1 (A::A1)
die Antwort von dem Verfahren B1 (B::B1), gibt das Verfahren A1
(A::A1) eine ZukunftsID als ein Argument eines WartenAuf an. Da
ein Verarbeiten zum Geben einer Antwort zu einer bestimmten ZukunftsID
bereits durchgeführt
wurde, kann das Verfahren A1 (A::A1) seine Ausführung fortsetzen.
-
Auf
diese Art und Weise führt
eine Zukunft die Rolle eines Vermittlers zum Synchronisieren von zwei
Objekten, die parallel in Betrieb sind, durch. Da es in den Entwurfsanweisungen
der mLokal-Metaraum-Kommunikationseinrichtung für die Nachrichtensendeseite
notwendig ist, zu klären,
für welche Nachricht
die Antwort erwartet wird, wird eine Zukunft durch eine ZukunftsID
identifiziert. Der Nachrichtenempfänger ist so angeordnet, dass
derselbe sich nicht bewusst sein muss, für welchen Sender seine Antwort
bestimmt ist. Eine Zukunfts-ID manifestiert sich daher in keiner
genau festgesetzten Form.
-
„Metarraum-(mAnsteuer-)Kommunikationseinrichtung"
-
Der
Metaraum mAnsteuer ist eine Umgebung, die die Kommunikationseinrichtung,
die auf einer Fortsetzung basiert, unterstützt. Dieser Metaraum beschreibt
einen Gerätetreiber.
-
Der
Basisbetrieb der Kommunikation zwischen Objekten, die die mAnsteuer-Metaraum-Kommunikationseinrichtung
verwendet, ist hier erklärt. Das
System zum Realisieren dieser Kommunikationseinrichtung und die
Attribute oder der Statusübergang,
der für
die Fortsetzung geeignet ist, die in der Erklärung verwendet wird, sind anschließend detailliert
erklärt.
-
7 zeigt
den Basisbetrieb der Kommunikation zwischen Objekten, die in der
mAnsteuer-Metaraum-Kommunikationseinrichtung verwendet wird. Wie
in 3 und 4 geben A, B Objekte an, A::A1,
A::A2 und B::B1 geben Verfahren A1, A2 und B1 des Objekts A und
des Objekts B an, ein vertikaler Volllinienpfeil gibt eine Ausführung eines
Verfahrens an, und ein schräger
Volllinienpfeil gibt eine Nachrichtenlieferung an.
-
Das
Objekt A sendet unter Verwendung des Sendens eine Nachricht zu dem
Objekt B. Bei dem Beispiel von 7 liefert
das Objekt A die Nachricht (Nrt) zu dem Verfahren B1 (B::B1) des
Objekts B. Das Objekt A gibt zu dieser Zeit ein ununterbrochenes
Verfahren A2 (A::A2) und eine ununterbrochene Nachricht (UnunterbrNrt))
zu dem Senden als ein fünftes
beziehungsweise ein sechstes Argument ab. Das Verfahren (A::A2)
ist zu dieser Zeit ein Verfahren eines Empfangen einer Antwort von
dem Verfahren (B::B1) für
eine Ausführung
nach dem Ende des Verarbeiten des Verfahrens A1 (A::A1). Die Nachricht (UnunterbrNrt))
ist eine Nachricht, die ein Verarbeiten des ununterbrochenen Verfahrens
A2 (A::A2) unterstützt,
und ist eine Nachricht, die den Inhalt, der durch das Verfahren
A1 (A::A1) zu dem ununterbrochenen Verfahren A2 (A::A2) geliefert
wird, enthält.
-
Das
BS erzeugt intern einen Gegenstand, der als eine Fortsetzung bezeichnet
ist, der ein ununterbrochenes Verfahren und eine ununterbrochene Nachricht
enthält.
Durch Erzeugen einer Fortsetzung hier ist, wie bei dem Fall einer
Zukunft, der unter Bezugnahme auf 5 erklärt ist,
ein Bereich, der für eine
Fortsetzung notwendig ist, in dem Speicher gesichert, indem das
Versenderobjekt, wie das Metaobjekt, mAnsteuerVersender, das anschließend erklärt wird,
ausgeführt
wird.
-
8 zeigt
die Attribute einer Fortsetzung. Eine Fortsetzung definiert die
Bereiche zum Speichern der ID (des ProgrammfadenID-Erzeugers), die das
Objekt spezifiziert, das die Fortsetzung erzeugt hat, des ununterbrochenen
Verfahrens (Wählerverfahren)
und der ununterbrochenen Nachricht (Leerraum·Nachricht). Wenn das Objekt
A, das Verfahren A::A2 und die Nachricht (UnunterbrNrt)) bei dem
Beispiel von 7 durch das Senden gesendet
werden, erzeugt das BS eine Fortsetzung mit dem Objekt A, das Verfahren
A::A2 und die Nachricht (UnunterbrNrt)), die in der ID (dem ProgrammfadenID-Erzeuger)
gespeichert sind, ein ununterbrochenes Verfahren (ein Wähler-Verfahren)
beziehungsweise eine ununterbrochene Nachricht (Leerraum·Nachricht).
-
Das
Verfahren B1 (B::B1) empfängt
zusätzlich
zu dem Inhalt der Nachricht, die von dem Verfahren A1 (A::A1) geliefert
wird, die Fortsetzungs-ID (FortID), die durch das BS erzeugt wird,
als die ID, die die Fortsetzung spezifiziert. Bei dem Beispiel von 7 empfangt
das Verfahren B1 (B::B1) die ID als eine FortID. Diese Fortsetzungs-ID
(FortID) wird als ein Argument eines Anstoßens (engl.: Kick) verwendet.
Ein Anstoßen
ist eine der APIs in dem Metaraum mAnsteuer. Bei dem vorliegenden
Ausführungsbeispiel
wird diese Fortsetzungs-ID (FortID) zu dem Objekt A gesendet, um
die Informationen des Inhalts der Fortsetzung zu erhalten. Ein Anstoßen hat
als sein Argument die im Vorhergehenden erwähnte Fortsetzungs-ID (FortID).
Durch Anstoßen
der Fortsetzung kann das Objekt des Metaraums mAnsteuer unbewusst
das ununterbrochene Verfahren starten, ohne sich der in einer Fortsetzung
enthaltenen Information bewusst zu werden. Bei dem Beispiel von 7 stößt das Verfahren
B1 (B::B1) selbst die empfangene FortsetzungsID (FortID) an, wodurch
das ununterbrochene Verfahren A2 (A::A2), das durch das Verfahren
A1 (A::A1) bestimmt ist, bei der Übergabe der Resultate des Verfahrens
B1 (B::B1) und der ununterbrochenen Nachricht (UnunterbrNrt)) gestartet wird.
-
Auf
diese Art und Weise kann die Fortsetzung das ununterbrochene Verfahren
ohne die Notwendigkeit, dass sich das Objekt, das die Anfangsnachricht
empfangt, bewusst sein muss, wer diese Nachricht gesendet hat oder
zu wem die Antwort gesendet wird (die Antwort kann zu dieser Zeit
gesendet werden), starten. In den Entwurfsanweisungen der mAnsteuer-Metaraum-Kommunikationseinrichtung
manifestiert sich, da das BS die Fortsetzungs-ID (FortID) zusammen
mit der Nachricht zu der Nachrichtenempfangsseite sendet, die Fortsetzungs-ID (FortID)
auf der Sendeseite nicht.
-
Vergleich einer Metaraum-(mLokal-)Kommunikationseinrichtung
und einer Metaraum-(mAnsteuer-)Kommunikationseinrichtung
-
In
den Entwurfsanweisungen der mLokal-Metaraum-Kommunikationseinrichtung
bleibt eine Verfahrensausführung
lediglich von dem Start eines Verfahrens bis zu seinem Ende parallel.
Obwohl diese Semantik verglichen mit den Entwurfsanweisungen der
mAnsteuer-Metaraum-Kommunikationseinrichtung hinsichtlich der Parallelität nicht
hoch ist, hat dieselbe die Vorteile, dass dieselbe durch einen Programmierer
intuitiv verstanden werden kann, während das Volumen der Codes,
die beschrieben werden müssen,
ohne Weiteres reduziert werden kann. Es ist jedoch bei diesen Entwurfsanweisungen für ein asynchrones
Ereignis, wie einen Gerätetreiber,
der eine Unterbrechung verwendet, nicht möglich, effizient beschrieben
zu sein.
-
In
den Entwurfsanweisungen der mAnsteuer-Metaraum-Kommunikationseinrichtung
kann das ununterbrochene Verfahren, das nach einem Beenden eines
gegenwärtigen
Verfahrens auszuführen ist,
bestimmt sein. Wenn eine Antwort zu einem Objekt zurückgesendet
wird, das das gegenwärtige
Verfahren in Verbindung mit einem asynchronen Ereignis, wie einer
Unterbrechung, ausführt,
kann das vorher bestimmte ununterbrochene Verfahren durch Anstoßen der
Fortsetzung gestartet werden. Das asynchrone Ereignis, wie ein Gerätetreiber,
kann daher effizient beschrieben sein. Obwohl es möglich ist,
ein Programm zu beschreiben, das verglichen mit den Entwurfsanweisungen
der mLokal-Metaraum-Kommunikationseinrichtung hinsichtlich der Parallelität hoch ist,
hat die mAnsteuer-Metaraum-Kommunikationseinrichtung
dahingehend Mängel,
dass dieselbe durch den Programmierer nicht intuitiv verstanden werden
kann und dass die Menge eines Codes, der beschrieben werden muss,
dazu tendiert, groß zu sein.
-
System zum Realisieren einer
Kommunikationseinrichtung
-
Bei
diesem Verfahren wird die Funktion, die durch den Metaraum eingerichtet
wird, durch das Objekt, das den Metaraum bildet, realisiert. Ein
solches Objekt ist im Gegensatz zu dem Objekt, das die Funktion,
die durch den Metaraum eingerichtet wird, verwendet, als ein Meta-Ebenen-Objekt
oder ein Metaobjekt bezeichnet. Das Objekt, das die Funktion, die
durch den Metaraum angeboten wird, verwendet, ist andererseits als
das Basisebenen-Objekt oder als ein Basisobjekt bezeichnet.
-
Als
ein Objekt, das die gemeinsamen Funktionen der Meta-Räume einrichtet,
kann ein sogenannter Zeitplaner (engl.: scheduler) (als ein bildendes
Element zum Realisieren von jeder Kommunikationseinrichtung, wie
nun erklärt
ist) verwendet sein. Das Objekt Zeitplaner ist ein Metaobjekt, das
den Zustand eines Objekts verwaltet. Die Entwurfsanweisungen des
Zeitplaners, die bei dem vorliegenden Ausführungsbeispiel erforderlich
sind, sind anschließend
erklärt.
-
Da
sich die Kommunikationseinrichtung des Metaraums mLokal von derselben
für den
Metaraum mAnsteuer unterscheidet, kann das Metaobjekt, das die Funktionen,
die die relevante Kommunikationseinrichtung realisieren, einrichtet,
getrennt definiert sein. Das Metaobjekt zum Realisieren der Nachrichtenlieferung
in der mLokal-Metaraum-Kommunikationseinrichtung
ist als das Metaobjekt MLokalerVersender bezeichnet, während dasselbe
zum Realisieren der Nachrichtenlieferung in der mAnsteuer-Metaraum-Kommunikationseinrichtung
als ein Metaobjekt MAnsteuer-Versender bezeichnet ist.
-
Die
mLokal-Metaraum-Kommunikationseinrichtung ist durch das Metaobjekt
MLokalerVersender, den Zeitplaner und andere Module, die die Ausführung derselben
unterstützen,
realisiert. Die mAnsteuer-Metaraum-Kommunikationseinrichtung ist durch
das Metaobjekt MAnsteuer-Versender, den Zeitplaner und andere Module,
die die Ausführung derselben
unterstützen,
realisiert. Der Beziehung zwischen dem Metaobjekt MLokalerVersender
und dem Zeitplaner und derselben zwischen dem Metaobjekt MAnsteuer-Versender
und dem Zeitplaner sind ein Szenario gegeben, und das System zum Realisieren
von jeder Kommunikationseinrichtung ist gezeigt. Die Zukunft und
die Fortsetzung sind ebenfalls gegebene Attribute und der Zustandsübergang derselben
ist durch das Szenario gezeigt.
-
System zum Realisieren einer Kommunikationseinrichtung
für die
Zukunft und derselben für
einen Metaraum mLokal
-
9 bis 12 zeigen
die Beziehung zwischen dem Metaobjekt MLokalerVersender und dem Zeitplaner
durch ein Szenario (ein Flussdiagramm).
-
9 zeigt
die Prozedur des Sendens für den
Metaraum mLokal.
-
Wenn
das Basisobjekt in dem Metaraum mLokal in 9 das Senden
ausführt,
geht ein Verarbeiten zu dem Metaobjekt MLokalerVersender für die Kommunikationseinrichtung,
die den Metaraum mLokal bildet, über,
wobei das Basisobjekt in einem Zustand Wartend (Warten) ist, wie
bei einem Schritt ST7 gezeigt ist. Auf einen solchen Übergang
des Verarbeitenszustands von dem Basisobjekt zu dem Metaobjekt ist
im Folgenden als eine M (Metaberechnung) Bezug genommen.
-
Bei
einem solchen Verarbeitensübergang
erzeugt das Metaobjekt MLokalerVersender bei einem Schritt ST1 eine
Zukunft (Zukunft).
-
Bei
einem Schritt ST2 wird dann der Zustand der Nachrichtenwarteschlange
(des Nachrichtenarrays) für
das Objekt mit der Adresse, zu der die Nachricht (AktiveNachricht)
zu liefern ist, bestimmt. Wenn es zu dieser Zeit keine Nachricht
in der Nachrichtenwarteschlange gibt (FALSCH), ist das Zielobjekt
in dem Ruhezustand (schlafend, wenn der Zeitplaner in dem Überwachungszustand
ist). Eine API BereitMachen wird daher bei einem Schritt ST5 zu
dem Zeitplaner ausgegeben, um einen Zustand einer möglichen
Ausführung
für das
Objekt (einen Bereit-Zustand, wenn der Zeitplaner überwacht)
einzustellen.
-
Die
Nachrichtenwarteschlange ist hier kurz erklärt. Bezug nehmend auf 13 verwertet
die CPU die gelieferte Nachricht, wenn einer der Programmfäden (engl.:
threads) in dem Objekt ausgeführt
wird. Die Nachrichtenwarteschlange stellt das Nachrichtenarray dar
und ist zum folgenden Verwerten der Nachrichten in der Nachrichtenwarteschlange aufgebaut.
Die API BereitMachen wird verwendet, um das Objekt ausführbar zu
machen, während
ein Bereit und ein Schlafend den Zustand einer möglichen Ausführung beziehungsweise
den Zustand Schlafend des Objekts anzeigen. In dem Zustand Schlafend
ist das Objekt leer laufend und bereit, eine Nachricht zu empfangen.
Die API BereitMachen hat das Verfahren und die Nachricht (Nrt),
die das Objekt als ein Argument (Programmfaden der Basis) spezifiziert
(Objekt B bei dem vorliegenden Ausführungsbeispiel). Bei dem vorliegenden
Ausführungsbeispiel wird
daher ein Überwachungsbefehl
zum Spezifizieren des Basisobjekts B zum Senden der Nachricht (Nrt)
zu dem Verfahren B zu dem Zeitplaner gesendet.
-
Wenn
es andererseits bei einem Schritt ST2 eine Nachricht in der Nachrichtenwarteschlange
gibt (WAHR), wurde eine Nachricht zu dem Objekt mit der Adresse
bereits geliefert und das Objekt befindet sich in dem Zustand einer
möglichen
Ausführung
(Bereit), während
das Objekt im Laufe einer Ausführung
ist (Laufend). Bei einem Schritt ST4 wird die Nachricht daher an
das hintere Ende der Nachrichtenwarteschlange gestellt, um das Verarbeiten
zu beenden. Die Zukunfts-ID, die die Zukunft, die einer Nachrichtensendung
entspricht, identifizieren kann, wird durch die Nachrichtenwarteschlange
gleichzeitig verwaltet. Diese Zustände sind anschließend unter
Bezugnahme auf 2 erklärt.
-
Ein
Rückgabewerterfolg
(sErfolg), der den Lieferungsende-Zustand anzeigt, wird dann in
die Metanachricht (MetaNachricht) platziert und ein Zustandsübergang
wird wieder zu dem Basisobjekt versetzt. Das Basisobjekt befindet
sich dann in dem Zustand einer Ausführung oder in dem Zustand einer möglichen
Ausführung,
wie bei einem Schritt ST8. Die Metanachricht (MetaNachricht) ist
eine Nachricht mit einem Parameter (einem Argument), das für ein Senden
erforderlich ist, wenn das Basisobjekt in dem Metaraum (mLokal)
das Senden durchführt.
-
Die
im Vorhergehenden erwähnten
M (Metaberechnung) und W (Wiederaufnehmen) sind in der
japanischen Patentanmeldung 89-67881 ,
auf die im Vorhergehenden Bezug genommen ist, detailliert gezeigt.
-
10 zeigt
die Prozedur betreffend einer Antwort durch das Metaobjekt (den
MLokalerVersender).
-
Bezug
nehmend auf 10 bestätigt das Metaobjekt (der MLokalerVersender)
zuerst bei einem Schritt ST11, welches Basisobjekt die Antwort (Antwort)
gegeben hat. Bei den Beispielen von 3 und 4 wird
bestätigt,
dass das Basisobjekt B die Antwort ausgegeben hat. Für diese
Bestätigung
wird die Funktion LetztenHolen, beispielsweise von der API, bei
dem vorliegenden Ausführungsbeispiel
verwendet. Jedes gewünschte Verfahren
kann jedoch verwendet sein. Das Basisobjekt befindet sich bei einem
Schritt ST24 in dem Zustand Wartend.
-
Bei
einem Schritt ST12 bis zu einem Schritt ST14 wird dann geprüft, ob die
Zukunfts-ID, die gleichzeitig
mit dem Starten des Basisobjekts gesendet wird, tatsächlich die
Zukunft (Zukunft) des Metaraums (mLokal) ist. Wenn die Resultate
der Schritte ST12 und ST14 falsch sind, wird angenommen, dass ein
Fehler aufgetreten ist, und ein Verarbeiten geht zu einem Schritt
ST22 über.
Wenn das Resultat einer Prüfung
bei einem Schritt ST13 falsch ist, ist der Zustand einer Kommunikation
mit einem anderen Metaraum durch eine Kommunikationseinrichtung,
die die Markierung als ein Merkmal der vorliegenden Erfindung verwendet,
gleichbedeutend, und das Metaobjekt (Lieferant), wie im Folgenden
erklärt
ist, wird aufgefordert, das Verarbeiten zu übernehmen.
-
Wenn
das Resultat einer Prüfung
bei den Schritten ST12 bis ST14 JA ist, wird das Attribut (Erzeuger)
der Zukunft (Zukunft) bei einem Schritt ST15 geprüft. Das
Attribut (Erzeuger) umfasst zu dieser Zeit das Objekt, das die Nachricht
zu dem Basisobjekt, das die Antwort (Antwort) gegeben hat, gesendet
hat. Bei dem Beispiel von 3 und 4 ist
das Objekt, das die Nachricht zu dem Basisobjekt B, das die Antwort
gegeben hat, gesendet hat, A und ist in einem Bereich Programmfaden-ID-Erzeuger
aufbewahrt.
-
Bei
einem Schritt ST16 wird als Nächstes
geprüft,
ob das Objekt in dem Zustand Wartend (Warten) ist. Wenn das Objekt
in dem Zustand Wartend (Warten) ist, führt das Objekt das WartenAuf
wie bei einem Schritt ST17 aus. Bei einem Ausführen des WartenAuf sind eine
Zukunfts-ID (ZukunftsID), eine Antwortnachricht (&Nrt) und eine
Größe (Größevon(Nrt))
Argumente, die gegenwärtig
behandelte Zukunfts-ID (ZukunftsID) ist gleich einer Zukunfts-ID (ZukunftsID),
die dem WartenAuf gegeben ist, und der Nachricht (Nrt), die durch
die Antwort (Antwort) gesendet wird, wird das Argument (&Nrt) gegeben, wie
unter Bezugnahme auf 3 und 4 erklärt ist.
Das Objekt in dem Zustand Wartend befindet sich durch die API BereitMachen
wieder in dem Zustand einer möglichen
Ausführung.
Das heißt,
das Objekt A bei den Beispielen von 3 und 4 wird
wieder in den Zustand einer möglichen
Ausführung
versetzt.
-
Da
das Verfahren der Adresse in dem Zustand Wartend ist, ist eine Bestimmung
und daher ein NICHT-DEFINIEREN (Nicht-Definieren) oder eine Nachricht
nicht notwendig und sind daher NULL.
-
Wenn
andererseits bei einem Schritt ST16 das Attribut Erzeuger nicht
in dem Zustand Wartend ist, wird ein WartenAuf noch nicht ausgeführt. Das Metaobjekt
(MLokalerVersender) stellt daher zu dieser Zeit bei einem Schritt
ST19 das Attribut (istAntwortGegeben) der Zukunft (Zukunft) ein,
um ein Markierzeichen für
einen Antwortabschluss einzugeben. Wenn notwendig, wird die Antwortnachricht
in der Nachricht (Nachricht), wie bei einem Schritt ST18, vorübergehend
aufbewahrt.
-
Die
Zukunft (Zukunft) wird anschließend
bei einem Schritt ST20 gelöscht
und ein Rückgabewerterfolg
(sErfolg) eines Lieferungsabschlusses wird bei einem Schritt ST21
in eine Metanachricht (MetaNachricht) eingegeben. Bei einem Schritt
ST22 wird ein Rückgabewert,
der einen Fehler spezifiziert, in die Metanachricht (MetaNachricht)
eingegeben, und bei einem Schritt ST23 wird ein Rückgabewerterfolg (sErfolg)
für einen
Lieferungabschluss in die Metanachricht (MetaNachricht) eingegeben.
Das Basisobjekt tritt dann in einen Ausführzustand oder einen Zustand
einer möglichen
Ausführung,
wie bei einem Schritt S25, ein.
-
11 und 12 stellen
die Prozedur für ein
WartenAuf dar. 11 zeigt insbesondere einen Fall,
bei dem eine Antwort vor einem WartenAuf ausgeführt wird (der Fall von 4),
während 12 den
umgekehrten Fall (das heißt,
einen Fall von 3) in Verbindung mit der Erklärung von 10 zeigt.
Der anschließende
Fluss des Basisobjekts ist um einer Einfachheit willen nicht gezeigt.
-
In 11 wird
die Zukunft (Zukunft) bei einem Schritt ST31 bestätigt. Bei
einem Schritt ST32 wird geprüft,
ob das Attribut (istAntwortGegeben) der Zukunft (Zukunft) eingestellt
wurde oder nicht, das heißt,
ob die Antwort (Antwort) gegeben wurde oder nicht. Wenn die Resultate
dieser Schritte ST31, ST32 beide WAHR sind, wird die Nachricht als
ein Resultat der Resultatsnachricht, die bei einem Schritt ST33
in der Zukunft (Zukunft) eingestellt wird, in der Nachricht (&Nrt) eines WartenAuf
eingestellt. Die Zukunft (Zukunft) wird anschließend bei einem Schritt ST31 gelöscht, und
bei einem Schritt ST35 wird ein Lieferungsenderfolg (sErfolg) in
eine Metanachricht (MetaNachricht) eingegeben. Wenn das Resultat
eines Schritts ST31 FALSCH ist, wird bei einem Schritt ST36 der
Fehlercode in die MetaNachricht eingegeben, um ein W (Wiederaufnehmen)
durchzuführen. Wenn
das Resultat eines ST32 FALSCH ist, geht ein Verarbeiten zu einem
in 12 gezeigten Schritt ST43 über.
-
In 12 wird
die Zukunft (Zukunft) bei einem Schritt ST41 bestätigt, und
bei einem Schritt ST42 wird bestätigt,
ob das Attribut (istAntwortGegeben) eingestellt wurde oder nicht.
Wenn die Resultate der Schritte ST41 und ST42 beide WAHR sind, wird bei
einem Schritt ST43 der Zustand Wartend eingestellt. Ein Erfolg (sErfolg)
wird anschließend
in eine Metanachricht (MetaNachricht) eingegeben und bei einem Schritt
ST45 von einem MetaAufruf ausgesendet. Wenn das Resultat des Schritts
ST41 FALSCH ist, wird bei einem Schritt ST46 ein Fehlercode in die Metanachricht
(MetaNachricht) eingegeben, um ein W (Wiederaufnehmen) durchzuführen. Wenn
das Resultat des Schritts ST42 FALSCH ist, geht das Verarbeiten
zu dem Schritt ST33 von 11 über. Bei den
Beispielen von 11 und 12 fragt
das Basisobjekt bei dem Metaobjekt (MLokalerVersender) an, einen
Zustand Wartend (Warten) bis zu einem W (Wiederaufnehmen) einzustellen.
-
System zum Realisieren einer Fortsetzung
und einer Metaraum-(mAnsteuer-) Kommunikationseinrichtung
-
In 14 bis 18 ist
die Beziehung zwischen dem Metaobjekt mAnsteuerVersender und dem
Zeitplaner durch ein Szenario angegeben. Da das Metaobjekt mAnsteuerVersender
ein Metaraum für
einen Gerätetreiber
ist, ist die Prozedur etwas komplexer als dieselbe für das Metaobjekt
mLokalerVersender. Ein erläuterndes
Beispiel ist eine Tabelle einer verzögerten Ausführung (VerzögerteAusführungTabelle). Die Prozedur
des Sendens und des Anstoßens
in dem Metaobjekt MAnsteuer-Versender ist derart, dass, wenn das
Objekt in dem Metaraum mAnsteuer das Senden oder Anstoßen anfragt,
lediglich eine Registrierung in der Tabelle einer verzögerten Ausführung (VerzögerteAusführungTabelle) ausgeführt wird,
während
eine Lieferung von tatsächlichen
Nachrichten zu der Zeit eines Aussteigens aus dem Verfahren gemeinsam
ausgeführt
wird.
-
14 zeigt
die Prozedur des Sendens in dem Metaobjekt MAnsteuer-Versender.
-
Bezug
nehmend auf 14 wird das Senden-Verarbeiten
bei einem Schritt ST51 in der Tabelle einer verzögerten Ausführung (VerzögerteAusführungTabelle) registriert,
wie im Vorhergehenden erklärt
ist. Das heißt,
das Argument für
eine verzögerte Ausführung in
der Metanachricht wird in der Tabelle registriert. Wenn das Basisobjekt
in dem Metaraum mAnsteuer ein Senden durchführt, wird die Metanachricht
(MetaNachricht) als ein Gegenstand, der Parameter, die für das Senden
erforderlich sind, enthält, in
der Tabelle einer verzögerten
Ausführung
(VerzögerteAusführungTabelle)
registriert. Bei einem Schritt ST52 wird anschließend ein
Erfolg (sErfolg) in die Metanachricht (MetaNachricht) eingegeben,
um das W (Wiederaufnehmen) durchzuführen.
-
Die
Struktur der im Vorhergehenden erwähnten Metanachricht (MetaNachricht)
ist kurz erklärt.
-
Bezug
nehmend auf 19 hat die Metanachricht (MetaNachricht)
zwei Bereiche, nämlich
einen Bereich A für
die zum Ausführen
der API des Metaaufrufs (Metaaufruf) erforderlichen Informationen, wie
ein Argument, und einen Bereich B für Fehlercodes. Die Tabelle
einer verzögerten
Ausführung (VerzögerteAusführungTabelle)
wird durch das Objekt des Versenders (Versender), der einen Bereich für die Tabelle
in dem Speicher sichert, erzeugt, wie bei dem in 5 gezeigten
Fall eines Erzeugen der Zukunft (Zukunft).
-
15 zeigt
die Prozedur des Anstoßens
in dem Metaobjekt (MAnsteuerVersender). In dieser Figur wird wie
in 14 bei einem Schritt ST61 das Anstoßen-Verarbeiten
in der Tabelle einer verzögerten
Ausführung
(VerzögerteAusführungTabelle)
registriert. Ein Erfolg (sErfolg) wird anschließend bei einem Schritt ST62
in die Metanachricht (MetaNachricht) eingegeben, um das W (Wiederaufnehmen) durchzuführen.
-
16 zeigt
ein Verfahren, bei dem das Basisobjekt in dem Metaraum mAnsteuer
ein Verarbeiten zu der Zeit eines Austeigens des Metaobjekt MAnsteuer-Versenders
beendet. Die in der Tabelle einer verzögerten Ausführung (VerzögerteAusführungTabelle) registrierte
Prozedur wird hier in der Folge ausgeführt, in der ein Verarbeiten
angefragt wurde, und die Prozedur wird schließlich zum Beenden des Objektverfahrens
genommen.
-
In 16 wird
zuerst der Schritt ST71 eingestellt, und das Basisobjekt, das die
Ausstiegs-Prozedur angefragt hat, wird (unter Verwendung von beispielsweise
einer Funktion LetztenHolen) identifiziert.
-
Bei
einem Schritt ST72 wird als Nächstes
geprüft,
ob das Basisobjekt durch eine Unterbrechung gestartet wurde oder
nicht. Das heißt,
es wird geprüft, ob
das Ausstiegs-Verfahren aufgrund einer Basisobjekt-Unterbrechung
gestartet wurde. Wenn das Verfahren durch eine Unterbrechung gestartet
wurde, ist es wahrscheinlich, dass nach der Unterbrechung, die ein
Starten des Verfahrens bewirkt hat, eine andere Unterbrechung anwesend
ist. Bezug nehmend auf 20 wird, wenn das Basisobjekt
II während
einer Ausführung
des Basisobjekts I unterbrochen hat, bei einem Schritt ST73 geprüft, ob der
anwesende Ausstieg den Ausstieg der Unterbrechung des Basisobjekts
II bedeutet. Wenn sich die Resultate einer Prüfung bei einem Schritt ST72
und ST73 beide als WAHR herausstellen, kehrt ein Verarbeiten bei
einem Schritt ST74 zu der im Vorhergehenden erwähnten getrennten Unterbrechung
(Wiederaufnahmeunterbrechung) zurück. Wenn die Resultate der
Prüfung bei
den Schritten ST72 und ST73 beide FALSCH sind, wird die in der Tabelle
einer verzögerten
Ausführung
(VerzögerteAusführungTabelle)
registrierte Prozedur durchgeführt.
Hinsichtlich dieses Verarbeitens zeigen 17 und 18 ein
Senden beziehungsweise ein Ansstoßen.
-
Nachdem
das Verarbeiten für
die Tabelle einer verzögerten
Ausführung
(VerzögerteAusführungTabelle)
bei einem Schritt ST75 zu Ende geht, wird bei einem Schritt ST76
wieder geprüft,
ob das Basisobjekt durch eine Unterbrechung gestartet wurde oder
nicht. Dieser Schritt ST76 ist im Wesentlichen der gleiche wie der
Schritt ST72. Wenn das Objekt durch eine Unterbrechung gestartet
wurde, wird die Prozedur zum Zurückkehren
von derselben (AusstiegAusUnterbrechung) ausgeführt, um die erste Unterbrechung
zu beenden. Wenn das Objekt durch keine Unterbrechung gestartet
ist, wurde das Objekt durch eine übliche Kommunikation zwischen
Objekten gestartet. Bei einem Schritt ST78 wird die Tabelle einer verzögerten Ausführung (VerzögerteAusführungTabelle)
initialisiert, und eine Nachricht wird zu einem Zeitplaner gesendet,
um denselben schlafend zu machen (Schlafendmachen). Das Argument
(Basis-Programmfaden) ist ein Basisobjekt, das bei dem Schritt ST71
spezifiziert wird. Bei einem Schritt ST79 wird die so weit ausgeführte Nachricht
aus der Nachrichtenwarteschlange des Basisobjekts entfernt.
-
Wenn
die Nachrichtenwarteschlange leer geworden ist, geht das Verarbeiten
zu Ende. Wenn die Nachrichtenwarteschlange nicht leer ist, wird
ein BereitMachen mit der Nachricht, die als Nächste zu liefern ist, als ein
Argument zu dem Zeitplaner ausgegeben, so dass das Objekt wieder
durch die Nachricht, die durch das Argument angegeben ist, gestartet
wird. Dies stellt das Objekt in einen Zustand einer möglichen
Ausführung
(bereit) für
die nächste
Nachricht.
-
17 und 18 zeigen
ein Szenario zum Verarbeiten einer der in der Tabelle einer verzögerten Ausführung (VerzögerteAusführungTabelle)
registrierten Prozeduren. Wenn beispielsweise 10 in die Tabelle
eingegeben wird, werden 10 Operationen ausgeführt. Der Inhalt der Anfrage
zu dem Zeitplaner durch die Anwesenheit oder die Abwesenheit der Nachricht
ist demselben bei dem Fall des Metaobjekts MLokalVersender ähnlich.
-
Bei
einem Fall des Sendens in dem Metaobjekt MLokalerVersender in 17 wird
zuerst bei einem Schritt ST81 eine Fortsetzung erzeugt.
-
Bei
dem nächsten
Schritt ST82 wird geprüft, ob
die Adresse der Nachricht der Metaraum mAnsteuer ist. Wenn das Resultat
einer Prüfung
FALSCH ist, wird ein Metaobjekt Lieferant aufgefordert, ein Verarbeiten
durchzuführen,
und übernimmt
dann eine Markierungskommunikation. Bei einem Schritt ST83 wird
der Zustand der Nachrichtenwarteschlange des Objekts der Adresse
einer Lieferung einer Nachricht (AktiveNachricht) geprüft. Wenn
es in der Nachrichtenwarteschlange keine Nachricht gibt, ist das
Objekt in dem Ruhezustand (schlafend, wenn der Zeitplaner eine Überwachung übernimmt).
Bei einem Schritt ST85 wird daher ein BereitMachen zu dem Zeitplaner
ausgegeben, um den Zustand einer möglichen Ausführung des
Objekts einzustellen oder den Zustand einer möglichen Ausführung des
Objekts einzustellen, wenn der Zeitplaner in dem Überwachungszustand
ist.
-
Wenn
bei einem Schritt ST82 und ST83 die Resultate einer Prüfung WAHR
sind, wurde die Nachricht zu dem Objekt eines Ziels bereits geliefert, so
dass sich das Objekt in dem Zustand einer möglichen Ausführung, im
Laufe einer Ausführung
(LAUFEND) oder einem ausgesetzten Zustand befindet. Bei einem Schritt
ST84 wird daher die entsprechende Nachricht in den hinteren Anschnitt
der Nachrichtenwarteschlange eingegeben, um das Verarbeiten zu beenden.
Eine Fortsetzung, die der Nachrichtensendung und einer MID zum Spezifizieren
derselben entspricht, wird, wie im Folgenden erklärt ist,
zu dieser Zeit ferner in der Nachrichtenwarteschlange überwacht.
-
Bei
einem Fall des Anstoßens
des Metaobjekts MAnsteuer-Versender in 18 wird
bei einem Schritt ST91 geprüft,
ob eine Fortsetzung, wie angegeben ist, eine Fortsetzung des Metaobjekts
MAnsteuer-Versender ist oder nicht. Wenn das Resultat einer Prüfung bei
einem Schritt ST91 WAHR ist, wird bei einem Schritt ST92 die Anwesenheit
einer Fortsetzung geprüft.
Wenn eine Fortsetzung bestätigt wird,
wird dieselbe bei einem Schritt ST93 geöffnet und Attribute in der
Fortsetzung (Adresse, Verfahren oder Nachricht) werden geprüft, so dass
demgemäß das Senden
ausgeführt
wird. Bei dem nächsten Schritt
ST94 wird die Nachricht bestätigt.
Bei einem Schritt ST95 wird die Nachricht in den letzten Abschnitt
der Nachrichtenwarteschlange eingegeben, um das Verarbeiten zu beenden.
Die Markierungs-ID (MID), die einer Nachrichtensendung zugeordnet
ist, wie im Folgenden erklärt
ist, wird zu dieser Zeit in der Nachrichtenwarteschlange gleichzeitig überwacht.
-
Wenn
die Resultate einer Prüfung
der Schritte ST92 und ST94 anders sind, wird bei einem Schritt ST96
ein BereitMachen zu dem Zeitplaner ausgegeben, um den Zustand einer
möglichen
Ausführung des
Objekts einzustellen. Die Schritte ST94, ST95 und ST96 sind Funktionen,
die denselben der Schritte ST83, ST84 und ST85 ähnlich sind. Wenn das Resultat
einer Prüfung
bei dem Schritt ST91 FALSCH ist, ist dieser Fall mit dem Fall einer
Kommunikation mit anderen Metaräumen
durch eine Kommunikationseinrichtung, die die Markierung verwendet, gleichbedeutend,
und das Metaobjekt wird aufgefordert, ein Verarbeiten durchzuführen (Lieferant).
-
Basiserklärung der Kommunikationseinrichtung,
die eine Markierung verwendet
-
Für eine Kommunikation
zwischen Objekten, ist es notwendig, neben einer einfachen Nachrichtensendung
eine Synchronisation mit einer Ausführung von anderen Verfahren
oder einem Empfang einer Antwort zu erreichen. Die Zukunft und die
Fortsetzung sind zu dieser Zeit erforderlich. Die Datenstruktur,
die eine Synchronisation und eine Parallelität, die bei einer Kommunikation
zwischen mehreren Objekten erforderlich sind, steuert, wie der Zukunft
oder der Fortsetzung bei dem vorliegenden Ausführungsbeispiel, ist als eine
Markierung bezeichnet. Die Datenstruktur hat eine Struktur wie eine
Struktur in der Sprache C oder PASCAL oder eine Klasse in C++. Diese
Markierung bezieht unterschiedliche Strukturen auf eine gemeinsame
Datenstruktur. Diese gemeinsame Datenstruktur ist zum Umfassen einer Identifizierung
(Attribute: wie ein AusfRaumID-Versender) zum Unterscheiden dieser
unterschiedlichen Datenstrukturen konfiguriert. Die gemeinsame Datenstruktur
ist ferner zum Umfassen einer Identifizierung (Attribute: wie ein
Langwort-ZeitStempel) zum Unterscheiden von Datenstrukturen des
gleichen Typs konfiguriert, wie unter Bezugnahme auf 21 detailliert
erklärt
ist. Die zum Unterscheiden der Markierungen notwendige ID ist als
eine MarkierungsID (MID) bezeichnet.
-
Für Markierungsattribute
sind Markierungstypen erforderlich. Der Markierungstyp muss fähig sein,
zu spezifizieren, in welcher Umgebung die Markierung verwendet wird.
Der Markierungstyp muss jedoch nicht fähig sein, eine globale Erkennung zu
erreichen. Es ist ausreichend, wenn bei einem Fall, dass der Markierungstyp
nicht identifiziert werden kann, der Markierungstyp durch Auffordern
eines anderen unabhängigen
Objekts, das fähig
ist, den Markierungstyp zu spezifizieren, identifiziert wird.
-
Indem
eine Zukunft (Zukunft) und eine Fortsetzung (Fortsetzung) in dem
Metaraum mLokal und dem Metaraum mAnsteuer als Beispiel genommen werden,
wird die Kommunikation zwischen unterschiedlichen Metaräumen, die
Markierungen verwenden, erklärt.
Bei dem vorliegenden Ausführungsbeispiel
ist angenommen, dass das Objekt A und das Objekt B in dem Metaraum
mLokal beziehungsweise dem Metaraum mAnsteuer anwesend sind, wie
im Vorhergehenden erörtert
ist, und die folgenden Verfahren sind definiert.
Objekt A
Verfahren
A1 (A::A1)
Objekt B
Verfahren B1 (B::B1)
Verfahren
B2 (B::B2)
-
Der
Basisbetrieb der Kommunikation zwischen unterschiedlichen Metaräumen, die
Markierungen verwenden, ist für
die folgenden zwei Fälle
erklärt.
- 1. Das Objekt A, Verfahren A1 (A::A1) veranlasst das
Senden und das WartenAuf (Senden + WartenAuf) für das Verfahren B1 (B::B1).
- 2. Das Objekt B, Verfahren A1 (A::A1) veranlasst das Senden
und das WartenAuf für
das Verfahren A1 (A::A1) und bestimmt ein Senden für das Verfahren
A1 (A::A1) und bestimmt das Verfahren B2 (B::B2) als ein ununterbrochenes
Verfahren.
-
„Falls
das Objekt A, Verfahren A1 (A::A1), das Senden und das WartenAuf
(Senden + WartenAuf) für das
Verfahren B1 (B::B1) veranlasst"
-
Das
Verfahren A1 (A::A1) führt
das Senden (Objekt B, Verfahren B1, Nachricht (Nrt), Funktion Größevon(Nrt)
und Zukunfts-ID (ZukunftsID)) aus. Das Metaobjekt MLokalerVersender
zum Durchführen
dieses Verarbeiten erzeugt zu dieser Zeit die Zukunft (Zukunft).
Es ist ausreichend, wenn die Zukunft (Zukunft) die folgenden Bedingungen
erfüllt:
Die
Zukunft (Zukunft) muss ein eindeutiger Gegenstand sein, der fähig ist,
die Markierungs-ID zu identifizieren,
der Markierungstyp zeigt
die Zukunft (Zukunft) des Metaraums mLokal an, und
die Zukunft
(Zukunft) hat Attribute der in 6 gezeigten
Zukunft (Zukunft).
-
Das
Metaobjekt MLokalerVersender fordert das Metaobjekt MAnsteuer-Versender
auf, durch eine Einrichtung die Nachricht (Nrt) zu dem Objekt B zu
liefern, während
dasselbe ferner ein Starten des Verfahrens B1 (B::B1) anfragt. Die
Markierungs-ID, die fähig
ist, die Zukunft (Zukunft) zu spezifizieren, wird zu dieser Zeit
gleichzeitig geliefert. Die Zukunfts-ID (ZukunftsID) wird zum anschließenden Spezifizieren
der Zukunft empfangen. Die Variable des Typs ist hier eine Zukunfts-ID
(ZukunftsID). Diese ID ist geplant, um die Markierungs-ID unter
Erfüllen der
Entwurfsanweisungen des Metaraums mLokal abzubilden.
-
Das
Objekt B kann nicht wissen oder sollte nicht wissen, woher die Nachricht
geliefert wurde, wenn das Verfahren B1 (B::B1) durch seine Nachricht (Nrt)
gestartet wird. Dies ist bei der Realisierung einer transparenten
Kommunikation zwischen Objekten erforderlich. Wenn das Verfahren
B1 (B::B1) gestartet wird, wird gleichzeitig mit der Nachricht (Nrt)
eine Fortsetzung gestartet. Die Fortsetzung (Fortsetzung) wird als
ein Typ einer Fortsetzungs-ID (FortID) behandelt. Die Variable ist
FortID. Diese Variable identifiziert die gleiche Markierung wie
die vorhergehende ZukunftsID.
-
Bei
einem Fortschritt einer Ausführung
des Verfahrens B1 (B::B1) wird das Anstoßen (FortID) ausgeführt. Das
Metaobjekt MAnsteuer-Versender prüft zu dieser Zeit den Markierungstyp,
der durch die Fortsetzungs-ID (FortID) spezifiziert werden kann.
Es gibt zu dieser Zeit von dem Standpunkt des Markierungs-ID-Verwaltungssystems
aus zwei Möglichkeiten.
- 1. Ein System, bei dem ein Metaobjekt MAnsteuer-Versender
erkennen kann, dass der mit einer Fortsetzungs-ID (FortID) identifizierbare
Markierungstyp die Zukunft (Zukunft) eines Metaraums mLokal ist
(Markierungs-ID-Verwaltungssystem (1)).
- 2. Ein System, bei dem das Metaobjekt MAnsteuer-Versender den
mit einer Fortsetzungs-ID (FortID) identifizierbaren Markierungstyp
nicht erkennen kann (Markierungs-ID-Verwaltungssystem (2)).
-
Bei
dem ersteren System kann das Metaobjekt MAnsteuer-Versender durch
eine Einrichtung eine MarkierungsID direkt zu dem Metaobjekt liefern. Wenn
die MarkierungsID geliefert wird, kann das Metaobjekt MLokalerVersender
ein Verarbeiten auf die gleiche Weise durchführen, als wenn die Antwort (Antwort)
in dem Metaraum mLokal durchgeführt wird.
Das heißt,
eine Ausführung
des Verfahrens A1 (A::A1) kann für
die Zukunft (Zukunft), die einer MarkierungsID (= Zukunfts-ID (ZukunftsID))
entspricht, auf die gleiche Weise wie das in 10 gezeigte Szenario
wieder eingeleitet werden, oder die Antwortnachricht kann vorübergehend
in der Zukunft (Zukunft) aufbewahrt werden.
-
Bei
dem letzteren Fall kann das folgende Verfahren als ein Verfahren
zum Liefern der MarkierungsID zu dem Metaobjekt MLokalerVersender
geplant sein.
- 1. Es gibt ein anderes Objekt,
das einen Markierungstyp überwacht.
Wenn demselben die MarkierungsID gegeben ist, untersucht dieses
Objekt den Typ der MarkierungsID und bereitet ein Verfahren vor,
das einen Versender als eine API zeigt, die fähig ist, die Markierung zu
verarbeiten. Das Metaobjekt MAnsteuer-Versender verwertet dieses
Verfahren, um zu wissen, dass es ausreicht, die MarkierungsID zu
dem Metaobjekt MLokalerVersender zu liefern, und liefert die MarkierungsID
direkt zu dem Metaobjekt MLokalerVersender (Markierungs-ID-Verwaltungssystem (2A)).
- 2. Es gibt ein anderes Objekt, das einen Markierungstyp überwacht,
und das Objekt liefert die angegebene MarkierungsID direkt zu dem
Versender (Versender), der fähig
ist, die zugeordnete Markierung zu verarbeiten (Markierungs-ID-Verwaltungssystem
(2B)).
-
Bei
diesen Fällen
wird die MarkierungsID schließlich
zu dem Metaobjekt MLokalerVersender geliefert, um eine Ausführung des
Verfahrens A1 (A::A1) auf die gleiche Weise wie das in 10 gezeigte
Szenario neu zu starten oder die Antwortnachricht vorübergehend
in der Zukunft (Zukunft) aufzubewahren.
-
„Das
Objekt B, Verfahren A1 (A::A1) veranlasst das Senden und WartenAuf
für das
Verfahren A1 (A::A1) und bestimmt das Verfahren B2 (B::B2) als ein
ununterbrochenes Verfahren"
-
Das
Verfahren B1 (B::B1) führt
das Senden (Objekt A, Verfahren A1, Nachricht (Nrt), Funktion (Größevon(Nrt)),
Verfahren B2 und Nachricht (UnunterbrNrt))) durch. Das Metaobjekt
(MAnsteuerVersender), das diese Prozedur ausführt, erzeugt zu dieser Zeit
eine Fortsetzung (Fortsetzung), die den folgenden Erfordernissen
genügt:
dass
die Fortsetzung (Fortsetzung) ein eindeutiger Gegenstand ist, der
durch die MarkierungsID identifiziert werden kann;
dass der
Markierungstyp anzeigt, dass sie eine Fortsetzung (Fortsetzung)
des Metaraums (mAnsteuer) ist; und
dass es das Attribut der
in 8 gezeigten Fortsetzung (Fortsetzung) gibt.
-
Das
BS, das das Metaobjekt MAnsteuer-Versender umfasst, liefert durch
eine Einrichtung die Nachricht (Nrt) zu dem Metaobjekt mLokalerVersender
und fragt ein Starten des Verfahrens A1 an. Die MarkierungsID, die
fähig ist,
die Fortsetzung (Fortsetzung) zu identifizieren, wird gleichzeitig
geliefert.
-
Bei
der üblichen
Kommunikation zwischen Objekten des Metaraums mAnsteuer wird diese
MarkierungsID als die Fortsetzungs-ID (FortID) behandelt. Bei diesem
Fall ist es jedoch nicht notwendig, das Metaobjekt MLokalerVersender
als die Fortsetzungs-ID (FortID) zu behandeln, derart, dass dasselbe
als eine MarkierungsID behandelt wird. Wenn bei der üblichen
Kommunikation zwischen Objekten des Metaraums mLokal eine Nachricht
zum Starten eines Verfahrens geliefert wird, wird derselben eine
Markierungs-ID, die von dem Metaobjekt MAnsteuerVersender geliefert
wird, auf die gleiche Weise zugeordnet, wie derselben die Zukunft
(Zukunft) oder die Zukunfts-ID (ZukunftsID) zugeordnet wird.
-
Bei
einem Fortschritt einer Ausführung
des Verfahrens A1 (A::A1) wird die Antwort (Antwort() oder Antwort
(Antwort Nrt)) ausgeführt.
Das Metaobjekt MAnsteuerVersender prüft zu dieser Zeit die Markierungs-ID,
die zugeordnet wird, wenn das Verfahren A1 (A::A1) gestartet wird,
und prüft
den durch die Markierungs-ID
identifizierten Markierungstyp. Bei diesem Fall gibt es auf die
gleiche Weise, wie bei einer Kommunikation von dem Objekt A in dem
Metaraum mLokal zu dem Objekt B in dem Metaraum mAnsteuer, von dem
Standpunkt des MarkierungsID-Verwaltungssystems
aus zwei Möglichkeiten, nämlich
- 1. ein System, bei dem ein Metaobjekt MLokalerVersender
den Markierungstyp, der als eine Fortsetzung (Fortsetzung) eines
Metaraums mLokalerVersender identifizierbar ist, erkennen kann (MarkierungsID-Verwaltungssystem
(1)).
- 2. Ein System, bei dem das Metaobjekt MAnsteuer-Versender den
mit einer Markierungs-ID (FortID) identifizierbaren Markierungstyp
nicht erkennen kann (MarkierungsID-Verwaltungssystem (2)).
-
Bei
diesen beiden Systemen kann, wie bei dem Fall einer Kommunikation
von dem Objekt A in dem Metaraum mLokal zu dem Objekt B in dem Metaraum
mAnsteuer, die MarkierungsID durch eine Einrichtung zu dem Metaobjekt
MAnsteuerVersender geliefert werden. Bei einem Empfang der MarkierungsID
führt das
Metaobjekt MAnsteuerVersender ein Verarbeiten wie bei dem in 18 gezeigten
Szenario durch. Das heißt,
die Fortsetzung (Fortsetzung), die der Markierungs-ID zugeordnet
ist, wird zuerst zum Erhalten des ununterbrochenen Verfahrens und
der ununterbrochenen Nachricht geöffnet. Ansprechend auf den
Zustand der Nachrichtenwarteschlange des Objekts, zu dem das ununterbrochene Verfahren
geliefert werden sollte (Erzeuger einer Fortsetzung), wird zum schließlichen
Starten des Verfahrens B2 (B::B2) auf den Zeitplaner zugegriffen.
-
„Fall
einer Realisierung einer Kommunikationseinrichtung bei dem vorliegenden
Ausführungsbeispiel, die
eine Markierung verwendet"
-
In
dem vorliegenden Kapitel ist ein System einer Realisierung, das
eine Kommunikation mit einer Transparenz von in dem Metaraum mLokal
und in dem Metaraum mAnsteuer anwesenden Objekten unter Verwendung
der Markierung ermöglicht,
erklärt.
Es ist angenommen, dass lediglich zwei Kommunikationseinrichtungen,
nämlich
eine mLokal-Metaraum-Kommunikationseinrichtung
und eine mAnsteuer-Metaraum- Kommunikationseinrichtung,
als unterschiedliche Kommunikationseinrichtungen existieren.
-
Zukunft, Fortsetzung und Markierung
-
In
dem BS können
die Zukunft in einem Metaraum mLokal und eine Fortsetzung in einem
Metaraum mAnsteuer als Markierungen behandelt werden. Bei diesem
Fall ist es für
das BS notwendig, zu unterscheiden, ob die Markierung (Markierung)
die Zukunft (Zukunft) oder die Fortsetzung (Fortsetzung) ist. Als
ein Typ, um eine Unterscheidung zu machen, wird die ID des Versenders
(Versenders) der API verwendet. Wenn die Versender-ID, die als ein
Markierungstyp verwendet wird, ein Metaobjekt MLokalerVersender
oder ein Metaobjekt MAnsteuer-Versender ist, kann die Markierung
identifiziert werden, um die Zukunft (Zukunft) beziehungsweise die
Fortsetzung (Fortsetzung) zu sein.
-
21 zeigt
durch ein Objektmodell-Diagramm des Objektmodellierverfahrens (OMT-Verfahrens)
die Beziehung zwischen der Markierung, der Zukunft und der Fortsetzung
und dieselbe zwischen der Markierung (Markierung) und der Markierungs-ID (MID).
Die Klasse Zukunft C1 und die Klasse Fortsetzung C2 können als
Unterklassen, die von der Klasse Markierung C3 abgeleitet werden,
definiert sein. Die Markierung (Markierung) verwendet einen Ort
einer Ausführung
(AusfRaumID) als eine Identifizierungs-ID. Bei diesem Fall wird
die ID des Orts der Ausführung
(AusfRaumID) als äquivalent
zu der objektidentifizierenden ID verwendet. Die Markierung (Markierung)
kann als eine Markierungs-ID (MID) identifiziert sein. Der in der
Markierung (Markierung) enthaltene Zeitstempel wird verwendet, um
sicherzustellen, dass die Markierung (Markierung), die unter Verwendung
der MarkierungsID (MID) spezifiziert wird, hinsichtlich der Zeitachse
eindeutig ist. Wenn die Zukunft (Zukunft) und die Fortsetzung (Fortsetzung)
identifiziert werden können,
muss der Zeitstempel nicht notwendigerweise verwendet werden.
-
In
der mLokal-Metaraum-Kommunikationseinrichtung und in der mAnsteuer-Metaraum-Kommunikationseinrichtung
werden die Zukunfts-ID (ZukunftsID) und die Fortsetzungs-ID (FortID)
zum Identifizieren einer Zukunft (Zukunft) beziehungsweise einer
Fortsetzung (Fortsetzung) verwendet. Wenn die Markierung (Markierung) eingeführt wird,
kann diese als eine MarkierungsID (MID), die gemeinsam spezifiziert
werden kann, identifiziert werden.
-
Bei
dem vorliegenden Ausführungsbeispiel wird
eine Typ-Neudefinition in einer Kopfdatei (MLokal.k und MAnsteuer
k), die eine Schnittstelle definiert, ausgeführt, so dass der Programmierer
die Schnittstelle, die den Metaraum mLokal oder den Metaraum mAnsteuer
einrichtet, direkt verwenden kann. Das heißt, in der Kopfdatei des Metaraums
mLokal kann die Zukunfts-ID (ZukunftsID) zu der MarkierungsID neu
definiert werden. Dies kann durch beispielsweise die Sprache C oder
das C++-Definitionsverfahren
als eine Typdef-MID-ZukunftsID gezeigt sein; wobei eine Typdef eine
Definition eines neuen Typs bedeutet. In der Fortsetzungs-Kopfdatei
einer Kopfdatei Mansteuer.k des Metaraums mAnsteuer wird die FortsetzungsID
(FortID) zu einer MarkierungsID neu definiert. Dies kann ähnlich als
eine Typdef-MID-FortID gezeigt sein.
-
MarkierungsID-Lieferungssystem und ein
Objekt, das die MarkierungsID liefert
-
Bei
dem vorliegenden Ausführungsbeispiel ist
das im Vorhergehenden erwähnte
MarkierungsID-Verwaltungssystem (2B) angewendet. Als ein Objekt,
das die Kommunikationseinrichtung zwischen unterschiedlichen Metaräumen unterstützt, ist
ein Lieferant eingeführt.
Das Objekt hat hauptsächlich zwei
Schnittstellen (Verfahren oder APIs).
-
Eine
derselben, das heißt
eine Schnittstelle sFehlerLieferObjekt, liefert die Nachricht (Nrt)
zu einem bestimmten Zielobjekt (das durch das Argument Objekt-ID
(OID) und ein Adressenverfahren (Sel) dargestellt ist) und fragt
bei dem Versender (Versender) des Metaraums, in dem das Zielobjekt
existiert, an, das Verfahren des Zielobjekts schließlich zu
starten. Diese Schnittstelle sFehlerLieferObjekt wird ferner verwendet,
wenn das Zielobjekt auf die MarkierungsID (MID), die als eines der
Argumente geliefert wird, anspricht.
-
Die
andere Schnittfläche
(sFehlerLieferMarkierung) sendet eine MarkierungsID (MID) zurück. Das
Objekt Lieferant prüft
den Typ der Markierung (Markierung), die der MarkierungsID (MID)
entspricht, um zu wissen, zu welchem Versender (Versender) die MarkierungsID
(MID) zurückgesendet werden
kann. Wenn notwendig, liefert die Schnittstelle (sFehlerLieferMarkierung)
ferner die Antwortnachricht (AntwortNrt).
-
Unter
den Verfahren, durch die der Versender (engl.: mailer) (Versender)
des Metaraums, in dem das Zielobjekt (Lieferantenziel) existiert,
zu erkennen ist, gibt es
- 1. ein Verfahren,
bei dem ein Objekt, wenn dasselbe erzeugt wird, vorher in einem
Objekt Lieferant registriert wird und das Objekt Lieferant unter Verwendung
einer Tabelle oder dergleichen den Inhalt steuert, und
- 2. ein Verfahren, bei dem ein Metaraum, dem ein Objekt angehört, oder
eine ID, die diesen Metaraum identifizieren kann, in einer Datenstruktur enthalten
ist, die direkt von dem Objekt verfolgt werden kann. Bei dem vorliegenden
Ausführungsbeispiel
wird das letztere Verfahren verwendet.
-
Tatsächliche Kommunikation zwischen
unterschiedlichen Metaräumen
-
Betreffend
die Kommunikation zwischen den unterschiedlichen Metaräumen sind
die folgenden zwei Fälle
einer Kommunikation zwischen zwei unterschiedlichen Metaräumen (einer
in unterschiedlichen Metaräumen
anwesenden Kommunikation zwischen Objekten) geplant.
- A. Der Fall einer Kommunikation, bei der das Metaraumobjekt
mLokal eine Kommunikation mit dem Metaraumobjekt mAnsteuer hat oder
eine solche Kommunikation hat, um die Antwort zu empfangen; und
- B. der Fall einer Kommunikation, bei der der Metaraum mAnsteuer
eine Kommunikation mit dem Metaraumobjekt mLokal hat oder eine solche Kommunikation
hat, um die Antwort zu empfangen.
-
Für die Fälle einer
Kommunikation zwischen unterschiedlichen Metaräumen Metaraum mLokal und Metaraum
mAnsteuer über
ein Objekt Lieferant (Lieferant) zeigen 22 und 23 den
ersteren Fall einer Kommunikation A, während 24 und 25 den
letzteren Fall einer Kommunikation B zeigen.
-
Bezug
nehmend auf 22 ist das Verarbeiten von einer
Annahme der Anfrage für
eine Prozedur das Senden des Basisobjekts durch das Metaobjekt MLokalerVersender
bis zu einer Erzeugung der Zukunft (Zukunft) (Schritt ST101) ähnlich zu
demselben, das in 9 gezeigt ist. Die Zukunft (Zukunft) wird
jedoch als eine Markierungs-Unterklasse
erzeugt.
-
Bei
einem Schritt ST102 wird das Lieferungsziel der Nachricht bestätigt. Wenn
das Ziel einer Lieferung der Nachricht kein Metaraumobjekt mLokal ist,
wird eine Nachricht zu dem Verfahren (Lieferobjekt) des Objekts
Lieferant gesendet.
-
Da
das Objekt Lieferant das Ziel einer Lieferung durch das Argument
des Verfahrens (Lieferobjekt) wissen kann, wird dasselbe weiter
zu dem mAnsteuerVersender geliefert, wie bei einem Schritt ST103
gezeigt ist. Die bei einem Schritt ST106 und folgenden Schritten
(Schritten ST106, ST107 und ST108) gezeigte Prozedur, nachdem die
Lieferung über
die Schnittstelle durch das Metaobjekt mAnsteuer-Versender angefragt
wurde, ist der Prozedur (Schritte ST83, ST84 und ST85), die das
Metaobjekt MAnsteuer-Versender zu der Zeit eines Ausstiegs für das Senden
durchführt, ähnlich.
Bei diesem Fall wird jedoch die MarkierungsID (MID) bei einem Schritt ST107
der Nachrichtenwarteschlange hinzugefügt.
-
23 zeigt
die Prozedur, wenn die Markierungs-ID (MID), die zu dem Metaraum
mAnsteuer geliefert wurde, in dem Metaraum mAnsteuer als die Fortsetzungs-ID
(FortID) behandelt wird und angestoßen wird.
-
Bezug
nehmend auf 23 weiß das Metaobjekt mAnsteuer-Versender,
dass die Fortsetzungs-ID (FortID), die zu der Zeit eines Verarbeiten für ein Anstoßen bei
einem Ausstieg bei einem Schritt ST111 bestimmt wird, nicht die
Fortsetzung des Metaraums mAnsteuer ist. Die Markierungs-ID (MID) wird
daher unter Verwendung der Markierung (LieferMarkierung) des Objekts
Lieferant geliefert.
-
Das
Objekt Lieferant identifiziert bei einem Schritt ST112 die Markierung
(Markierung) von der Markierungs-ID (MID), um aus dem Attribut (AusfRaumID-Versender) zu wissen,
dass die Markierung (Markierung) die Markierung des Metaobjekts
MLokalerVersender (die Zukunft (Zukunft) des Metaraums (mLokal))
ist. Die Markierungs-ID (MID) wird daher zu dem Metaobjekt MLokalerVersender
geliefert.
-
Die
Prozedur seit der Zeit, zu der das Metaobjekt MLokalerVersender
die Markierungs-ID (MID) angenommen hat, ist der Antwort (Antwort)
des Metaobjekts MLokalerVersender von 10 ähnlich. Die
anschließende
Prozedur sind die Schritte ST14, ST15, ST16, ST17 und ST20, wenn
das Resultat eines Schritts ST13 WAHR ist.
-
24 und 25 zeigen
ein Szenario, bei dem eine Nachricht von dem Metaraum mAnsteuer zu
dem Metaraum mLokal gesendet wird und eine Antwort empfangen wird.
Der Betrieb des Objekts Lieferant ist demselben, der in 22 und 23 gezeigt
ist, ähnlich.
-
Das
heißt,
bei dem Beispiel von 24 ist die Prozedur seit der
Zeit, zu der das Metaobjekt MLokalerVersender die Anfrage für eine Prozedur des
Sendens des Basisobjekts angenommen hat, bis zu der Zeit einer Erzeugung
der Fortsetzung (Fortsetzung) derselben, die in 17 gezeigt
ist, ähnlich.
-
Bei
einem Schritt ST122 wird das Ziel einer Lieferung der Nachricht
bestätigt.
Wenn das Ziel einer Nachrichtenlieferung kein Metaraumobjekt mAnsteuer
ist, wird die Nachricht zu dem Verfahren (Lieferobjekt) des Objekts
Lieferant gesendet.
-
Da
das Objekt Lieferant das Ziel einer Lieferung wissen kann, wird
die Nachricht weiter zu ihrem Versender (Versender) geliefert, wie
bei einem Schritt ST123 gezeigt ist. Die Prozedur nach einer Lieferungsanfrage
für das
Metaobjekt MLokalerVersender über
die Schnittstelle, wie bei Schritten ST126, ST127, ST128 gezeigt
ist, ist der Prozedur ähnlich,
die das Metaobjekt MLokalerVersender bei einem Ausstieg des Metaobjekts
MLokalerVersender von 18 für das Senden durchführt (Schritte ST94,
ST95 und ST96).
-
Das
Metaobjekt MLokalerVersender weiß andererseits bei Schritten
ST131 bis ST134, dass die ZukunftsID (ZukunftsID), die zu der Zeit
eines Verarbeitens für
ein Anstoßen
zu der Zeit eines Ausstiegs bestimmt wird, nicht die Zukunft (Zukunft)
des Metaraums mLokal ist, wie bei den Schritten ST11, ST12 und ST13
von 10. Die Markierungs-ID (MID) wird daher unter
Verwendung der Markierung (LieferMarkierung) des Objekts Lieferant
geliefert. Das ist das Gleiche, wie der Fall, bei dem das Resultat
des Schritts ST13 FALSCH ist.
-
Das
Objekt Lieferant spezifiziert bei einem Schritt ST135 aus der Markierungs-ID
(MID) und weiß aus
ihren Attributen, dass die Markierung (Markierung) die Fortsetzung
(Fortsetzung) des Metaraums mAnsteuer ist. Die Markierungs-ID (MID) wird
daher zu dem Metaobjekt MAnsteuer-Versender geliefert.
-
Die
Prozedur seit der Zeit einer Annahme der Markierungs-ID (MID) durch
das Metaobjekt MAnsteuer-Versender ist dem Verarbeiten (Schritte
ST93, ST94, ST95 und ST96) des Metaobjekts MAnsteuer-Versender,
das unter Bezugnahme auf 18 erklärt ist, ähnlich.
-
Andere denkbare Systeme für eine Realisierung
-
In
dem vorliegenden Kapitel sind andere denkbare Systeme für eine Realisierung
der „Kommunikationseinrichtung,
die die Markierung verwendet," als
dieselben, die so weit erklärt
sind, erklärt.
-
„System
für ein
Erkennen des Markierungstyps durch die MarkierungsID"
-
Das
vorliegende Ausführungsbeispiel
hat eine ID des Versenders (Versender) als ein Attribut der Markierung
(Markierung). Dies ermöglicht
eine Unterscheidung des Typs der Markierung (Markierung). Ein anderes
Verfahren ist ein System eines Beifügens der Informationen zum
Erkennen des Markierungstyps zu dem Markierungs-ID. Wenn die Markierungs-ID
eine ganze Zahl ist, die durch zwei Bits dargestellt ist, kann dieselbe
geplant sein, um ein System zu verwenden, bei dem zwei niedrigere
Bits für
den Typ der Markierung (Markierung) verwendet werden. 26 zeigt
ein Beispiel des Systems zum Verifizieren des Markierungstyps durch
die MarkierungsID. Das heißt,
wenn die Kombination der niedrigeren zwei Bits in 26 00
ist, stellt die Markierungs-ID die Zukunft (Zukunft) des Metaraums
mLokal dar. Wenn andererseits die Kombination der niedrigeren zwei
Bits 01 ist, stellt die Markierungs-ID die Fortsetzung (Fortsetzung)
des Metaraums mAnsteuer dar. Im Gegensatz zu 21 zeigt 27 ein OMT,
bei dem lediglich die Markierungs-ID (MID) erzeugt wird, ohne den
Gegenstand der Markierung zu verwenden, und die Markierungsattribute
in dieser Markierungs-ID (MID) umfasst sind. In 27 sind C1
und C2 die gleichen wie dieselben, die in 21 gezeigt
sind. Bei diesem Fall besteht keine Notwendigkeit, einen Markierungsbereich
in dem Speicher zu sichern, wodurch Speicherbereich gespart wird. Obwohl
bei dem vorliegenden Ausführungsbeispiel die
niedrigeren zwei Bits verwendet werden, können selbstverständlich ein
einziges Bit oder höhere
oder optionale Zwischenbits verwendet sein.
-
Markierungsverwaltungssystem
-
Bei
dem vorliegenden Ausführungsbeispiel wurde,
wie im Vorhergehenden beschrieben ist, die Möglichkeit eines Verwendens
der Markierungsverwaltungssysteme (1), (2) und (3) gezeigt. Bei
jedem dieser Systeme wurde gezeigt, dass die Markierung einen Typ
als ihr Attribut hat, und der Versender (Versender) den Typ prüft, um eine
Entscheidung zu treffen, ob mindestens der Versender (Versender)
selbst die Markierung verarbeiten kann oder nicht. Im Unterschied
zu diesem Ausführungsbeispiel
kann ein solches System geplant sein, bei dem der Typ in den Markierungsattributen
nicht umfasst ist und in dem die Markierung, die durch den Versender
(Versender) verarbeitet werden kann, in dem Inneren des Versenders
(Versenders) verwaltet wird.
-
Bei
diesem System werden, wenn die Zukunft (Zukunft) der Fortsetzung
(Fortsetzung) durch den Versender (Versender) erzeugt wird, die
so erzeugten Informationen in einer Tabelle aufbewahrt, die dem
Versender (Versender) selbst gehört.
Wenn die Antwort (Antwort) oder das Anstoßen (Anstoßen) durch die Markierung geliefert
wird, tastet der Versender (Versender) die Tabelle ab. Wenn die
Markierung durch den Versender (Versender) verarbeitet werden kann,
wird die übliche
Operation der Antwort (Antwort) und des Anstoßens (Anstoßen) durchgeführt. Sonst
ist es möglich,
wie in dem Markierungsverwaltungssystem (2A), eine Abfrage durchzuführen, zu
welchem Versender (Versender) die Markierung geliefert werden kann,
oder bei anderen Objekten anzufragen, das folgende Verarbeiten fortzusetzen.
-
Bei
diesem Fall muss ein anderes Objekt als der Versender (Versender),
das die Markierungs-ID und die zugeordnete Markierung verarbeiten
kann, wie das Objekt Lieferant, beispielsweise eine Tabelle bewältigen,
wenn der Typ als das Markierungsattribut fehlt.
-
28 zeigt
das Zustandsübergangsdiagramm
des Programmfadens (Programmfaden) in dem Zeitplaner. Eine erläuterte Entwurfsanweisung des
Zeitplaners ist nun gezeigt.
-
Jeder
Programmfaden (Programmfaden) stellt jeden Zustand für eine Ausführungssteuerung dar.
Der Zeitplaner überwacht
einen Zustandsübergang
dieser Programmfaden (Programmfäden)
und bestimmt basierend auf dem Attribut, wie einer Prioritätsreihenfolge,
welcher Programmfaden als Nächstes
ausgeführt
wird.
-
Der
Zustand Schlafend (Schlafend) zeigt an, dass es in Verbindung mit
dem Programmfaden (Programmfaden) nichts auszuführen gibt. Die Nachricht (Nachricht)
befindet sich zu dieser Zeit in dem Zustand eines möglichen
Empfangs.
-
Der
Zustand einer möglichen
Ausführung (Bereit)
zeigt an, dass sich der Programmfaden (Programmfaden) in dem Zustand
einer möglichen
Ausführung
befindet und in die Warteschlange für Programmfäden (Programmfäden) in
dem Zustand einer möglichen
Ausführung
(BereiteWarteschlangen) in dem Zeitplaner gestellt (eingereiht)
wird. Das Objekt, das dem Programmfaden (Programmfaden) in dem Zustand
einer möglichen
Ausführung
(Bereit) zugeordnet ist, wird durch eine M (Metaberechnung) aufgerufen.
-
Der
Ausführzustand
(Laufend) zeigt an, dass der Programmfaden (Programmfaden) läuft.
-
Der
Zustand Wartend (Warten) zeigt den Ausführungsunterbrechungszustand
an und wird erzeugt, wenn ein WartenAuf durch die im Vorhergehenden
erwähnte
Kommunikationsfunktion des Metaraums (mLokal) vor einer Antwort
ausgegeben wird.
-
Mehrere Beispiele der Schnittstelle (API)
sind im Folgenden erklärt.
sFehler.BereitMachen (Programmfaden, Sel, Nrt)
-
Diese
Schnittstelle (API) wird durch ein Metaobjekt Versender, wie das
im Vorhergehenden erwähnte
Metaobjekt (MLokalerVersender), zum Senden der Nachricht (Nrt) zu
dem Verfahren, das durch den Wähler
(Sel) des Adressenobjekts, das durch den Programmfaden (Programmfaden)
verbunden ist, bestimmt ist, verwendet.
-
Der
Zeitplaner (Zeitplaner) bewirkt einen Übergang des Zustands des Programmfadens
(Programmfadens) aus dem Zustand Schlafend (Schlafend) in den Zustand
einer möglichen
Ausführung (Bereit),
um den Zustand in die Bereiten Warteschlangen einzugeben (einzureihen).
-
Das
Adressenobjekt wird aufgerufen, wenn der Programmfaden (Programmfaden)
zeitlich geplant wird, das heißt,
wenn der Programmfaden (Programmfaden) in dem Zustand einer möglichen
Ausführung
(Bereit) durch den Zeitplaner (Zeitplaner) ausgeführt wird.
-
Ein
sFehler zeigt unterdessen den Zustand des Resultats einer Ausführung an
und, wenn ein BereitMachen korrekt in Betrieb gewesen ist, sendet derselbe
einen Rückgabewert
(sErfolg) zurück,
der diese Wirkung anzeigt. Sonst sendet ein sFehler verschiedene
Fehler zurück.
-
sFehler-BereitMachen (Programmfaden)
-
Diese
Schnittstelle (API) wird durch einen Versender zum Starten einer
Ausführung
des Programmfadens (Programmfadens) verwendet. Der Zeitplaner (Zeitplaner)
bewirkt einen Übergang
des Zustands des Programmfadens (ProgrammfadensP) von dem Zustand
Wartend (Warten) in den Zustand einer möglichen Ausführung (Bereit),
um denselben in die bereiten Warteschlangen (Bereite Warteschlangen)
zu stellen (einzureihen). Diese Schnittstelle wird verwendet, wenn
ein Objekt, das ein WartenAuf durch die im Vorhergehenden erwähnte Metaraum-(mLokal-)Kommunikationsfunktion
ausgegeben hat und sich in dem Zustand Wartend (Warten) befindet,
durch die Antwort (Antwort), die durch ein anderes Objekt ausgegeben
wird, die Resultatsnachricht empfängt, um in einen Zustand Bereit
versetzt zu werden.
-
sFehler-WartenLassen (Programmfaden)
-
Diese
Schnittstelle (API) wird zum Stoppen einer Ausführung des Programmfadens (Programmfaden)
verwendet. Der Zeitplaner (Zeitplaner) bewirkt einen Übergang
des Programmfadens (Programmfaden) von dem Zustand einer möglichen
Ausführung (Bereit)
in den Zustand Wartend (Warten), um denselben aus den Warteschlangen
in den Bereiten Warteschlangen zu entfernen (auszureihen). Jeder
Versender muss unterdessen diese Schnittstelle nicht aufrufen, um
eine Ausführung
des Basisobjekts zu stoppen. Dies liegt daran, dass der Zustand
bereits in den Zustand Wartend (Warten) geändert wurde, wenn das Basisobjekt
unter Verwendung der im Vorhergehenden erwähnten M (Metaberechnung) den Versender
aufruft.
-
sFehler-SchlafendMachen (Programmfaden)
-
Diese
Schnittstelle (API) wird durch den Versender zum Stoppen einer Ausführung des
Programmfadens (Programmfadens) verwendet. Der Zeitplaner (Zeitplaner)
bewirkt einen Übergang
des Programmfadens (Programmfadens) von dem Zustand einer möglichen
Ausführung
(Bereit) in den Zustand Schlafend (Schlafend), um denselben aus
den Warteschlangen in den Bereiten Warteschlangen zu entfernen (auszureihen).
-
Der
Zustand des Objekts, wie von dem Versender aus gesehen, oder des
zugeordneten Programmfadens wird unterdessen in einen Zustand Schlafend
(Schlafend), einen Zustand einer möglichen Ausführung (Bereit)
und einen Zustand Wartend (Warten) klassifiziert. Dies liegt daran,
dass der Versender nicht wissen muss, welches von mehreren Objekten
in dem Zustand einer möglichen
Ausführung
in der CPU läuft.