DE3937532C2 - Mehrprozessoranlage - Google Patents
MehrprozessoranlageInfo
- Publication number
- DE3937532C2 DE3937532C2 DE3937532A DE3937532A DE3937532C2 DE 3937532 C2 DE3937532 C2 DE 3937532C2 DE 3937532 A DE3937532 A DE 3937532A DE 3937532 A DE3937532 A DE 3937532A DE 3937532 C2 DE3937532 C2 DE 3937532C2
- Authority
- DE
- Germany
- Prior art keywords
- module
- data
- input
- program
- output
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F7/00—Methods or arrangements for processing data by operating upon the order or content of the data handled
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/36—Software reuse
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Devices For Executing Special Programs (AREA)
Description
Die Erfindung bezieht sich auf eine Mehrprozessoranlage, die
mit modular aufgebauter Software betreibbar ist.
Mit der Entwicklung und dem Testen von
Programmen befaßt sich allgemein: Gewald et al.: "Software Engineering",
Oldenburg Verlag, 3. Aufl., 1982, S. 152-173.
Bei einem herkömmlichen Software-Entwicklungsverfahren wird
zunächst ein Modulaufbau des gesamten Softwaresystems be
stimmt, so daß auf der Grundlage dieses Aufbaus eine innere
Bearbeitung eines jeden Software-Moduls möglich ist, und
zwar in Abhängigkeit einer Rangfolge von Moduloperationen,
um auf diese Weise die Programmierung der Module zu erhal
ten.
Bleibt daher ein Teil im Modulaufbau der Gesamtsystem-Soft
ware unbestimmt, so lassen sich Aufbau und Entwicklung der
jeweiligen Software-Module nicht starten. Treten darüber
hinaus Änderungen während des Aufbaus und der Entwicklung
eines Software-Moduls auf, so wird der Modulaufbau des ge
samten Software-Systems durch diese Änderungen beeinflußt.
Dies kann Modifikationen der Software-Module erforderlich
machen, die in einigen Fällen bereits vollständig entwic
kelt worden sind.
Es wurde daher bereits ein Verfahren zum Programmieren der
Software-Module in einer Sequenz entwickelt, die von einer
Flußrichtung einer Initiierungssteuerung abhängt, die vom
flußaufwärts liegenden Ende zum flußabwärts liegenden Ende
oder im umgekehrter Richtung verläuft, so daß eine Modifi
kation eines Software-Moduls, wenn überhaupt, ein flußauf
wärts oder flußabwärts liegendes Software-Modul beeinflus
sen kann. Mit diesem Verfahren ist es jedoch nicht möglich,
die Programmgestaltung zur Bildung der jeweiligen Software-
Module unabhängig voneinander und gleichzeitig durchzufüh
ren.
Es sei darauf hingewiesen, daß eine Einrichtung zur Durch
führung des herkömmlichen Verfahrens z. B. in der JP-A-61-
208540 beschrieben ist.
In Übereinstimmung mit der herkömmlichen Technologie er
folgt die Programmgestaltung in sogenannter Top-Down-Weise,
also von der Spitze zur Basis. Insbesondere wird zunächst
der Aufbau des Gesamtsystems bestimmt, um auf diese Weise
die Module auf der Grundlage des Software-Auf
baus zu erhalten, wodurch der Reihe nach Programme erzeugt
werden.
Das hat zur Folge, daß es in einem distributierten Compu
tersystem schwierig ist, Software-Aufbau und Software-Ent
wicklung für jedes Modul unabhängig und gleichzeitig durch
zuführen, so daß sich die Software-Produktivität nicht so
ohne weiteres erhöhen läßt.
Der Erfindung liegt die Aufgabe zugrunde, eine Mehrprozessoranlage
zu schaffen, mit deren Hilfe sich die je
weiligen Software-Module unabhängig voneinander und gleich
zeitig aufbauen bzw. entwickeln lassen und dann gemeinsam ablaufen können.
Die Lösung dieser Aufgabe gelingt mit
der in Anspruch 1 angegebenen Anlage. Sie eignet sich zur Anwendung in einem
System, in dem der Modulaufbau des
gesamten Software-Systems jedesmal dann erneuert bzw.
auf den neuesten Stand gebracht wird, wenn irgendein Software-
Modul gebildet ist, so daß sich durch Aufbau und Entwick
lung der Software-Module in einer sogenannten "Bottom-up"-
Weise die Software-Produktivität verbessern läßt und die im
Zusammenhang mit der herkömmlichen Technologie erwähnten
Nachteile nicht mehr auftreten.
Bei einem solchen
Programmierungsverfahren werden zur Bildung ei
nes distributierten Software-Systems mit einer Mehrzahl von
Software-Modulen, die miteinander über einen Nachrichtenda
tenaustausch kombiniert sind, jedesmal dann, wenn ein Soft
ware-Modul gebildet worden ist, für welches Eingabe-/Ausga
bedatenposten bestimmt worden sind, Nachrichtendaten zwi
schen dem Software-Modul und den zuvor erzeugten Software-
Modulen geprüft, um die Integrität des Inhalts der Nach
richtendaten überprüfen zu können, wobei ferner eine Bezie
hung zwischen einem Software-Modul, das die Nachrichtenda
ten erzeugt, und einem Software-Modul, das die Nachrichten
daten verwendet, geprüft wird. Die Software-Modul-Verbin
dung oder Software-Modul-Trennung erfolgt zum Zwecke des
Aufbaus des distributierten Software-Systems. Das Verfahren
zeichnet sich dadurch aus, daß die Anzahl der Nachrichten
datenposten und die Anzahl der Software-Module, durch die
das gesamte distributierte Software-System aufgebaut wird,
wahlweise bzw. beliebig eingestellt werden können.
Werden Software-Module
miteinander kombiniert bzw. verbunden, so werden in Übereinstimmung mit der Erfindung von den
Ausgangsdaten der Software-Module, die vor der Verbindung
vorliegen, Ausgangsdaten, die nicht zu einem Prozessor oder
einer Prozessoreinrichtung übertragen werden sollen, die
sich von denjenigen Prozessoreinrichtungen unterscheidet,
in denen die Software-Module nach der Verbindung gespei
chert werden, als Rundfunkunterdrückungscodetabelle regi
striert. Anschließend wird bei einer Programmausführung mit
Hilfe der nach der Verbindung erhaltenen Software-Module
nur ein Selbstempfangsprozeß für die registrierten Aus
gangsdaten durchgeführt.
Wenn ein Programm durch Verbindung der Software-Module ge
bildet wird, so werden ein Eingangsverarbeitungsmodul, ein
Operationsverarbeitungsmodul und ein Ausgangsverarbeitungs
modul eines Software-Modulprogranms vor der Verbindung ge
sammelt, um ein Eingangsverarbeitungsmodul, ein Operations
verarbeitungsmodul und ein Ausgangsverarbeitungsmodul eines
Programmcodes zu bilden.
Für den Fall, daß unter Bezugnahme auf den Inhalt von Nach
richtendaten eine Einschlußbeziehung gefunden wird, können
die passenden Datenposten miteinander kombiniert bzw. ver
bunden werden.
Da die kombinierten Nachrichtendaten die Inhalte vor der
Verbindung enthalten und die Eingabe-/Ausgabedaten der
Software-Module gesichert sind, läßt sich die Anzahl der
Nachrichtendaten reduzieren und die Anzahl der Module im
Gesamtsystem unverändert aufrechterhalten.
Darüber hinaus lassen sich von der Einschlußbeziehung Nach
richtendaten separieren. Durch Behandlung der separierten
Nachrichtendatenposten als individuelle Posten oder durch
Verbinden der separierten Nachrichtendatenposten können die
Eingabe-/Ausgabedaten für die Software-Module geschützt
werden. Das bedeutet, daß sich die Anzahl der Nachrichten
daten erhöht und die Anzahl der Module im Gesamtsystem un
verändert bleibt.
Ferner lassen sich anhand von Beziehungen zwischen der Auf
stellung und der Verwendung der Nachrichtendaten die pas
senden Software-Module miteinander verbinden bzw. kombinie
ren.
Werden insbesondere die Nachrichtendaten nur durch ein
Software-Modul erzeugt und werden diese Nachrichtendaten
nur durch ein Software-Modul verwendet, so lassen sich das
datenerzeugende und das datenverwendende Modul zu einem
Software-Modul miteinander verbinden.
Da in diesem Fall die Nachrichtendaten gestrichen werden,
vermindert sich die Anzahl der Nachrichtendaten und die An
zahl der Software-Module.
Werden dagegen die Nachrichtendaten durch eine Mehrzahl von
Software-Modulen verwendet, so können diese Module mitein
ander kombiniert bzw. verbunden werden.
Dadurch bleibt die Anzahl der Nachrichtendaten unverän
dert, während sich die Anzahl der Software-Module verrin
gert.
Sollen kombinierte bzw. verbundene Software-Module wieder
in die ursprünglichen Software-Module zurückgeführt bzw.
getrennt werden, so wird eine Software-Modultrennung durch
geführt.
Wie oben beschrieben, läßt sich der gesamte Programmaufbau
beliebig verändern, und zwar durch Verbinden und Trennen
der das System aufbauenden Software-Module und Nachrichten
daten.
Ein Ausführungsbeispiel der Erfindung wird nachfolgend unter Bezugnahme auf die
Zeichnung näher beschrieben. Es zeigt
Fig. 1 ein Flußdiagramm eines Modulaufbau-Prüfprogramms,
Fig. 2 ein Funktionsdiagramm eines Programmaufbau-Unter
stützungssystems,
Fig. 3 eine Darstellung zur Erläuterung der Struktur ei
ner Inhaltscodetabelle in Fig. 2,
Fig. 4 eine Darstellung zur Erläuterung der Struktur ei
ner Modultabelle in Fig. 2,
Fig. 5 eine Darstellung zur Erläuterung der Struktur ei
ner Datenpostentabelle in Fig. 2,
Fig. 6 eine Darstellung zur Erläuterung der Struktur ei
ner historischen Verbindungstabelle in Fig. 2,
Fig. 7 ein Flußdiagramm eines Definitionseingabeprogramms
von Fig. 2,
Fig. 8 ein Flußdiagramm eines Modulaufbau-Erneuerungspro
gramms von Fig. 2,
Fig. 9 ein Funktionsdiagramm eines
Systems nach einem Ausführungs
beispiel der Erfindung,
Fig. 10 eine Darstellung zur Erläuterung des Aufbaus einer
Rundfunkunterdrückungs-Inhaltscodetabelle in Fig.
9,
Fig. 11 eine Darstellung zur Erläuterung eines Modulver
bindungsbetriebs bei einer Programmausführung ge
mäß dem Ausführungsbeispiel der Erfindung,
Fig. 12 ein Flußdiagramm des Rundfunkunterdrückungspro
gramms von Fig. 9,
Fig. 13 ein Flußdiagramm zur Erläuterung des Betriebs der
Schnittstellenschaltung (Interface) in Fig. 9,
Fig. 14A und 14B Darstellungen zur Erläuterung eines Pro
grammverbindungsbetriebs im Ausführungs
beispiel der Erfindung, und
Fig. 15 ein Flußdiagramm des Modulverbindungsprogramms in
Fig. 9.
Die Fig. 2 zeigt ein Funktionsdiagramm eines allgemeinen Programmaufbau-
Unterstützungssystems, auf das die Erfindung, wie unten unter bezug auf
Fig. 9 erläutert, anwendbar ist.
Das System nach Fig. 2 enthält einen Prozessor oder eine
Prozessoreinrichtung 1, eine Inhaltscodetabelle 2, eine Mo
dultabelle 3, eine Datenpostentabelle 4, eine Tabelle 5 für
historische Verbindungen, einen Definitionseingabeprogramm-
Speicherbereich 6, einen Modulaufbau-Prüfprogramm-Speicher
bereich 7, einen Modulaufbau-Erneuerungsprogramm-Speicher
bereich 8 und einen Bearbeitungsmodul-Speicherbereich 9.
Der Bearbeitungsmodul-Speicherbereich 9 dient zur Speiche
rung eines Modulbearbeitungsprozedur-Programms.
Obwohl in der Fig. 2 nicht dargestellt, kann der Prozessor
1 auch mit einer Kathodenstrahlröhre (CRT) verbunden sein.
Die Fig. 3 zeigt einen beispielsweisen Aufbau der Inhalts
codetabelle 2 von Fig. 2. Die Inhaltscodetabelle 2 nach
Fig. 3 enthält einen Inhaltscode 21, Datenpostennummern 22
und Datenpostennamen 23.
Der Inhaltscode 21 kennzeichnet einen Inhalt von Nachrich
tendaten, die durch die Software-Module ausgetauscht wer
den, um die Datenpostennamen 23 zu identifizieren, deren
Nummer durch die Datenpostennummer 22 spezifiziert ist.
Dieses Format wird wiederholt für jeden Inhaltscode 21 ver
wendet.
Die Fig. 4 zeigt ein Diagramm zur Erläuterung des Aufbaus
der Modultabelle 3 von Fig. 2. Dieser Formataufbau wird für
jedes Modul wiederholt spezifiziert.
Die Struktur von Fig. 4 enthält eine Eingabeinhaltscodenum
mer 31, einen Eingabeinhaltscode 32, eine Ausgabeinhalts
codenummer 33, einen Ausgabeinhaltscode 34, eine Eingabeda
tenpostennummer 35, einen Eingabedatenpostennamen 36, eine
Ausgabedatenpostennummer 37, einen Ausgabedatenpostennamen
38, einen Modulnamen 39, eine Bearbeitungsmodul-Speicher
adresse 40 und eine Bearbeitungsmodullänge 41.
Ein mit dem Modulna
men 39 bezeichnetes Software-Modul enthält ein Bearbeitungsmodul,
das die Bearbeitungsmodullänge 41 in Bytes aufweist und
unter einer Adresse gespeichert ist, die durch die Bearbei
tungsmodul-Speicheradresse 40 bestimmt ist.
Weiterhin ist der unentbehrliche Eingabeinhaltscode 32
(Eingangsinhaltscode) für ein Software-Modul nur die Einga
beinhaltscodenummer 31. Für die Ausgabe existieren die Aus
gabeinhaltscodes 34, deren Nummer durch die Ausgabeinhalts
codenummer 33 bestimmt ist. Der Inhalt von Eingabeinhalts
code 32 und Ausgabeinhaltscode 34 kennzeichnen eine Daten
spezifikation der Nachrichtendaten.
Die Basis für die Software-Modulbearbeitung bestimmt sich
durch eine Gruppe von Daten, die jeweils die Eingabedaten
postennamen 36, deren Nummer durch die Eingabedatenposten
nummer 35 spezifiziert ist, und die Ausgabedatenpostennamen
38, deren Nummer durch die Ausgabedatenpostennummer 37 spe
zifiziert ist, repräsentieren.
Die Fig. 5 dient zur Erläuterung der Struktur der Datenpo
stentabelle 4 von Fig. 2.
Die Datenpostentabelle 4
zeigt den Inhalt eines jeden Datenpostennamens 23 der In
haltscodetabelle 2 von Fig. 3 an und enthält eine Datenein
heitslänge 42, eine Nummer bzw. Anzahl von Elementen in ei
nem Feld oder eine Feldelementanzahl 43, einen Datencode 44
und ein Anwesenheits-/Abwesenheitszeichen 45, wobei die
Elemente 42 bis 45 jeweils Attribute des Datenpostennamens
23 sind. Diese Posten werden wiederholt für jeden Datenpo
stennamen 23 spezifiziert.
Die Fig. 6 zeigt ein Diagramm zur Erläuterung des Aufbaus
der in Fig. 2 vorhandenen Tabelle 5 zur Speicherung histo
rischer Verbindungen (combining historical table).
Der Aufbau nach Fig. 6 enthält einen Modulnamen 51 vor der
Verbindung und einen Modulnamen 52 nach der Verbindung.
In diesem Beispiel werden der Modulname 51 vor
der Verbindung und der Modulname 52 nach der Verbindung als
ein Paar behandelt, um auf diese Weise die passenden Daten
der Modultabelle 3 zu sichern, die dem Modul vor der Ver
bindung zugeordnet sind und um den Zustand des Moduls vor
der Verbindung wieder herstellen zu können, wenn der ver
bundene Zustand aufgelöst bzw. freigegeben wird.
Die Fig. 7 zeigt ein Flußdiagramm des Definitionseingabe
programms, das im Definitionseingabeprogramm-Speicherbe
reich 6 von Fig. 2 gespeichert ist.
Sollen Eingabe-/Ausgabedaten
in einem Software-Modul definiert werden, so sucht das Sy
stem einen Inhaltscode 21, der die Eingabe- und Ausgabeda
tenpostennamen 36 und 38 enthält, die in Übereinstimmung
mit dem Moduleinheitsformat gemäß Modultabelle 3 geliefert
worden sind (Schritt 701).
Genauer gesagt erfolgt unter Verwendung eines jeden Einga
bedatenpostennamens 36 von Fig. 4 als Schlüssel ein Wieder
aufsuchvorgang in der Inhaltscodetabelle 2 von Fig. 3.
Wird als Ergebnis kein Posten gefunden, der zu der Bedin
gung des Schlüssels paßt, so wird ein neuer Inhaltscode 21
bestimmt. Der Code 21 wird mit dem Datenpostennamen 23 ge
paart, der zu ihm gehört, um auf diese Weise Daten zu pro
duzieren, die in der Inhaltscodetabelle 2 gespeichert wer
den (Schritt 702).
Fehlt darüber hinaus der Datenpostenname 23 in der Datenpo
stentabelle 4 von Fig. 5 (Schritt 703), so wird ein den Da
tenpostennamen 23, die Dateneinheitslänge 42, die Feldele
mentanzahl 43, den Datencode 44 und den Anwesenheits/Abwe
senheits-Code 45 enthaltender Satz, dessen Elemente als De
finitionseingaben geliefert worden sind, in einer Gruppe zu
der Datenpostentabelle 4 gespeichert (Schritt 704).
Im Anschluß daran wird auf der Grundlage der Datenpostenna
men 23 sowie der Eingabe- und Ausgabedatenpostennamen 36
und 38, die mit dem Inhaltscode 21 verbunden sind, eine Ra
tionalitätsprüfung (Verträglichkeitsprüfung) durchgeführt,
und zwar für die Einschlußbeziehung (Schritt 705). Durch
die Rationalitätsprüfung wird unter anderem bestimmt, ob
die Eingangs- und Ausgangsdatenpostennamen 36 und 38 in den
Datenpostennamen 23 vorhanden sind, die zum Inhaltscode 21
gehören, und ferner bestimmt, ob eine Inkonsistenz exi
stiert zwischen den Attributen der Dateneinheitslänge 42,
der Feldelementanzahl 43, des Datencodes 44 und des Anwe
senheits/Abwesenheitscodes 45.
Liefert die Rationalitätsprüfung ein befriedigendes Ergeb
nis, so werden die Inhaltscodetabelle 2, die Modultabelle 3
und die Datenpostentabelle 4 erneuert bzw. auf den neuesten
Stand gebracht (Schritt 706).
Die Fig. 1 zeigt ein Flußdiagramm des Modulaufbau-Prüfpro
gramms 7 von Fig. 2.
Durch Verwendung der
Inhaltscodetabelle 2 werden die Datenpostennamen 23, die zum In
haltscode 21 gehören, wechselseitig mit dem Inhaltscode 21
verglichen, um somit die Einschlußbeziehung (inclusion
relationship) zu überprüfen (Schritt 101).
Sind z. B. die Datenpostennamen 23 Elemente eines Satzes
und ist der Inhaltscode 21 ein Name des Satzes, so lassen
sich die Inhaltscodes 21 möglicherweise zu einem Inhalts
code einer Verbindung von Sätzen kombinieren, wenn eine Re
lation für eine Verbindung von Sätzen gültig ist.
Die Inhaltscodes 21 können darüber hinaus auch, wenn eine
Beziehung für eine Teilmenge mit Datenpostennamen 23 als
Elemente gefunden wird, zur Bildung einer Teilmenge mit
einander verbunden werden.
Existiert also eine Verbindungsmöglichkeit (Schritt 102),
so wird der Inhalt der Verbindungsmöglichkeit auf der
(nicht dargestellten) CRT abgebildet (Schritt 103).
Als nächstes erfolgt eine Prüfung für die Trennung des In
haltscodes (Schritt 104).
Existiert also eine Beziehung für eine Vereinigung von Sät
zen zwischen Sätzen mit Datenpostennamen 23 als Elemente
dieser Sätze zwischen Inhaltscodes 21, so läßt sich eine
Trennoperation durchführen, um Verbindungsteilsätze zu er
halten.
Der Inhalt der Trennmöglichkeit wird auf der CRT abgebildet
(Schritte 105 und 106).
Anschließend wird die Möglichkeit einer Modulverbindung ge
prüft (Schritt 107).
Sind alle Ausgabeinhaltscodes 34 in einem Software-Modul
identisch mit allen Eingabeinhaltscodes 34 eines anderen
Software-Moduls, so können in der Modultabelle 3 diese
Software-Module möglicherweise miteinander kombiniert wer
den.
Ferner wird die Möglichkeit der Software-Modulverbindung
auf der CRT dargestellt (Schritte 108 und 109).
Sodann überprüft das System die Auflösung bzw. Freigabe ei
ner Modulverbindungsspezifikation (Schritt 110).
Eine Modulverbindungsauflösung bzw. -freigabe bedeutet eine
Trennung von Software-Modulen, derart, daß ein verbundenes
Software-Modul in das Original-Modul zurücküberführt wird.
Ist es also möglich, eine Modulverbindung freizugeben bzw.
aufzulösen (Schritt 111), so wird der Inhalt der Tabelle 5
mit historischen Verbindungen (früheren Verbindungen) auf
der CRT abgebildet (Schritt 112).
Die Fig. 8 zeigt ein Flußdiagramm des Modulaufbau-Erneue
rungsprogramms im Speicherbereich 8 von Fig. 2.
Wird der Aufbau des gebilde
ten Software-Moduls erneuert, so wird zunächst geprüft, ob
der Inhaltscode 21 verbunden oder getrennt werden soll
(Schritt 801).
Soll insbesondere der Inhaltscode 21 verarbeitet werden, so
bestimmt das System die Durchführung der Verbindung oder
Trennung (Schritt 802) zwecks Erneuerung der Inhaltscodeta
belle 2 in Abhängigkeit vom Inhalt des Ergebnisses (Schrit
te 803 und 804).
Ist das zu bearbeitende Objekt ein Software-Modul (Schritt
801) und soll die Verbindung erfolgen (Schritt 805), so
wird die Modultabelle 3 erneuert (Schritt 807). Sodann wird
der Inhalt des Software-Moduls vor der Verbindung im Spei
cher 5 für historische Verbindungen gesichert (Schritt
808).
Andererseits werden für die Trennung bzw. Auflösung der
Verbindungsspezifikation (Schritt 805) die passenden Daten
vom Speicher 5 für historische Verbindungen in die Modulta
belle 3 zurückgeliefert um wiederum das Original-Modul zu
erstellen (Schritt 806).
Die Fig. 9 zeigt ein Funktionsdiagramm eines Programmauf
bau-Unterstützungssystems in Übereinstimmung mit einem
Ausführungsbeispiel der Erfindung.
Das System in Fig. 9 enthält einen Rundfunkunterdrückungs
programm-Speicherbereich 10 (broadcast suppress program
storing area), ein Interface 11 (Schnittstellenschaltung)
zur Datenverbindung mit anderen Computern, einen Modulver
bindungsprogramm-Speicherbereich 12, eine Rundfunkunter
drückungs-Inhaltscodetabelle 13 (broadcast suppress content
code table), einen Übertragungsweg 14 und andere Tabellen
und Programmspeicherbereiche, die identisch sind mit denen
des Beispiels nach Fig. 2.
Wird beim vorliegenden Ausführungsbeispiel eine Software-
Modul-Verbindungsbedingung in den Schritten 107 bis 109 des
Flußdiagramms nach Fig. 1 erfüllt, so erfolgt eine Modul
verbindung bei einer Programmausführung. Es werden also Mo
dule miteinander kombiniert, um ein Programm zu erzeugen.
Die Fig. 10 zeigt ein Diagramm zur Erläuterung des Aufbaus
der Rundfunkunterdrückungs-Inhaltscodetabelle 13 von Fig.
9.
Beim vorliegenden Ausführungsbeispiel wird die Rundfunkun
terdrückungs-Inhaltscodetabelle 13 in einem Fall verwendet,
bei dem ein von einem Software-Modul erzeugter Inhaltscode
nicht zu anderen Computern geliefert wird, so daß ein soge
nannter Selbstempfangsbetrieb vorliegt, um den Inhaltscode
als Rundfunkunterdrückungs-Inhaltscode 61 speichern zu kön
nen. Wird ein Datenposten des Inhaltscodes, der in der
Rundfunkunterdrückungs-Inhaltscodetabelle 13 gespeichert
ist, ausgegeben, so wird dem Interface 11 befohlen, den
Selbstempfangsbetrieb durchzuführen.
Die Fig. 11 zeigt ein Diagramm zur Erläuterung des Modul
verbindungsbetriebs bei einer Programmausführung in diesem
Ausführungsbeispiel der Erfindung.
Dieses Ausführungsbeispiel enthält ein Modul P71 vor der
Verbindung, welches als Eingabe Daten mit einem Inhaltscode
S73 empfängt, um einen Inhaltscode m75 und einen Inhalts
code n76 zu erzeugen. Ferner enthält das System ein Modul
Q72 vor der Verbindung, das als Eingabe Datenposten vom
Inhaltscode n75 und vom Inhaltscode m76 empfängt, um ei
nen Inhaltscode t74 zu bilden.
Ist bei diesem Betrieb eine Modulverbindungsbedingung in
den Schritten 107 bis 109 von Fig. 1 erfüllt, so erfolgt
die Verarbeitung bei einer Programmausführung, derart, daß
dann, wenn der Inhaltscode n75 und der Inhaltscode m76
als Rundfunkunterdrückungscodes 61 registriert werden, ein
Modul PQ70 nach der Verbindung erzeugt wird, das nach dem
Verbindungsbetrieb als Eingang den Inhaltscode s73 emp
fängt, um den Inhaltscode t74 zu erzeugen.
Die Fig. 12 zeigt ein Flußdiagramm des Rundfunkunterdrüc
kungsprogramms im Speicherbereich 10 von Fig. 9.
Wird bei diesem Ausführungsbeispiel eine Modulverbindungs
bedingung in den Schritten 107 bis 109 von Fig. 1 erfüllt,
so führt das Rundfunkunterdrückungsprogramm 10 einen Wie
deraufsuchvorgang in der Rundfunkunterdrückungs-Inhalts
codetabelle 13 durch, wobei als Schlüssel der Inhaltscode
der Daten verwendet wird, die gesendet bzw. übertragen wer
den sollen (Schritt 1201).
Wurde in der Tabelle 13 kein passender Inhaltscode gespei
chert, so wird als Ergebnis dem Interface 11 befohlen, den
Inhaltscode über den Übertragungsweg 14 zu anderen Compu
tern zu senden (Schritt 1203).
Wird dagegen der Inhaltscode aufgefunden, so erfolgt keine
Übertragung zu den externen Computern.
Die Fig. 13 zeigt ein Flußdiagramm zur Erläuterung der Ar
beitsweise vom Interface 11.
Befiehlt im vorliegenden Ausführungsbeispiel das im Spei
cherbereich 10 gespeicherte Rundfunkunterdrückungsprogramm
eine Übertragung von Daten vom Interface 11 (Schritte 1301
und 1302), so werden die Daten über die Übertragungsroute
14 zu den externen Einrichtungen gesendet (Schritt 1303).
Wird dagegen keine Übertragung befohlen, so erfolgt keine
Datenübertragung zu den externen Einrichtungen.
Anschließend werden die passenden Daten als Selbstempfangs
posten des eigenen Systems verarbeitet (Schritt 1304).
Infolge des oben beschriebenen Betriebs gibt das Modul P71
gemäß Fig. 11 vor der Verbindung den Inhaltscode m75 und
den Inhaltscode n76 aus. Diese Codes werden nicht zu den
anderen Computern übertragen, sondern nur durch das Modul
Q72 vor der Verbindung empfangen.
Das bedeutet, daß die anderen Computer nach der Verbindung nur das Modul PQ70
erkennen, das den Inhaltscode s73 emp
fängt und den Inhaltscode t74 erzeugt bzw. ausgibt. Insbe
sondere werden die vor der Verbindung vorhandenen Module
P71 und Q72 nicht erkannt.
Die Fig. 14 zeigt ein Diagramm zur Erläuterung der Pro
grammverbindung in diesem Ausführungsbeispiel nach der Er
findung, während die Fig. 15 ein Flußdiagramm des Modulver
bindungsprogramms in Fig. 9 ist.
Die Fig. 14A zeigt Moduleinschlußbeziehungen vor und nach
einer Modulverbindung.
Im vorliegenden Fall empfängt ein Modul A82 vor der Ver
bindung Daten eines Inhaltscodes P84 zwecks Erzeugung ei
nes Inhaltscodes q85. Dagegen empfängt ein Modul B83 vor
der Verbindung Daten des Inhaltscodes P84 zur Erzeugung
eines Inhaltscodes r86.
Durch Kombination dieser beiden Software-Module entsteht
ein Modul AB81 nach der Verbindung, das Daten des Inhalts
codes P84 empfängt und die Inhaltscodes q85 und r86 er
zeugt bzw. ausgibt.
Die Fig. 14B zeigt ein Programmbeispiel vor und nach einer
Software-Modulverbindung, bei der die vor der Verbindung
vorhandenen Module A82 und B83 nach Fig. 14A zur Erzeu
gung eines Programms miteinander kombiniert werden.
Sind die Software-Module nach Fig. 14A zur Bildung eines
Programms miteinander kombiniert worden, so werden ein Ein
gangsmodul A92, eine Modul-A-Verarbeitung 93 und ein Aus
gangsmodul A94, das ein Programm 98 des Moduls A vor der
Verbindung darstellt, mit Hilfe des Modul-Verbindungspro
gramms so verarbeitet bzw. kombiniert, daß ein Eingangsmo
dul 95, eine Modul-B-Verarbeitung 96 und ein Ausgangsmodul
B97 erhalten werden, das ein Programm 97 des Moduls B vor
der Verbindung darstellt.
Entsprechend der Fig. 15 erfolgen eine Kombination von Be
fehlsteilen der Eingangsmodule (Schritt 1501), eine Kombi
nation der Bearbeitungsmodule (Schritt 1502) und eine Kom
bination der Ausgangsmodule (Schritt 1503), um in einfacher
Weise ein Programm des Moduls AB zu erzeugen, das nach der
Kombination erhalten wird.
Somit läßt sich jedes Soft
ware-Modul, für das Eingabe-/Ausgabedatenposten bestimmt
worden sind, unabhängig aufbauen und so verarbeiten, daß
der Aufbau des Gesamtsystems erneuert bzw. auf den neuesten
Stand gebracht werden kann, während die Programmierarbeit
durchgeführt wird. Die Software-Module lassen sich gleich
zeitig erzeugen, so daß sich eine erhöhte Software-Produk
tivität ergibt.
Claims (6)
1. Mehrprozessoranlage mit mehreren Prozessoren (1), deren
jeder mindestens einen Modul (in 9) eines Programms ausführt und
über eine Schnittstelle (11) mit einem Datenübertragungskanal
(14) verbunden ist, wobei die Module zum Empfang einer Eingangsdatennachricht
und zur Abgabe einer Ausgangsdatennachricht
ausgelegt sind,
dadurch gekennzeichnet,
daß jeder Prozessor die Eingangs- und Ausgangsdaten seiner
Module in einer Datentabelle (3) eingespeichert hat,
diese nach Daten durchsucht, die als Ausgangsdaten (75, 76)
mindestens eines ersten Moduls (71) und als Eingangsdaten
(75, 76) mindestens eines zweiten Moduls (72) dienen, und bei
Vorliegen derartiger Daten eine Kennmarke (61) des ersten
Moduls (71) in einer Unterdrückungstabelle (13) setzt und bei
gesetzter Kennmarke (61) die Aussendung der Ausgangsnachricht
des ersten Moduls (71) durch die Schnittstelle (11) verhindert,
während im anderen Fall die Aussendung erfolgt.
2. Anlage nach Anspruch 1, dadurch gekennzeichnet, daß der
Prozessor die Kennmarke (61) nur dann in der Unterdrückungstabelle
(13) setzt, wenn die Ausgangsnachricht nicht von
einem in einem anderen Prozessor ausgeführten Programm-Modul
benötigt wird.
3. Anlage nach Anspruch 1 oder 2, gekennzeichnet durch
einen Speicher mit einer Datentabelle (3) zur Speicherung der
Eingangs- (32) und der Ausgangsnachrichten (34) jedes Moduls,
wobei der Prozessor die Datentabelle absucht, um einen dritten
Modul (51, 71) mit einem vierten Modul (51, 72), dessen
Eingangsnachricht (75, 76) mit der Ausgangsnachricht (75, 76)
des dritten Moduls übereinstimmt, zur Bildung eines fünften
Moduls (52, 70) zu verbinden, bevor ein Lademodul des Programms
erzeugt wird.
4. Anlage nach Anspruch 3, dadurch gekennzeichnet, daß der
Speicher eine History-Tabelle (5) zur Aufnahme von Moduldaten
des dritten (51, 71) und des vierten Moduls (51, 72) aufweist,
wobei die Modulaten jeweils einzelnen Modulen zugeordnet sind
und deren Eingangs- (32) und Ausgangsnachrichten (34) enthalten.
5. Anlage nach Anspruch 3 oder 4, dadurch gekennzeichnet, daß
der Prozessor den dritten und den vierten Modul nach Programmteilen
jeweils hinsichtlich Eingabeverarbeitung, Operationsbetrieb
und Ausgabeverarbeitung verbindet (Fig. 14B, Fig. 15).
6. Anlage nach Anspruch 3 oder 4, dadurch gekennzeichnet,
daß der Prozessor eine Zerlegung des fünften Moduls (52, 70)
in den dritten (51, 71) und den vierten Modul (51, 72) anhand
der History-Tabelle (5) durchführt, wenn die Verbindung der
Module aufgelöst werden soll, bevor ein neuer Lademodul des
Programms erzeugt wird.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP63284988A JPH02130631A (ja) | 1988-11-11 | 1988-11-11 | ソフトモジュールの統合分離方式 |
Publications (2)
Publication Number | Publication Date |
---|---|
DE3937532A1 DE3937532A1 (de) | 1990-05-17 |
DE3937532C2 true DE3937532C2 (de) | 1994-05-19 |
Family
ID=17685685
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE3937532A Expired - Lifetime DE3937532C2 (de) | 1988-11-11 | 1989-11-10 | Mehrprozessoranlage |
Country Status (4)
Country | Link |
---|---|
JP (1) | JPH02130631A (de) |
KR (1) | KR930001070B1 (de) |
CN (1) | CN1027324C (de) |
DE (1) | DE3937532C2 (de) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE19509603C1 (de) * | 1995-03-16 | 1996-05-23 | Siemens Ag | Verfahren zum Abspeichern von Systemdaten eines Kommunikationssystems |
DE19527808C2 (de) * | 1995-07-28 | 1999-04-01 | Siemens Ag | Verfahren zum Modifizieren der Softwareprozeduren eines Kommunikationssystems |
CN100439566C (zh) * | 2004-08-06 | 2008-12-03 | 贵阳铝镁设计研究院 | 大面不等电式五点进电母线配置装置 |
CN100451177C (zh) * | 2004-08-06 | 2009-01-14 | 贵阳铝镁设计研究院 | 非对称式槽底母线配置及电流配置方法 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS61208540A (ja) * | 1985-03-13 | 1986-09-16 | Toshiba Corp | プログラム設計支援装置 |
-
1988
- 1988-11-11 JP JP63284988A patent/JPH02130631A/ja active Pending
-
1989
- 1989-11-10 DE DE3937532A patent/DE3937532C2/de not_active Expired - Lifetime
- 1989-11-10 KR KR1019890016268A patent/KR930001070B1/ko not_active IP Right Cessation
- 1989-11-11 CN CN89108497A patent/CN1027324C/zh not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
CN1051799A (zh) | 1991-05-29 |
KR930001070B1 (ko) | 1993-02-15 |
DE3937532A1 (de) | 1990-05-17 |
KR900008376A (ko) | 1990-06-04 |
JPH02130631A (ja) | 1990-05-18 |
CN1027324C (zh) | 1995-01-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP0346801B1 (de) | Verfahren und Anordnung zur Ausführung eines Programms in einem heterogenen Mehrrechnersystem | |
DE69126587T2 (de) | Verfahren zur Verwaltung von Arbeitseinheitidentifizierern in einem verteilten Transaktionsverarbeitungssystem | |
DE69131500T2 (de) | Regelgesteuertes Transaktionsverwaltungssystem und -verfahren | |
DE68926345T2 (de) | Datenverarbeitungsnetzwerk | |
DE4235193C2 (de) | Netzwerksystem und zugehöriges Softwareverwaltungsverfahren | |
DE69322549T2 (de) | Verteilte Transaktionsverarbeitung mit einem Zwei-Phasen-Bindungsprotokoll mit erwarteter Bindung ohne Aufzeichnungspflicht | |
DE69611542T2 (de) | Verfahren und vorrichtung zum ermitteln verbindungsorientierter kommunikationsfigurationen | |
DE3382775T2 (de) | Elektronisches Dokumentenverteilnetzwerk mit gleichmässigem Datenstrom. | |
DE3852115T2 (de) | Simulationsverfahren für Programme. | |
EP0635792B1 (de) | Verfahren zur Koordination von parallelen Zugriffen mehrerer Prozessoren auf Resourcenkonfigurationen | |
DE69206917T2 (de) | Hilfsverfahren für die Entwicklung einer miteinander kommunizierender Automatengruppe | |
EP0685086B1 (de) | Einrichtung zur automatischen erzeugung einer wissensbasis für ein diagnose-expertensystem | |
DE3842289C2 (de) | Verfahren zur Entwicklung von Programmen für ein verteiltes Datenverarbeitungssystem | |
DE3416939A1 (de) | Verfahren zur steuerung von betriebseinrichtungen | |
DE3508291A1 (de) | Realzeit-datenverarbeitungssystem | |
DE4437272C2 (de) | Automatisch betriebene Datenverarbeitungsanlage | |
DE19617976A1 (de) | Kommunikationssystem mit Mitteln zum Austausch von Softwareprozessen | |
DE4104568A1 (de) | Verfahren und vorrichtung zur programmverarbeitung | |
EP2648094B1 (de) | Verfahren und system zum erzeugen eines quellcodes für ein computerprogramm zur ausführung und simulation eines prozesses | |
DE3937532C2 (de) | Mehrprozessoranlage | |
EP4002098A1 (de) | Verfahren zur bereitstellung der funktionalität von mehreren mikrodiensten und/oder der funktionalität von mehreren software-containern mittels einer cloud-infrastruktur, system, verwendungssystem, computerprogramm und computerlesbares medium | |
DE3112693A1 (de) | Modular aufgebautes dezentrales datenverarbeitungssystem | |
DE3751493T2 (de) | Verteiltes Verarbeitungssystem und -verfahren. | |
DE3876823T2 (de) | System zur verschliessungsverhuetung einer relationalen datenbank. | |
EP3441919A1 (de) | Verfahren zum austausch von daten zwischen engineering-tools eines engineering-systems sowie engineering-system zur durchführung des verfahrens |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
OP8 | Request for examination as to paragraph 44 patent law | ||
D2 | Grant after examination | ||
8364 | No opposition during term of opposition |