DE3937532C2 - Mehrprozessoranlage - Google Patents

Mehrprozessoranlage

Info

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
Application number
DE3937532A
Other languages
English (en)
Other versions
DE3937532A1 (de
Inventor
Yasuo Suzuki
Kinji Mori
Katsumi Kawano
Masayuki Orimo
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Publication of DE3937532A1 publication Critical patent/DE3937532A1/de
Application granted granted Critical
Publication of DE3937532C2 publication Critical patent/DE3937532C2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F7/00Methods or arrangements for processing data by operating upon the order or content of the data handled
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/30Creation or generation of source code
    • G06F8/36Software 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.
DE3937532A 1988-11-11 1989-11-10 Mehrprozessoranlage Expired - Lifetime DE3937532C2 (de)

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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS61208540A (ja) * 1985-03-13 1986-09-16 Toshiba Corp プログラム設計支援装置

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