DE4104568A1 - Verfahren und vorrichtung zur programmverarbeitung - Google Patents

Verfahren und vorrichtung zur programmverarbeitung

Info

Publication number
DE4104568A1
DE4104568A1 DE4104568A DE4104568A DE4104568A1 DE 4104568 A1 DE4104568 A1 DE 4104568A1 DE 4104568 A DE4104568 A DE 4104568A DE 4104568 A DE4104568 A DE 4104568A DE 4104568 A1 DE4104568 A1 DE 4104568A1
Authority
DE
Germany
Prior art keywords
program
processing
information
data
input
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.)
Ceased
Application number
DE4104568A
Other languages
English (en)
Inventor
Katsumi Kawano
Kinji Mori
Yasuo Suzuki
Masayuki Orimo
Hirokazu Kasashima
Kozo Nakai
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
Priority claimed from JP3471290A external-priority patent/JPH03238571A/ja
Priority claimed from JP6942490A external-priority patent/JPH03269623A/ja
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Publication of DE4104568A1 publication Critical patent/DE4104568A1/de
Ceased legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/448Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4494Execution paradigms, e.g. implementations of programming paradigms data driven

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Description

Die Erfindung betrifft ein Verfahren und eine Vorrichtung zur Programmverarbeitung. Sie ist insbesondere dann von Vorteil, wenn ein ohne Berücksichtigung eines Datenflusses entwickeltes Programm zum automatischen Erzeugen eines Programms vom Datenflußtyp verwendet wird, indem der Programmkode des ursprünglichen Programms verwendet wird, oder dann, wenn ein I/O(Input/Output=Eingabe/Ausgabe)-Programm mit Datenflußstruktur erzeugt wird, wobei I/O-Spezifikationen durch Mitteilungsdaten definiert sind.
Bisher wird herkömmliche Software für vollständig zentralisierte Steuerung in einer Umgebung ausgeführt, die in bezug auf Softwareerweiterbarkeit und -pflege unzureichende Eigenschaften aufweist. Dies war ein lästiges Hindernis beim Entwerfen eines Systems.
Um dieses Problem zu beseitigen, wurde ein verteiltes Verarbeitungsverfahren bekannt, das mehrere an ein gemeinsames Übertragungsmedium angeschlossene Informationsverarbeitungseinrichtungen nutzt, um eine Folge von Datenverarbeitungsschritten eines Jobs in verteilter Weise auszuführen.
Wenn, wie vorstehend genannt, eine Folge von Datenverarbeitungsschritten eines Jobs von mehreren Prozessoren in verteilter Art ausgeführt wird, kann hierzu ein Verfahren verwendet werden, gemäß dem einer der Prozessoren die Programmausführungssteuerung für die anderen Prozessoren übernimmt. Dieses Verfahren ist jedoch mit dem Nachteil verknüpft, daß das Steuerprogramm zum Steuern der Prozessoren ziemlich komplex wird, z. B. wegen der Zeitablaufsteuerung für die Programme, die von den anderen Prozessoren auszuführen sind. Darüber hinaus besteht eine weitere Schwierigkeit dahingehend, daß ein Ausfall des Steuerprozessors zum Zusammenbrechen des gesamten Systems führt. Zusätzlich verringert sich die Verarbeitungsgeschwindigkeit des Systems aufgrund der Konzentration von Information im Steuerungsprozessor.
Als Verfahren zum Lösen dieser Schwierigkeiten in der herkömmlichen Technik wurde aus JP-A-56-1 46 361 (1982) ein besonderes Verfahren bekannt. Bei diesem werden in einer Umgebung eines verteilten Systems, das unter Berücksichtigung der Autonomie der Software erstellt wurde, die Programmlenkung und -ausführung auf eine Weise gesteuert, die mit einem Fluß von Daten verknüpft ist.
Dieses Verfahren ist ein verteiltes Verarbeitungsverfahren, das auf mehrere Prozessoren anwendbar ist, bei dem Folgen von Datenverarbeitungsschritten durch die jeweiligen Prozessoren ohne Überwachung durch einen Steuerungsprozessor ausgeführt werden können. Dabei wird jeder Prozessor, der mit den anderen über ein gemeinsames Übertragungsmedium verbunden ist, mit einem Programm geladen, das eine Folge von Verarbeitungsschritten eines Jobs in gewünschter Weise ausführt. In jedem Prozessor wird das Programm initialisiert, sobald Daten vom Übertragungspfad empfangen werden und ein Satz von Daten, der zum Ausführen des Programms erforderlich ist, in vollständiger Anordnung vorliegt.
Im Stand der Technik wurde ein Verfahren zum Steuern der Programmausführung beschrieben, jedoch wurde nicht berücksichtigt, wie ein Programm zum Ausführen von Funktionen nach dem Datenflußtyp erzeugt werden kann. Das technische Problem der Programmentwicklung wurde nicht gelöst.
Wie in JP-A-57-1 46 361 (1982) beschrieben, muß also ein Programm notwendigerweise ein solches zum Ausführen eines Ablaufs nach dem Datenflußtyp sein, wenn es ein Verfahren implementieren soll, das zum Steuern von Abläufen zum Lenken und Ausführen eines Programms in einer Weise dient, die mit dem Datenfluß in einer verteilten Systemumgebung verbunden ist, die unter Berücksichtigung der Softwareautonomie entwickelt wurde. Infolgedessen muß ein Programmierer, der das Programm erstellt, ein Verfahren zum Erzeugen eines Programmlaufs in Beziehung zu einem Datenfluß und nicht in Beziehung zu einem Verfahren gemäß der gewohnten Programmsprache entwickeln. Dies war eine schwere Belastung für den Entwickler.
Als herkömmliches Programmentwicklungsverfahren ist z. B. in JP-A-63-1 06 044 (1988) ein flußorientiertes Programmentwicklungsverfahren beschrieben. Bei diesem Verfahren muß der Programmentwickler die Logik nur in einem Flußdiagramm erkennen, um ein Programm ohne Beachtung von Quelll-Objekt- und Lademoduldateien zu entwickeln.
In diesem Zusammenhang wird darauf hingewiesen, daß beim Entwickeln eines Programms in herkömmlicher Technik I/O-Verarbeitung in der Programmspezifikation nicht von der Anwendungsverarbeitung unterschieden wird. In einem Verarbeitungsablauf erfolgt die Verarbeitung dadurch, daß z. B. geeignete Schritte an einem Punkt angegeben werden, an dem äußere Daten erforderlich sind. Infolgedessen beinhaltet die Programmverarbeitung alle Programmabläufe vom Erfassen der äußeren Daten bis zur Funktion des Ladens einer äußeren Einrichtung mit aus der Verarbeitung resultierenden Daten. Um ein vollständiges Programm zu erhalten, unterläuft die beschriebene Programmverarbeitung eine Programmentwicklung, zu der Debuggen, Kompilieren, Linken und Laden gehören.
Beim Stand der Technik wird eine gemeinsame Tabelle verwendet, um Daten zwischen mehreren Programmroutinen zu übertragen, wobei die Datenquellenseite Daten in die gemeinsame Tabelle einschreibt und dann die Datenempfangsseite über die Tatsache informiert, daß Daten in die gemeinsame Tabelle eingeschrieben wurden; zugleich wird der Ort (Adresse) angegeben, an den die Daten geschrieben wurden. Nach Empfang dieser Mitteilung kann die Datenempfangsseite die Daten aus der gemeinsamen Tabelle erfassen. Auf der Datenempfangsseite ist es zusätzlich zum eigentlichen Anwendungsprogramm erforderlich, ein Programm für die Verarbeitung zu erstellen, z. B. um die Daten aus der gemeinsamen Tabelle zu lesen und die Routine auf der Datenquellenseite zu identifizieren.
Wie vorstehend beschrieben, ist bei der herkömmlichen Technik zum Minimieren der Prozeßabläufe eines Programms das Programm wie folgt strukturiert. Im Programm werden nicht alle Eingabedaten gleichzeitig erfaßt, sondern Teile von Eingabedaten werden aufeinanderfolgend empfangen, um sie dann zu überprüfen. Wenn sich herausstellt, daß ein Datenteil falsch ist, wird die Datenerfassung an diesem Punkt angehalten, um die Verarbeitung zu beenden. Das Programm weist also wiederholt einen Ablauf auf, gemäß dem ein Teil der Eingabedaten empfangen wird, um mit diesen Daten einen Teil der vom Programm auszuführenden Anwendungsverarbeitung auszuführen, um Ausgabedaten als Ergebnis der teilweisen Anwendungsverarbeitung in eine äußere Einrichtung einzuschreiben. Für Programmentwicklungsprozesse wie Kompilieren, Linken und Laden des Programms wird als Voraussetzung angenommen, daß die Eingabeverarbeitung und die Ausgabeverarbeitung mit der Anwendungsverarbeitung integriert sind.
Bei Programmentwicklungsabläufen können die externen Spezifikationen (d. h. das Design und interne Spezifikationen der Eingabe- und Ausgabedaten) nicht von den internen Spezifikationen (d. h. der Designspezifikation der Anwendungsverarbeitung) getrennt werden. Wenn fehlende Übereinstimmung zwischen Spezifikationen vorliegt, ist es demgemäß schwierig, den Ort festzustellen, an dem die fehlende Übereinstimmung in den internen und externen Spezifikationen zu einem Ausführungsfehler führt. Infolgedessen ist der Wirkungsgrad beim Debuggen des Programms verringert.
Es ist demgemäß die erste Aufgabe der Erfindung, ein Verfahren und eine Vorrichtung zum Erzeugen eines Programms vom Datenflußtyp anzugeben, mit dem ein Benutzer ein Programm gemäß einem vorgegebenen Format erstellt, ohne daß er auf den Datenfluß zu achten hat. Beim Registrieren des Programms für eine Ausführungsumgebung führt der das Programm speichernde Prozessor Abläufe zum Umwandeln des Programms in ein solches vom Datenflußtyp aus, und er setzt Ausführungsbedingungen, um dabei Belastungen für den Benutzer zu verringern.
Eine zweite Aufgabe der Erfindung besteht darin, ein Verfahren und eine Vorrichtung zum Erzeugen eines I/O-Spezifizierungsprogramms anzugeben, durch die Programmodule gleichzeitig getrennt erzeugt werden, um automatisch eine Prüfung auf fehlende Übereinstimmung vorzunehmen, wodurch die Produktivität des Programms gesehen über die Gesamtabläufe erhöht wird. Darüber hinaus erhöht sich der Programmwirkungsgrad durch automatisches Erzeugen lediglich der I/O-Befehle des Programms.
Um die erste Aufgabe zu lösen, ist das erfindungsgemäße Verfahren dadurch gekennzeichnet, daß dann, wenn ein in einem vorgegebenen Programmkode geschriebenes neues Programm in einem Prozessor abzuspeichern ist, ein Programmkode für einen Eingabeverarbeitungsteil und ein Programmkode für ein Ausgabeverarbeitungsteil im Programm ermittelt werden. Innerhalb des Programms wird dann der ermittelte Programmkode für den Eingabeverarbeitungsteil vor den anderen Verarbeitungsteilen angeordnet, während der ermittelte Programmkode für den Ausgabeverarbeitungsteil nach den anderen Verarbeitungsteilen angeordnet wird. Wenn ein Satz von Informationsgrößen, die zum Ausführen des Programms erforderlich sind, erhalten wird, wird die Gesamtinformation als Eingabeinformation verwendet, um die Programmverarbeitung auszuführen, gemäß der der Eingabeverarbeitungsteil vor den anderen Verarbeitungsteilen ausgeführt wird, und der Ausgabeverarbeitungsteil nach den anderen Verarbeitungsteilen ausgeführt wird.
Gemäß der Erfindung sucht der Prozessor beim Abspeichern eines Programms einen Eingabeinformationsverarbeitungs-Beschreibungsteil und einen Ausgabeinformationsverarbeitungs-Beschreibungsteil, die er auf der Grundlage von Programmkodes erkennen kann und die in Übereinstimmung mit einem vorgegebenen Format in das Programm eingeschrieben sind und die notwendig sind, um das Programm zu betreiben.
Das Programm wird so umgeformt, daß der Eingabeverarbeitungsteil vor den anderen Verarbeitungsteilen des Programms ausgeführt wird und der Ausgabeverarbeitungsteil nach den anderen Verarbeitungsteilen abgearbeitet wird.
Darüber hinaus erstellt die die Ausführung des Programms steuernde Software automatisch Bedingungen für die Programmausführung auf Grundlage von Beziehungen zwischen I/O-Informationen.
Infolgedessen wird die Ausführungsumgebung eines gerade entwickelten neuen Programms automatisch gebildet, wenn das Programm zu seiner Ausführung registriert wird.
Dies hat zur Folge, daß dann, wenn Informationsgrößen, die zum Ausführen des Programms erforderlich sind, aus Inforamtion ausgewählt werden, wie sie über das gemeinsame Übertragungsmedium erfaßt werden, das Programm betrieben wird. Die Informationsgrößen werden an das Programm übergeben, wenn es auf diese Weise aktiviert wird.
Darüber hinaus wird beim Beenden der Programmverarbeitung die durch das Programm erzeugte Information an das gemeinsame Übertragungsmedium übertragen.
Wie vorstehend angegeben, wird ein ohne Berücksichtigung des Datenflusses geschriebenes und erzeugtes Programm in ein Programm vom Datenfluß umgewandelt, das dann ausgeführt wird.
Um die zweite Aufgabe zu lösen, ist ein erfindungsgemäßes Verfahren dadurch gekennzeichnet, daß dann, wenn ein Programm mit Softwaremodulen so entworfen wird, daß es einen Eingabeverarbeitungsteil, einen Ausgabeverarbeitungsteil und einen Anwendungsverarbeitungsteil aufweist, die Verarbeitungsbefehle in den Eingabe- und Ausgabeverarbeitungsteilen zunächst angepaßt werden, um ein zu kompilierendes Programm zu erzeugen, wodurch ein Objektmodul gebildet wird. Danach werden die Objektmodule gelinkt, um einen ausführbaren Modul zu erzeugen, der dann von der tatsächlichen oder Ausführungsumgebung registriert und in dieser gespeichert wird.
Gemäß der Erfindung wird bei einem Programmentwurfsprozeß ein Programm in drei Teile untergliedert, d. h. einen Eingabeverarbeitungsteil, einen Ausgabeverarbeitungsteil und einen Anwendungsverarbeitungsteil, um anschließend ein Programm zu erzeugen, das nur die Eingabe- und Ausgabeverarbeitungsteile enthält. Mehrere Softwaremodule, die ein Programm bilden, werden durch Austauschen von Mitteilungsdaten gelinkt. Genauer gesagt werden Mitteilungsdaten direkt übertragen, um zwischen Softwaremodulen ausgetauscht zu werden, ohne daß eine gemeinsame Tabelle verwendet wird. Infolgedessen wird ein Programm erzeugt, das nur I/O-Befehle enthält. Zunächst werden I/O-Befehle dadurch definiert, daß Namen angegeben werden, die Datengrößen in einem programmvariablen Level zugeordnet sind. Dies führt zu einem automatischen Editieren des Programms in einem Format, wie es ein Compiler erhalten muß. Verarbeitungsbefehle für I/O-Abläufe müssen nicht für Definitionen geschrieben werden. Die Linkverarbeitung wählt nämlich geeignete Befehle in Anpassung an I/O-Abläufe, um die ausgewählten Befehle in das Programm einzuschreiben, wodurch es ermöglicht wird, daß automatisches Linken ausgeführt werden kann. Da, wie oben angegeben, die Programmausführung in einem Zustand möglich ist, bei dem das Anwendungsprogramm fehlt, wird das Programm direkt in der zu kompilierenden Form editiert. Darüber hinaus werden ausführbare I/O-Befehle in dasselbe eingeschlossen, so daß die resultierenden Programmodule gelinkt werden, um Objektmodule zu erhalten, die dann in einer tatsächlichen Umgebung registriert und von dieser gespeichert werden.
Die Beziehungen zum Mitteilungsaustausch bleiben somit zwischen den Modulen erhalten, und demgemäß kann das Programm ausgeführt werden. Das heißt, daß die Module mit einer Softwarekonfiguration und Beziehungen zwischen den Modulen betrieben werden können, die identisch mit denen im Endzustand sind, wie sie vorliegen, wenn der Anwendungsverarbeitungsteil erzeugt wird.
Die vorigen und andere Aufgaben, Vorteile, Betriebsweisen und Wirkungsweisen der Erfindung gehen aus der folgenden Beschreibung in Zusammenhang mit den beigefügten Figuren hervor.
Fig. 1 ist ein Blockdiagramm, das schematisch den Aufbau eines verteilten Verarbeitungssystems zeigt, bei dem ein erstes Ausführungsbeispiel des erfindungsgemäßen Programmverarbeitungsverfahrens implementiert ist;
Fig. 2 ist ein Flußdiagramm, das ein Beispiel für die Funktion zeigt, wie sie von einem Prozessor im System von Fig. 1 ausgeführt wird.
Fig. 3A und 3B sind schematische Diagramme zum Erläutern eines besonderen Beispiels, bei dem ein Programm vom Datenflußtyp durch die Verarbeitung gemäß Fig. 2 erzeugt wird;
Fig. 4A und 4B sind erläuternde Diagramme zum Erklären eines konkreten Verarbeitungsbeispiels auf Grundlage der Verarbeitung von Fig. 2;
Fig. 5A und 5B sind erläuternde Diagramme zum Erklären eines konkreten Ausführungsbeispiels auf Grundlage der Verarbeitung von Fig. 2 für den Fall, daß Eingabeverarbeitung an mehreren Stellen für identische Information in einem Programm vom Verkettungstyp auszuführen ist;
Fig. 6A und 6B sind erläuternde Diagramme zum Erklären eines konkreten Verarbeitungsbeispiels für die Verarbeitung von Fig. 2 für den Fall, daß Eingabeverarbeitung für unterschiedliche Informationsgrößen in einem Programm vom Verkettungstyp auszuführen ist;
Fig. 7A und 7B sind erläuternde Diagramme zum Erklären eines konkreten Verarbeitungsbeispiels auf Grundlage der Verarbeitung von Fig. 2 für den Fall, das Ausgabeverarbeitung an mehreren Stellen für identische Information in einem Programm vom Verkettungstyp auszuführen ist;
Fig. 8A und 8B sind erläuternde Diagramme zum Erklären eines konkreten Verarbeitungsbeispiels gemäß der Verarbeitung von Fig. 2 für den Fall, daß Ausgabeverarbeitung für unterschiedliche Informationsgrößen in einem Programm vom Verkettungstyp auszuführen ist;
Fig. 9A und 9B sind erläuternde Diagramme zum Erklären eines konkreten Verarbeitungsbeispiels gemäß der Verarbeitung von Fig. 2 für den Fall, daß Eingabeverarbeitung und Ausgabeverarbeitung in dieser Reihenfolge für identische Information in einem Programm vom Verkettungstyp vorzunehmen sind;
Fig. 10A und 10B sind erläuternde Diagramme zum Erklären eines konkreten Verarbeitungsbeispiels gemäß der Verarbeitung von Fig. 2 für den Fall, daß Eingabeverarbeitung und Ausgabeverarbeitung jeweils an mehreren Stellen für identische Information in einem Programm vom Verkettungstyp auszuführen sind;
Fig. 11A und 11B sind erläuternde Diagramme zum Erklären eines besonderen Verarbeitungsbeispiels eines Verfahrens zum Erzeugen eines Programms vom Verzweigungstyp auf Grundlage der Verarbeitung von Fig. 2;
Fig. 12A und 12B sind erläuternde Diagramme zum Erklären eines besonderen Ausführungsbeispiels eines Verfahrens zum Erzeugen eines Programms vom Wiederholungstyp auf Grundlage der Verarbeitung von Fig. 2;
Fig. 13A und 13B sind erläuternde Diagramme zum Erklären eines besonderen Ausführungsbeispiels auf Grundlage der Verarbeitung von Fig. 2 für den Fall, daß sich Eingabe/Ausgabe-Information für jede wiederholte Ausführung in einer Wiederholungs- oder Iterations-Anweisung ändert;
Fig. 14A und 14B sind erläuternde Diagramme zum Erklären eines besonderen Verarbeitungsbeispiels auf Grundlage der Verarbeitung von Fig. 2 für den Fall, daß in einem Programm Unterprogramm aufgerufen werden;
Fig. 15 ist ein Diagramm zum Erläutern des Übertragungsformats für Information, wie sie über das gemeinsame Übertragungsmedium von Fig. 1 übertragen wird;
Fig. 16A und 16B sind erläuternde Diagramme zum Erklären eines besonderen Verarbeitungsbeispiels eines Programms, wie es im verteilten Verarbeitungssystem ausgeführt wird, das in Zusammenhang mit Fig. 15 beschrieben wurde;
Fig. 17 ist ein schematisches Diagramm, das Dateien und Programme in einer Verarbeitungsvorrichtung zum Unterstützen von Programmentwicklung zeigt, durch welche Vorrichtung ein zweites Ausführungsbeispiel des erfindungsgemäßen Programmverarbeitungsverfahrens implementiert wird;
Fig. 18 ist ein Diagramm, das die Inhaltskodedatei von Fig. 17 im einzelnen zeigt;
Fig. 19 ist ein Diagramm, das die Datengrößendatei von Fig. 17 im einzelnen zeigt;
Fig. 20 ist ein Diagramm, das die Funktionsmoduldatei von Fig. 17 im einzelnen zeigt;
Fig. 21 ist ein Diagramm, das den Inhalt einer Kreuzreferenztabelle zwischen Inhaltskodes und Datengrößen gemäß Fig. 27 zeigt.
Fig. 22 ist ein Diagramm, das den Inhalt einer Kreuzreferenztabelle zwischen Funktionsmodulen und Inhaltskodes gemäß Fig. 27 zeigt;
Fig. 23 ist ein Diagramm, das den Inhalt einer Kreuzreferenztabelle zwischen Funktionsmodulen und Datengrößen von Fig. 27 zeigt;
Fig. 24 ist ein Diagramm, daß das Systemflußdiagramm von Fig. 27 im einzelnen zeigt;
Fig. 25 ist ein erläuterndes Diagramm zum Erklären der Verarbeitung des Programms zum automatischen Erzeugen von I/O-Befehlen im Programm von Fig. 17;
Fig. 26 ist ein Diagramm, das den Ablauf bis zum Betrieb eins I/O-Spezifizierungsprogramms in Fig. 27 zeigt;
Fig. 27 ist ein Diagramm, das I/O-Daten der erfindungsgemäßen Verarbeitungsvorrichtung zum Unterstützen von Programmentwicklung zeigt.
Fig. 28 ist ein Flußdiagramm, das den Verarbeitungsablauf des Inhaltskodeeditierprogramms in Fig. 17 zeigt;
Fig. 29 ist ein Flußdiagramm, das den Verarbeitungsablauf des Datengrößeneditierprogramms in Fig. 17 zeigt;
Fig. 30 ist ein Flußdiagramm, das den Verarbeitungsablauf des Funktionsmoduleditierprogramms in Fig. 17 zeigt;
Fig. 31 ist ein Diagramm, das den Inhalt der Systemflußtabelle von Fig. 17 zeigt;
Fig. 32 ist ein Diagramm, das den Inhalt der Inhaltskode/Datengröße-Kreuzreferenztabelle oder -Kreuztabelle von Fig. 17 zeigt;
Fig. 33 ist ein Diagramm, das den Inhalt der Funktionsmodul/Inhaltskode-Kreuztabelle von Fig. 17 zeigt;
Fig. 34 ist ein Diagramm, das den Inhalt der Funktionsmodul/Datengrößen-Kreuztabelle von Fig. 17 zeigt;
Fig. 35 ist ein Diagramm, das den Inhalt der I/O-Befehlsprogramm-Quelldatei von Fig. 17 zeigt;
Fig. 36 ist ein Flußdiagramm, das den Verarbeitungsablauf des Systemflußintegrationsprogramms in Fig. 17 zeigt;
Fig. 37 ist ein Flußdiagramm, das den Verarbeitungsablauf des Inhaltskode/Datengrößen-Integrationsprogramms von Fig. 17 zeigt;
Fig. 38 ist ein Flußdiagramm, das den Verarbeitungsablauf des Funktionsmodul/Inhaltskode-Integrationsprogramms in Fig. 17 zeigt;
Fig. 39 ist ein Flußdiagramm, das den Verarbeitungsablauf des Funktionsmodul/Datengrößen-Integrationsprogramms in Fig. 17 zeigt;
Fig. 40 ist ein Flußdiagramm, das den Verarbeitungsablauf des Strukturplausibilitäts-Überprüfungsprogramms in Fig. 17 zeigt;
Fig. 41 ist ein Flußdiagramm, das den Verarbeitungsablauf des Programms zur automatischen Erzeugung von I/O-Befehlen in Fig. 17 zeigt.
Fig. 1 ist ein Blockdiagramm, das den Aufbau eines Systems für verteilte Datenverarbeitung zeigt, mit dem ein erstes Ausführungsbeispiel des erfindungsgemäßen Programmverarbeitungsverfahrens realisiert wird.
Der Aufbau weist Prozessoren 21 bis 23 auf, von denen jeder zum Ausführen eines erfindungsgemäßen Programmverarbeitungsverfahrens dient. Weiterhin weist er Datenendstellen 41 bis 43 mit jeweils einer Anzeigeeinrichtung und einer Tastatur sowie Übertragungssteuerungen 11 bis 13 zum Steuern von Informationsübertragung über ein gemeinsames Übertragungsmedium 3 auf.
Prozessoren 21 bis 23 sind über die Übertragungssteuerungen 11 bis 13 mit dem gemeinsamen Übertragungsmedium 3 jeweils verbunden, um zwischen ihnen Nachrichtenübertragung auszuführen.
Die Prozessoren 21 bis 23 sind jeweils mit den Datenendstellen 41 bis 43 verbunden.
Eine Datenendstelle weist im vorliegenden Fall eine Schnittstelle Mensch/Maschine auf, die durch Einrichtungen wie eine Anzeigeneinrichtung und eine Tastatur realisiert ist, um eine Funktion zum Erzeugen eines vorgebenenen Programms bereitzustellen. Das Programm kann auf einem Prozessor mit Hilfe der Schnittstelle ausgeführt werden.
Die Prozessoren 21 bis 23 führen jeweils automatische Programmwandlung für Programme aus, die von Hand in geeigneten Programmsprachen über jeweilige Datenendstellen 41 bis 43 eingegeben werden, und die in unterschiedlicher Form erzeugt werden. Als Ergebnis der Umwandlung wird ein neues Programm vom Datenflußtyp erzeugt, das in einer vom Datenfluß abhängigen Weise betrieben und ausgeführt wird.
Nun wird ein Verarbeitungsverfahren beschrieben.
Fig. 2 ist ein Flußdiagramm, das die Verarbeitungsfunktion der Prozessoren 41 bis 43 von Fig. 1 gemäß der Erfindung zeigt.
Zunächst wird ein auszuführendes Programm in das System eingelassen (Schritt 201), und dann wird eine Überprüfung vorgenommen, um zu entscheiden, ob das Programm einen Eingabeverarbeitungsteil, d. h. einen Eingabekode aufweist (Schritt 202). Wenn dies der Fall ist, wird eine neue Eingabevariable zugehörig zur Eingabevariable im Eingabekode gesetzt (Schritt 203).
Anschließend wird eine Größe des Eingabekodes durch einen Programmkode durch eine Zuordnungsanweisung "Eingabevariable←neue Eingabevariable" ersetzt (Schritt 204).
Darüber hinaus werden der Eingabekode und ein Programmkode für die Zuordnungsanweisung "neue Eingabevariable - Eingabevariable" an einer ersten Stelle des Verarbeitungsteils des Programms eingesetzt (Schritt 205).
Infolge der oben beschriebenen Verarbeitung wurde ein Programmkode vollständig erzeugt, der den Eingabeverarbeitungsteil des Programms zu Beginn der Programmverarbeitung ausführt.
Wenn andererseits das Programm einen Ausgabeverarbeitungsteil, d. h. einen Ausgabekode aufweist (Schritt 206), wird eine neue Ausgabevariable in bezug zur Ausgabevariable des Ausgabekodes gesetzt (Schritt 207), und dann wird eine Größe des Ausgabekodes für den Programmkode durch eine Zuordnungsanweisung "neue Ausgabevariable←Ausgabevariable" ersetzt (Schritt 208).
Darüber hinaus wird ein Ausgabekode erzeugt, der die neue Ausgabevariable nutzt, die an einer Stelle einzusetzen ist, die der Endstelle des Verarbeitungsteils dieses Programms vorausgeht (Schritt 209).
Dadurch wurde ein Programmkode vollständig erzeugt, der den Ausgabeverarbeitungsteil des Programms am Ende der Programmverarbeitung bewirkt.
Durch die so bewerkstelligte Verarbeitung durch die Eingabe- und Ausgabeverarbeitungsteile wird das Programm in ein solches vom Datenflußtyp überführt, das schließlich ausgegeben wird (Schritt 210).
Die Prozessoren 21 bis 23 von Fig. 1 führen die oben angegebenen Verarbeitungsabläufe aus, um jeweils über die Datenendstellen 41 bis 43 eingegebene Programme in solche vom Datenflußtyp umzuwandeln.
Nun wird unter Bezugnahme auf ein besonderes Programmbeispiel die Funktion beschrieben, wie sie gemäß der Erfindung von den Prozessoren 21 bis 23 von Fig. 1 ausgeführt wird.
Die Fig. 3A und 3B sind erläuternde Diagramme zum Erklären eines konkreten Beispiels eines Ablaufs, wie er von jedem der Prozessoren 21 bis 23 von Fig. 1 ausgeführt wird, um ein Programm vom Datenflußtyp zu erzeugen.
Fig. 3A zeigt ein Programm, wie es von der Datenendstelle 41, 42 oder 43 von Fig. 1 erzeugt wird.
Fig. 3B zeigt ein Programm vom Datenflußtyp, wie es durch Übersetzen des obigen Programms durch den Prozessor von Fig. 1 erzeugt wird.
In Fig. 3A sind BEGIN 301 und END 304 Quellkodebegriffe, die den Anfang bzw. das Ende des Programms kennzeichnen. Darüber hinaus bezeichnet IN einen Programmkode zum Verarbeiten des Empfangs von Information von einer Quelle außerhalb des Programms, während OUT einen Programmkode zum Verarbeiten des Sendens von Information zu einer äußeren Stelle bezeichnet.
Das heißt, daß IN A1 302 diejenige Information A1 bezeichnet, die von einer äußeren Quelle empfangen wird, während OUT B1 Information B1 kennzeichnet, die an eine außenliegende Stelle abgegeben wird.
Darüber hinaus bedeutet #A1←A1 312 in Fig. 3B, daß die Information A1 in A1 gespeichert wird. A1←#A1 313 bezeichnet, daß Information #A1 in A1 überführt wird, und #B1←B1 314 zeigt an, daß Information B1 in #B1 geladen wird.
Anders gesagt bedeutet dies, daß das in Fig. 3A dargestellte Programm in das Programm von Fig. 3B überführt wurde, in dem das Quellprogramm von IN A1 302 bis OUT B1 303 von Fig. 3A durch das Quellprogramm von IN A1 311 bis OUT #B1 315 ersetzt wurde. Das resultierende Programm wird danach in das System eingegliedert.
Das Programm von Fig. 3B ist so ausgebildet, daß Eingabeverarbeitung zum Erfassen von Eingaben von einer äußeren Quelle und Ausgabeverarbeitung zum Ausgeben von Werten an einen äußeren Ort jeweils zu Beginn bzw. zu Ende des Programms ausgeführt werden, wodurch das Programm ein solches vom Datenflußtyp ist.
In dieser Beziehung sind #A1 und #B1 Namen, die für die I/O (Input/Output=Eingabe/Ausgabe)-Verarbeitungsschritte vergeben sind, die erstellt werden, wenn das Programm von Fig. 3A in dasjenige von Fig. 3B umgewandelt wird. Diese Namen sind so angenommen, daß sie sich von denjenigen im ursprünglichen Programm von Fig. 3A unterscheiden.
Wenn die Namen zugeordnet werden, werden vorab Regeln erstellt wie z. B. die, daß in einem erzeugenden Programm ein Name mit # als erstem Zeichen nicht benutzt werden kann. Alternativ kann z. B. ein Verfahren angenommen werden, gemäß dem vor jeder Zuordnung eines Namens die Quellprogrammodule insgesamt durchgesehen werden, um einen Namen zu bestimmen, der sich von einem bereits darin verwendeten Namen unterscheidet.
Darüber hinaus wird angenommen, daß der Quellkode in Übereinstimmung mit einem vorgegebenen Format und Syntaktikregeln einer geeigneten Programmsprache beschrieben wird.
Das heißt, daß die Programmkode der Fig. 3A und 3B nur ein Beispiel darstellen. Die I/O-Verarbeitungskodes sind nicht auf IN und OUT beschränkt. Zum Beispiel kann, ohne daß es zu Schwierigkeiten kommt, eine Programmsprache verwendet werden, die als I/O-Verarbeitungskodes RECEIVE und SEND oder READ und WRITE nutzt.
Unter Bezugnahme auf andere Programme wird nun ein konkretes Beispiel eines erfindungsgemäßen Programmverarbeitungsverfahrens angegeben.
Im allgemeinen weist ein Programm Verarbeitungen unterschiedlicher Formen auf. Bei der Beschreibung der unten stehenden Ausführungsbeispiele wird die Grundform der Programmanweisungen wie folgt. in drei Typen klassifiziert.
(i) Verkettungstyp: Ein Programm wird als Folge von Programmschritten ausgeführt.
(ii) Verzweigungstyp: Die Programmausführungsreihenfolge ändert sich abhängig von einer Bedingung.
(iii) Wiederholungstyp: Identische Verarbeitungsabläufe werden für eine vorgegebene Anzahl von Durchläufen wiederholt.
Darüber hinaus wird als Beispiel für eine Programmbeschreibung ein solches Ausführungsbeispiel gegeben, bei dem (iv) ein Programm Unterroutinen aufweist.
Zunächst wird ein Ausführungsbeispiel vom Verkettungstyp (i) beschrieben.
Obwohl die Programmkodes der Fig. 3A und 3B ebenfalls Programmbeispiele vom Verkettungstyp sind, wird ein anderes typisches Beispiel in den Fig. 4A und 4B dargestellt.
Die Fig. 4A und 4B sind erläuternde Diagramme, die als besonderes Verarbeitungsbeispiel gemäß der Erfindung ein Programm vom Verkettungstyp zeigen.
Die Programmkodes der Fig. 4A und 4B sind in einer anderen Programmsprache als diejenigen von Fig. 3A und 3B implementiert.
Insbesondere sind statt IN und OUT in den Programmkodes der Fig. 3A und 3B durch RECEIVE bzw. SEND in den Fig. 4A und 4B ersetzt. das Programmwandlungsverfahen ist genau dasselbe, wie es in Verbindung mit Fig. 2 beschrieben wurde.
Genauer gesagt wird das Programm von Fig. 3A mit den Programmkodes zwischen RECEIVE A1 401 und SEND B1 402 in das Programm von Fig. 3B überführt, das Programmkodes zwischen RECEIVE A1 411 und SEND #B1 415 aufweist, wodurch ein Programm vom Datenflußtyp erhalten wird.
Informationszuweisungen werden in den Schritten #A1←A1 412, A1←#A1 413 und #B1←B1 414 vorgenommen.
Das Programmerzeugungsverfahren in Zusammenhang mit dem Verkettungstyp wird darüber hinaus in Zusammenhang mit den folgenden Fällen (1) bis (6) beschrieben.
(1) Eingabeverarbeitung für identische Information erscheint an mehreren Stellen des Programms (Fig. 5A und 5B).
(2) Eingabeverarbeitung wird für unterschiedliche Verarbeitungsgrößen ausgeführt (Fig. 6A und 6B).
(3) Ausgabeverarbeitung für identische Information tritt an mehreren Stellen auf (Fig. 7A und 7B).
(4) Ausgabeverarbeitung wird für unterschiedliche Informationsgrößen ausgeführt (Fig. 8A und 8B).
(5) Eingabe- und Ausgabeverarbeitung wird in dieser Reihenfolge für gleiche Information ausgeführt (Fig. 9A und 9B).
(6) Im Fall (5) wird die Eingabeverarbeitung erneut nach der Ausgabeverarbeitung ausgeführt (Fig. 10A und 10B).
Es wird zunächst der Fall (1) beschrieben, gemäß dem Eingabeverarbeitung für identische Information an mehreren Stellen ausgeführt wird.
Die Fig. 5A und 5B sind besondere Verarbeitungsbeispiele eines erfindungsgemäßen Programms vom Verkettungstyp für den Fall, daß Eingabeverarbeitung für identische Information an mehreren Stellen ausgeführt wird.
Bei diesem Beispiel weist das mit Hilfe der Datenendstelle 41, 42 oder 43 von Fig. 1 erzeugte Programm, wie es in Fig. 5A dargestellt ist, zwei Eingabeverarbeitungsstellen in A1 501 und 502 auf, in die die identische Information A1 von einer äußeren Quelle eingegeben wird.
Wie bei der Verarbeitung, die in bezug auf die Beispiele der Fig. 3A und 3B beschrieben wurde, wird der die Eingabeverarbeitung beschreibende Teil an den Anfang des Programms verschoben, wie in Fig. 5B dargestellt.
Bei diesem Beispiel werden dieselben Eingabeverarbeitungsteile IN A1 501 und 502 durch einen Eingabeverarbeitungsteil IN A1 511 ersetzt. Darüber hinaus werden an den Stellen, in denen ursprünglich die Schritte IN A1 501 und 502 spezifiziert sind, jeweils Schritte A1←#A1 513 und 514 ausgeführt, so daß die Eingabeinformation #A1 die ursprünglich mit A1 bezeichneten Daten ersetzt.
Infolgedessen führt das erhaltene Programm gemäß Fig. 5B die Datenverarbeitung des Programms von Fig. 5A gemäß einem Datenfluß aus.
In diesem Zusammenhang erfolgt die Zuordnung #A1←A1 in Anbetracht eines Falles, bei dem die Verarbeitung (z. B. die Zuordnung einer Konstanten) für die Information A1 zwischen IN A1 511 und A1←#A1 513 stattfinden kann. Es wird nämlich die Eingabeinformation A1 einmal in #A1 abgelegt, und dann wird die Information wieder in A1 in den ursprünglichen Eingabeverarbeitungspositionen IN A1 501 und 502 abgespeichert, wodurch vermieden wird, daß die Information A1 zerstört wird.
Nun wird der Fall (2) beschrieben, gemäß dem Verarbeitung für unterschiedliche Informationsgrößen erfolgt.
Die Fig. 6A und 6B zeigen konkrete Verarbeitungsbeispiele eines erfindungsgemäßen Programms vom Verkettungstyp, bei dem Eingabeverarbeitung für unterschiedliche Informationsgrößen ausgeführt wird.
Das Programm der Fig. 6A und 6B beinhaltet Informationseingabeverarbeitung in Schritten IN A1 601 und IN A2 602. Diese eingabeverarbeitungsbeschreibenden Teile werden durch die Verarbeitung gemäß Fig. 2 in IN A1, A2 611 übertragen, die am Anfang des Programms angeordnet wird, wie in Fig. 6B dargestellt.
Die Angabe IN A1, A2 611 zeigt an, daß Information A1 und Information A2 von einer äußeren Quelle erfaßt werden. Die Programmkodes IN A1 601 und IN A2 602, die im Programm von Fig. 6A vorhanden sind, werden durch A1←#A1 614 bzw. A2←#A2 615 ersetzt.
Es folgt nun eine Beschreibung für den Fall (3), gemäß dem Ausgabeverarbeitung an mehreren Stellen für identische Information ausgeführt wird.
Die Fig. 7A und 7B zeigen konkrete Verarbeitungsbeispiele eines erfindungsgemäßen Programms vom Verkettungstyp für den Fall, daß Ausgabeverarbeitung für identische Information an mehreren Stellen ausgeführt wird.
Im Programm von Fig. 7A wird Ausgabeverarbeitung von Information B1 an zwei Stellen OUT B1 701 und 702 ausgeführt.
Diese ausgabeverarbeitungsbeschreibenden Stellen werden durch die Verarbeitung gemäß Fig. 2 in OUT B1 713 transformiert, was am Schluß des Programms angeordnet wird, wie in Fig. 7B dargestellt.
Die Beschreibungsteile OUT B1 701 und 702 sind im Programm von Fig. 7B in #B1←B1 711 und 712 umgewandelt. Wenn in diesem Fall ein Verarbeitungsschritt vorhanden ist, der den Inhalt von B1 zwischen den Schritten OUT B1 701 und 702 ändert, ändert sich der Inhalt von B1 zwischen den Ausgabeverarbeitungsschritten OUT B1 701 und 702.
Bei dem so erhaltenen Programm gemäß Fig. 7B wird der letzte Inhalt von B1, also der Inhalt beim Ausführen des Schritts #B1←B1 712 ausgegeben.
In diesem Fall kann demgemäß ein Verfahren angewendet werden, das dasselbe Ergebnis bei gelöschtem Schritt #B1←B1 711 liefert.
Dieses Verfahren reicht aus, wenn die Ausgabefunktion auf konkrete Weise verarbeitet wird, z. B. wenn Ausgabe auf eine Platte erfolgt.
Um mehrere Ausgabeverarbeitungsschritte OUT B1 701 und 702 gleichzeitig oder mit einem einzigen Schritt auszuführen, ist es nur erforderlich, unterschiedliche Namen für #B1 in den Schritten #B1←B1 711 und 712 zu verwenden. Z. B. werden die Namen #B1 (1) und #B1 (2) den Schritten #B1←B1 711 bzw. 712 zugeordnet, so daß die Ausgaben in einem einzigen Ausgabeschritt OUT #B1 713 erfolgen.
In diesem Fall ist der Schritt OUT #B1 713 in OUT #B1 (1), #B1 (2) zu transformieren.
Nun wird Fall (4) beschrieben, gemäß dem Ausgabeverarbeitung für unterschiedliche Informationsgrößen ausgeführt wird.
Die Fig. 8A und 8B zeigen ein konkretes Verarbeitungsbeispiel eines erfindungsgemäßen Programms vom Verkettungstyp für den Fall, daß Ausgabeverarbeitung für unterschiedliche Informationsgrößen ausgeführt wird.
Das Programm von Fig. 8A enthält Informationsausgabeverarbeitung für unterschiedliche Informationsgrößen in Schritten OUT B1 801 und OUT B2 802.
In diesem Fall wird der jeweilige Inhalt von Informationsgrößen B1 und B2, die in den Schritten OUT B1 801 bzw. OUT B2 802 auszugeben sind, gemäß der Verarbeitung von Fig. 2 in #B1 bzw. #B2 überführt, so daß die Ausgaben gleichzeitig im abschließenden Programmteil OUT #B1, #B2 813 erfolgen, wie in Fig. 8B dargestellt.
Anschließend folgt eine Beschreibung des Falls (5), gemäß dem Eingabe- und Ausgabeverarbeitung in dieser Reihenfolge für gleiche Information ausgeführt wird.
Die Fig. 9A und 9B sind ein konkretes Verarbeitungsbeispiel eines erfindungsgemäßen Programms vom Verkettungstyp für den Fall, daß Eingabe- und Ausgabeverarbeitung in dieser Reihenfolge für identische Information ausgeführt wird.
Das Programm von Fig. 9A beinhaltet Eingabe- und Ausgabeverarbeitung für identische Information A1. Darüber hinaus wird bei diesem Programm nach dem vollständigen Ausführen eines Eingabeverarbeitungsschritts IN A1 901 eine Ausgabe OUT A1 902 ausgeführt.
Auch bei diesem Beispiel werden, wie dies aus der Beschreibung der obigen Ausführungsbeispiele verstanden werden kann, die Eingabe- und Ausgabeverarbeitungsteile in IN A1 911 und OUT #A1 915 umgewandelt, wie dies in Fig. 9B dargestellt ist, was mit der Verarbeitung von Fig. 2 erfolgt. Darüber hinaus werden die Schritte IN A1 901 und OUT A1 902 in A1←#A1 913 bzw. #A1←A1 914 umgewandelt.
Im folgenden wird Fall (6) beschrieben, gemäß dem nach dem Ausführen von Fall (5), nämlich nach Eingabe- und Ausgabeverarbeitung in dieser Reihenfolge für identische Information die Eingabeverarbeitung erneut ausgeführt wird.
Die Fig. 10A und 10B zeigen konkrete Ausführungsbeispiele eines erfindungsgemäßen Programms vom Verkettungstyp für den Fall, daß mehrere Eingabe- Ausgabeverarbeitungskodes für identische Information vorliegen.
Auch in diesem Fall dient die Logik der Programmerzeugung dazu, das Programm von Fig. 10A in dasjenige von Fig. 10B zu überführen.
Wenn man diesen Fall mit demjenigen der Fig. 9A und 9B vergleicht, wird das völlig identische Verfahren ausgeführt, so daß die Eingabe- und Ausgabeteile jeweils an den Anfang bzw. an den Schluß des Programms bewegt werden, also zu IN A1 1011 bzw. OUT #A1 1016. Es werden also die ursprünglichen Eingabe- und Ausgabeteile IN A1 1001, OUT A1 1002 und IN A1 1003 in A1←#A1 1013, #A1←A1 1014 bzw. A1←#A1 1015 umgewandelt.
Konkrete Beispiele eines erfindungsgemäßen Programmerzeugungsverfahrens wurden vorstehend für den Fall (i) beschrieben, gemäß dem das Programm vom Verkettungstyp ist.
Es wird nun das Verfahren für den Fall (ii) beschrieben, gemäß dem das Programm vom Verzweigungstyp ist.
Die Fig. 11A und 11B zeigen ein besonderes Verarbeitungsbeispiel eines erfindungsgemäßen Programmerzeugungsverfahrens, das auf ein Programm vom Verzweigungstyp angewendet wird.
In Fig. 11A ist ein Beispiel eines Programms mit einer Verzweigung dargestellt (Anweisung IF).
Im Programmbeispiel von Fig. 11 ist beim Erfülltsein einer Bedingung C1 ein in Klammern { } enthaltener Teil auf IF (C1) 1102 auszuführen, wenn die Bedingung erfüllt ist; andernfalls ist ein mit Klammern umschlossener Teil auszuführen, der auf ELSE 1105 folgt.
Programmkodes in bezug auf I/O-Befehle werden in derselben Weise, wie vorstehend in Zusammenhang mit dem Fall (i), gemäß dem das Programm vom Verkettungstyp ist, in neue Programmkodes gewandelt.
Dies heißt, daß die Eingabebefehle IN A1 1103 und IN A2 1106 von Fig. 11A in IN A1, A2 1111 umgewandelt werden, was im ersten Bereich des Programms von Fig. 11B angeordnet wird.
Darüber hinaus werden die Inhalte an den Stellen der Eingabebefehle IN A1 1103 und IN A2 1106 von Fig. 11A durch A1 - #A1 1115 bzw. A2←#A2 1117 im Programm von Fig. 11B ersetzt.
Da die Ausgabeverarbeitung von einer Bedingung abhängt, wird eine Variable mit dem Namen #C1 verwendet, um einen Verarbeitungsprogrammkode zum Zuweisen des Inhalts zur Bedingung C1 zuzuordnen, wie #C1←C1 1114 in Fig. 11B, direkt nach der linksseitigen Klammer {, die auf IF C1 1102 folgt.
Programmkodes OUT B1 1104 und OUT B2 1107 von Fig. 11A werden auf dieselbe Weise in #B1←B1 1116 bzw. #B2#B2 1118 umgewandelt.
Der Ausgabebefehlsteil wird jedoch mit Hilfe von #C1 in IF (#C1) OUT #B1 1119 und ELSE OUT #B2 1120 umgewandelt, was am Ende von Fig. 11B anzuordnen ist.
Ein konkretes Beispiel für ein Programmerzeugungsverfahren wurde vorstehend für den Fall (ii) beschrieben, bei dem das Programm vom Verzweigungstyp ist.
Im folgenden wird ein besonderes Verarbeitungsbeispiel für ein erfindungsgemäßes Programmerzeugungsverfahren für den Fall gegeben, bei dem das Programm vom Wiederholungstyp ist.
Fig. 12A zeigt ein Programm, bei dem ein mit Klammern umschlossener Teil, der auf FOR (i=1, 10; i++) folgt, zehn Mal wiederholt wird.
Dieses Beispiel ist dem Fall entsprechend, bei dem Eingabe- und Ausgabeverarbeitungsbefehle an mehreren Stellen im Programm festgelegt sind, was oben in Beziehung zu Fall (i) beschrieben wurde.
Programmkodes von Fig. 12A werden dementsprechend in Programmkodes von Fig. 12B umgewandelt.
Das heißt, daß IN A1 1203 von Fig. 12A als Eingabebefehl IN A1 1211 im ersten Bereich von Fig. 12B angeordnet wird. Darüber hinaus wird #A1 in #A1←A1 1212 verwendet, und die Stelle IN A1 1203 wird durch A1←#A1 1213 ersetzt. Darüber hinaus wird OUT B1 1204 von Fig. 12A durch #B1←B1 1214 in Fig. 12B ersetzt. Der Ausgabebefehl ist mit OUT #B1 1215 bezeichnet.
Darüber hinaus kann, wie in Zusammenhang mit Fall (3) vom Verkettungstyp (i) beschrieben, ein Verfahren genutzt werden, gemäß dem alle der mehreren Ausgabebefehle jeweils ausgeführt werden.
Nun wird ein Programmerzeugungsverfahren beschrieben, das auf den Fall angewendet ist, gemäß dem Eingabe/Ausgabe-Information sich für jeden wiederholten Ablauf der Wiederholungsanweisung ändert.
Die Fig. 13A und 13B zeigen ein konkretes Verarbeitungsbeispiel eines Programmerzeugungsverfahrens für den Fall, daß Eingabe/Ausgabe-Information sich für jede wiederholte Ausführung einer Wiederholungsanweisung ändert.
Die Programmkodes IN A1 1203 und OUT B1 1204 von Fig. 12A sind in Fig. 13A jeweils durch IN Ai 1303 bzw. OUT Bi 1304 ersetzt. Jede der Eingabe/Ausgabe-Informationsgrößen Ai und Bi ändert sich für jeden wiederholten Ablauf. Das Programm gemäß Fig. 13A wird mit einer Verarbeitung gemäß Fig. 2 in ein Programm umgewandelt, das einen Eingabeverarbeitungsteil aufweist mit FOR (i=1, 10; i++) 1311, IN Ai 1312 und #A1←A1 1313, und das einen Ausgabeverarbeitungsteil aufweist mit FOR (i=1, 10; i++) OUT #B1 1316.
Im vorigen wurden konkrete Verarbeitungsbeispiele für ein erfindungsgemäßes Programmerzeugungsverfahren in Zusammenhang mit drei Grundtypen von Programmen gegeben, nämlich für (i) ein Programm vom Verkettungstyp, (ii) ein Programm vom Verzweigungstyp und (iii) ein Programm vom Wiederholungstyp.
Im folgenden wird ein Programmerzeugungsverfahren für den Fall (iv) beschrieben, gemäß dem ein Programm Unterprogrammaufrufe beinhaltet.
Unterprogramme werden häufig beim Erzeugen eines Programms verwendet.
Die Fig. 14A und 14B zeigen ein besonderes Verarbeitungsbeispiel eines erfindungsgemäßen Programmerzeugungsverfahrens für den Fall, daß ein Programm Unterprogrammaufrufe enthält.
Fig. 14 zeigt ein Programm, das den Befehl CALL SUB 1412 enthält, um eine Unterroutine SUB aufzurufen.
Die Unterroutine SUB weist Programmkodes auf, die von SUB 1404 bis RETURN 1407 laufen.
Das Programm von Fig. 14A entspricht einem Programm, das dadurch erhalten wird, daß CALL SUB 1412 mit den Programmkodes zwischen SUB 1404 und RETURN 1407 ersetzt wird. Das resultierende Programm enthält keinen Unterprogrammaufruf. Das erfindungsgemäße Programmerzeugungsverfahren muß nur auf das erhaltene Programm angewendet werden.
Dies bedeutet, daß IN A1 1405 von Fig. 14A als IN A1 1411 im ersten Bereich des Programms in Fig. 14B angeordnet wird. Anschließend wird #A1←A1 1412 für Variablensubstitution angegeben. Im letzten Bereich wird der Ausgabebefehl OUT #B1 1413 angeordnet.
In der Unterroutine werden IN A1 1405 und OUT B1 1406 von Fig. 14A jeweils in A1←#A1 1414 bzw. #B1←B1 1415 in Fig. 14B umgewandelt.
Es wird nun der Fall beschrieben, daß ein gemäß der Erfindung erzeugtes Programm in einem der Prozessoren 21, 22 oder 23 von Fig. 1 abgearbeitet wird und Eingabe/Ausgabe-Befehle des Programms sich auf Mitteilung von Informationen beziehen, wie sie über das gemeinsame Übertragungsmedium 3 übertragen wird.
Fig. 15 zeigt das Übertragungsformat von Information, wie sie über das gemeinsame Übertragungsmedium 3 von Fig. 1 geleitet wird.
Über das gemeinsame Übertragungsmedium 3 von Fig. 1 mitgeteilte Information 151 weist ein Informationsfeld 153 auf, das Information enthält wie auch einen Inhaltskode 152, der den Inhalt der Information bezeichnet.
In einem verteilten Verarbeitungssystem wird die Information 151 abhängig vom Inhaltskode 152 mitgeteilt, der den Inhalt der Information angibt. Die über das gemeinsame Übertragungsmedium 3 von Fig. 1 gesendete Information 151 wird durch die Übertragungssteuerungen 11, 12 und 13 empfangen, die jeweils mit einem der Prozessoren 21, 22 bzw. 23 empfangen sind. Der Inhaltskode 152 wird überprüft, und wenn sich herausstellt, daß der Prozessor die Information 151 benötigt, sendet die Steuerung diese Information 151 an ihn.
Der Prozessor 21, 22 oder 23 empfängt die Information 151 als Eingangsdaten für ein Programm, das aus im Prozessor gespeicherten Programmen ausgewählt wurde. Wenn erforderliche Informationsgrößen als Ergebnis der Datenempfangsabläufe angesammelt sind, wird das Programm ausgeführt, um die so erhaltenen Eingangsdatengrößen zu verarbeiten.
Information, die aus der Verarbeitung resultiert, wird mit einem Inhaltskode 152 versehen, der der Information entspricht. Der zuständige Prozessor 21, 22 oder 23 überträgt dann die erhaltene Information über die zugehörige Übertragungssteuerung 11, 12 bzw. 13 an das gemeinsame Übertragungsmedium 3.
Unter der Information, die über das gemeinsame Übertragungsmedium 3 läuft, wird jede für die Verarbeitung erforderliche Information so bearbeitet, daß der Inhaltskode 152 registriert wird und im Speicher einer zugeordneten Übertragungssteuerung gespeichert wird. Darüber hinaus wird auf ähnliche Weise die in bezug auf jedes Programm erforderliche Information registriert und in einen internen Speicher jedes Prozessors 21, 22 oder 23 geladen.
Die entsprechende Beziehung zwischen der Information 151 und dem Inhaltskode 152 wird einheitlich während der Systemdesignphase festgelegt. Ein Festlegungsverfahren ist in JP-A 57-146361 (1982) beschrieben und demgemäß bekannt. Daher wird hier keine doppelte Beschreibung gegeben.
Die Fig. 16A und 16B zeigen besondere Verarbeitungsbeispiele eines Programms, wie es im verteilten Verarbeitungssystem abgearbeitet wird, wie es in Zusammenhang mit Fig. 15 beschrieben wurde.
In den Fig. 16A und 16B enthält ein Eingabebefehl RECEIVE (A1, CC1) 1602 den Wert CC1, der den Inhaltskode 152 von Fig. 15 bezeichnet. Der Befehl RECEIVE (A1, CC1) 1602 zeigt an, daß der Inhaltskode CC1 zu empfangen und in A1 zu speichern ist.
Entsprechend gibt ein Ausgabebefehl SEND (B1, CC2) 1603 an, daß die Information B1 für den Inhaltskode CC1 übertragen werden soll.
Bei diesem Beispiel werden für das Senden und Empfangen der Mitteilung RECEIVE und SEND anstelle von IN bzw. OUT verwendet.
Das Programm von Fig. 16B wird aus dem Programm von Fig. 16A auf dieselbe Weise erzeugt, wie dies oben in Zusammenhang mit Fig. 2 erläutert wurde.
Das heißt, das RECEIVE (A1, CC1) 1602 von Fig. 16A als Eingabebefehl RECEIVE (A1, CC1) 1611 im ersten Bereich von Fig. 16B angeordnet wird. #A1←A1 1612 gibt an, daß die Information A1 in #A1 geladen werden soll. Darüber hinaus zeigt A1←#A1 1613 an, daß die Information aus #A1 der Größe A1 zugeordnet werden soll.
Auf ähnliche Weise ist SEND (B1, CC1) 1603 von Fig. 16A durch #B1←B1 1614 in Fig. 16B ersetzt, um die Information B1 in #B1 abzuspeichern. Darüber hinaus ist SEND (B1, CC2) 1603 in Fig. 16B als Ausgabebefehl SEND (#B1, CC2) 1615 vorhanden.
Das Programm von Fig. 16B führt im verteilten Verarbeitungssystem von Fig. 1 zu einer Funktion vom Datenflußtyp.
Gemäß den unter Bezugnahme auf die Fig. 1 bis 16 beschriebenen Ausführungsbeispielen kann ein von einem Programmierer ohne Beachtung von I/O-Abläufen erstelltes Programm in ein Programm umgewandelt werden, das gemäß einem Datenfluß arbeitet.
Infolgedessen können Programmkodes für I/O-Befehle und Verarbeitungskodes getrennt werden, was die Möglichkeit verringert, daß ein Programmfehler zum Ausgeben falscher Information oder zum Löschen des Inhalts eines Informationsspeichermediums während der Ausführung des Programms führen kann.
Darüber hinaus kann bei Auftreten eines Fehlers im Programm der Ort des Fehlers leicht lokalisiert werden, was das Ersetzen des Programms vereinfacht.
Insgesamt kann also ein Programm mit erhöhter Zuverlässigkeit, Erweiterbarkeit und vereinfachter Pflegbarkeit erhalten werden, ohne daß der Programmierer hierzu ein besonderes Programm erstellen muß.
Dadurch können durch die Erfindung verschiedene Belastungen vermieden werden, die bisher auf einem Programmierer lagen, wenn er ein Programm zu erstellen hatte, das in einem Rechner vom Datenflußtyp abzuarbeiten war.
Es wird nun ein zweites Ausführungsbeispiel der Erfindung im einzelnen beschrieben.
Fig. 27 zeigt I/O-Daten, wie sie von erfindungsgemäßen Prozessoren gehandhabt werden.
Der Aufbau von Fig. 27 weist eine Unterstützungsverarbeitungseinrichtung 2101 zum Unterstützen der Erzeugung und Ausführung eines Programms gemäß der Erfindung sowie eine I/O-Einrichtung 2115 mit Einrichtungen wie einer Tastatur und einer Anzeigeeinrichtung auf. Daten zur linken und rechten Seite der Unterstützungsverarbeitungseinrichtung 2101 sind Eingabe- bzw. Ausgabedaten. Die Unterstützungsverarbeitungseinrichtung 2101 erhält über die Eingabeeinrichtung 2115 Designinformation 2111 zum laufenden System, Anlagenaufbauinformation 2112, übergeordnete Computerinterfacedaten 2113 und untergeordnete Computerinterfacedaten 2114. Dabei wird die Designinformation zum laufenden System, Daten 2111, von einem Systemdesigner bereitgestellt; hierzu gehören Daten wie der Systemname und eine Länge. Die übergeordnete Computerinterfaceinformation, Daten 2113, beinhalten z. B. im Fall eines Prozeßsteuerungsrechners Daten, die sich auf den Produktionsablauf und das Systemmanagement beziehen. Die untergeordneten Computerinterfacedaten 2114 beinhalten Daten, die einen speziellen Herstellprozeß auf Grundlage des Produktionszeitplans betreffen, z. B. Daten, die sich auf das Öffnen und/oder Schließen eines Ventils beziehen. Die Ausgabeeinrichtung 2115 stellt auf einer Anzeigeeinrichtung Daten dar, wie sie aus der Datenverarbeitung durch den Prozessor 2101 auf Grundlage der Eingangsdaten resultieren. Die Darstellung erfolgt als Systemflußdaten 2141, Kreuzreferenzdaten 2141 zu Inhaltskode/Datengrößen, Kreuzreferenzdaten 2143 zu Funktionsmodul/Inhaltskodedaten, Kreuzreferenzdaten 2144 zu Funktionsmodul/Datengrößendaten, Strukturplausibilitätsbezugsdaten 2145 und Daten von I/O-Befehlen eines Programms 2145. In dieser Hinsicht unterscheidet sich der Systemfluß von einem Steuerfluß, wie er durch ein herkömmliches Flußdiagramm von Verarbeitungsabläufen repräsentiert wird; er beinhaltet einen Datenfluß, der die Inhalte von Funktionen und Spezifizierungen repräsentiert. Im Systemfluß sind Funktionen, die die Grundzüge des Systems (beschrieben in einer Anwendersprache) bezeichnen, in übergeordneten Elementen in einer Baumstrukturkonfiguration zugeordnet, während besondere Spezifikationen (in einer Programmiersprache geschrieben) untergeordneten Elementen der Konfiguration zugeführt werden. Die anderen Kreuzreferenzdaten 2142 bis 2144 sind Tabellen, auf die unter dem Gesichtspunkt jeder der obigen Beschreibungen zugegriffen wird.
Nun wird die Grundfunktion der Programmentwicklungsunterstützung beschrieben, wie sie durch die Erfindung gegeben wird.
Wie oben angegeben, werden beim herkömmlichen Programmerzeugungsverfahren Daten über eine gemeinsame Tabelle übertragen. Im Gegensatz hierzu werden bei der Erfindung ohne gemeinsame Tabelle Daten direkt zum Datenaussenden übertragen. Die übertragenen Daten können durch jeden Nutzer im System empfangen werden. Dementsprechend sind bei der Erfindung Funktionen zum Einschreiben von Daten in die Tabelle, zum Lesen von Daten daraus und zum Angeben der Datenadresse nicht erforderlich, welche Daten herkömmlich bei der Datenübertragung erforderlich sind. Beim Empfangen von Daten muß ein Programm nur direkt Verarbeitung der Daten ausführen, um das Ergebnis der Verarbeitung auszugeben. Infolgedessen kann ein Job an derjenigen Position begonnen werden, an der Daten empfangen werden. Infolgedessen kann ein Programm nur mit I/O-Spezifikationen erzeugt werden. In diesem Fall kann ein interner Verarbeitungsteil des Programms getrennt später erzeugt werden.
In diesem Hinblick können für eine gewisse mit Inhaltskodes A, B, C, F1 und D auszuführende Verarbeitung zugeordnete Programme nur für die empfangenen Datengrößen erzeugt werden, wenn jeweils Datengrößen mit den Inhaltskodes A, B und C empfangen werden. Wenn ein Job für den Inhaltskode F1 nur ausgeführt werden kann, wenn die Inhaltskodes A bis D vorhanden sind, und Verarbeitung für den Inhaltskode D im Normalfall nicht ausgeführt wird, werden die Verarbeitung für den Inhaltskode F1 und die dem Inhaltskode D zugeordnete Verarbeitung getrennt erzeugt, was zu Inkonsistenz führt. Dementsprechend ist es beim obigen Verfahren wesentlich, Konsistenz aufrechtzuerhalten.
Fig. 17 zeigt Daten, Tabellen und Programme, die bei einer erfindungsgemäßen Programmentwicklungs-Verarbeitungsvorrichtung 2110 verwendet werden.
Der Prozessor 2100 wird mit einer Gruppe von Eingangsdatendateien versorgt, wie einer Inhaltskodedatei 2131, einer Datengrößendatei 2132 und einer Funktionsmoduldatei 2133. Er enthält auch eine Gruppe von Tabellen, wie eine Systemflußtabelle 2181, eine Inhaltskode/Datengrößen-Kreuztabelle 2182, eine Funktionsmodul/Inhaltskode-Kreuztabelle 2183 und eine Funktionsmodul/Datengrößen-Kreuztabelle 2184.
Die Gruppe der Eingangsdatendateien wird durch Programme erzeugt, die im System vorhanden sind, wie ein Inhaltskode-Editierprogramm 2121, ein Datengrößen-Editierprogramm 2122 und ein Funktionsmodul-Editierprogramm 2125.
Darüber hinaus wird die Gruppe von Tabelle durch einen Satz von Programmen erzeugt, wie einem Systemfluß-Integrationsprogramm 2126, einem Inhaltsdaten/Datengrößen-Integrationsprogramm 2127, einem Funktionsmodul/Inhaltskode-Integrationsprogramm 2128 und einem Funktionsmodul/Datengrößen-Integrationsprogramm 2129.
Darüber hinaus weist der Aufbau ein Strukturplausibilitäts-Überprüfungsprogramm 2123 zum Ausführen einer Überprüfung der Modulstruktur und ein Programm 2124 zum automatischen Erzeugen von I/O-Befehlen zum Erzeugen einer I/O-Befehlsprogramm-Quelldatei 2186 auf.
Der Prozessor 2100 von Fig. 17 editiert Eingangsdaten, um auf Grundlage des Inhaltskode-Editierprogramms 2121, des Datengrößen-Editierprogramms 2122 und des Funktionskodemodul-Editierprogramms 2125 eine Inhaltskodedatei 2131, eine Datengrößendatei 2132 und eine Funktionsmoduldatei 2133 zu erstellen. Die Inhaltskodedatei 2131 repräsentiert den Inhalt von Datengrößen als Satz; die Datengrößendatei 2132 speichert Attribute zu jeweiligen Datengrößen wie Länge, Typ, Wertebereich und Name; und in der Funktionsmoduldatei 2133 sind externe Spezifikationen jedes Moduls mit Namen und Inhaltskodes der I/O-Daten derselben repräsentiert.
Anschließend wird das Designinformations-Integrationsprogramm 2126 ausgeführt, um zur Ausgabe, wie in Fig. 27 dargestellt, die Inhaltskode/Datengrößen-Kreuzreferenz 2142, die Funktionsmodul/Inhaltskode-Kreuzreferenz 2143, die Funk­ tionsmodul/Datengrößen-Kreuzreferenz 2144 und das Systemflußdiagramm 2141 zu erzeugen.
Das Programm 2124 zur automatischen Erzeugung von Programmbefehlen wird ausgeführt, um I/O-Programmbefehle aus Werten der Inhaltskodedatei 2131, der Datengrößendatei 2132 und der Funktionsmoduldatei 2133 zu erzeugen. Die erhaltenen I/O-Befehle bilden ein Programm von I/O-Befehlen, das das gemäß der Erfindung endgültig zu erzeugende Objekt ist.
Fig. 18 zeigt die Inhaltskodedatei von Fig. 17 im einzelnen.
Die Inhaltskodedatei 2131 beinhaltet einen Inhaltskode 2021, der einen Kode angibt, wie er Datengrößennamen 2023 zugeordnet ist, die einem Datengrößenzählwert 2022 entsprechen. Dieses Format wird für jeden Inhaltskode 2021 wiederholt erzeugt. Der Inhaltskode 2021 stellt Größen wie einen Managementzeitplan, ein Überwachungsverfahren und Lagerhaltung dar. Die Größe ist weiter in mehrere konkrete Größen unterteilt, um Datengrößen zu implementieren, die den jeweiligen Inhaltskodes 2021 zugeordnet sind (z. B. als Temperatursteuerung, Geschwindigkeitszunahme oder Ventilbetätigung bezeichnet).
Fig. 19 zeigt Einzelheiten der Datengrößendatei von Fig. 17.
Die Datengrößendatei 2132 beinhaltet Dateielemente, von denen jedes einen Datengrößennamen 2031, Informationsgrößen und ein Hinweis 2035 für das Vorhandensein oder Fehlen eines Vorzeichens aufweisen. Die Informationsgrößen repräsentieren Attribute zum Namen, wie die Dateneinheitslänge 2032, einen Arrayzählwert 2033 des Elements und einen Datenkode 2034. Dieses Format tritt wiederholt für jeden Datengrößennamen 2031 in der Datei 2132 auf.
Fig. 20 zeigt Einzelheiten des Inhalts der Funktionsmoduldatei 2133 von Fig. 17.
Die Funktionsmoduldatei 2133 ist mit einem Modulnamen 2041, einer Modullänge 2042, einem Eingabeinhalts-Kodezählwert 2044, einem Ausgabeinhalts-Kodezählwert 2045, Eingabeinhaltskodes 2043 und Ausgabeinhaltskodes 2046 geladen. Die Modullänge 2042 bezeichnet die Länge eines Programms, wie es durch den Modulnamen 2041 repräsentiert ist. Durch den Eingabeinhalts-Kodezählwert 2044 wird die Anzahl von Eingabeinhaltskodes 2043 bezeichnet, die als Eingaben in den Modul erforderlich sind. Darüber hinaus gibt der Ausgabeinhalts-Kodezählwert 2045 die Anzahl von Ausgabeinhaltskodes 2046 an, die in der Daten 2133 aufgezeichnet sind.
Fig. 21 zeigt Einzelheiten der Inhaltskode/Datengrößen-Kreuzreferenztabelle von Fig. 24.
In dieser Figur sind Abkürzungen für den Inhaltskode 2021 von Fig. 18, d. h. Y00S4, YB1002, YB2003 usw. entlang der Horizontalen angeordnet, wohingegen Datengrößennamen 2031 von Fig. 19 wie bftoadr, coildie, coildii und coilno entlang der Vertikalen aufgetragen sind. In dieser Liste sind Beziehungen, die zwischen den Inhaltskodes 2021 und den Datengrößennamen 2031 bestehen, mit Sternchen markiert. Inhaltskodes 2021 sind übergeordneten Funktionen zugeordnet, z. B. einem Managementzeitplan, einem Produktionsplan und einem Überwachungsschema. Datengrößennamen 2021 spezifizieren Datengrößen, die sich auf untergeordnete Funktionen beziehen, wie auf eine besondere Maßnahme, die beim tatsächlichen Ausführen des Managementzeitplans, einem Herstellprozeß gemäß dem Produktionsplan und beim Öffnen/Schließen eines Ventils gemäß dem Überwachungsschema auszuführen ist.
Infolge der Überprüfung durch die Inhalte der Inhaltskode/­ Datengrößen-Kreuzreferenztabelle 2142 wird eine Warnmitteilung angezeigt, wenn unterschiedliche Inhaltskodes 2021 für Datengrößennamen 2031 bestehen, die völlig miteinander übereinstimmen, um auf die Möglichkeit doppelter Definition hinzuweisen. Wenn z. B. für den Inhaltskode YD3B1 dem Datengrößen 3 coilno, 8 cc, 17 saisoid und 1928bcc zugeordnet sind, ein Inhaltskode gefunden wird, dem dieselben ihn bildenden Datengrößen zugeordnet sind, wird die Warnanzeige für doppelte Definition auf der Anzeigeeinrichtung dargestellt.
Fig. 22 zeigt Einzelheiten zum Inhalt der Funktionsmodul/In­ haltskode-Kreuzreferenztabelle 2143 von Fig. 27. In diesem Diagramm sind Abkürzungen von Modulnamen 2041 wie A-A DRS RC, A-I COW RK usw. entlang der Horizontalen angeordnet, während Abkürzungen für Inhaltkodes 2021 wie Y00S4 und YB002 entlang der Vertikalen angeordnet sind. Buchstaben I und O bezeichnen jeweils Ausgabe- bzw. Eingabeinhaltskodes 2043 und 2046, die dem Modulnamen 2041 zugeordnet sind. Wenn unterschiedliche Modulnamen 2041 jeweils Inhaltskodes 2021 aufweisen, denen übereinstimmende Eingabe- und Ausgabeinhaltskodes 2043 bzw. 2046 zugeordnet sind, wird eine Warnmitteilung dargestellt, um auf die Möglichkeit doppelter Definition hinzuweisen.
Fig. 23 zeigt im einzelnen die Funktionsmodul/Datengrößen-Kreuzreferenzliste 2144 von Fig. 27.
In diesem Diagramm sind Abkürzungen von Modulnamen 2041 wie A-A DRS RC und A-I COW RK entlang der Horizontalen angeordnet, während Bezeichnungen von Datengrößennamen 2031 wie bftoadr, coildie usw. entlang der Vertikalen angeordnet sind. In dieser Tabelle geben Buchstaben I und O jeweils an, ob der Datengrößenname 2031 einen Eingabe- und einen Ausgabedatenwert für den Modulnamen 2041 darstellt.
Fig. 24 zeigt Einzelheiten zum Systemflußdiagramm von Fig. 27.
Bei diesem Ablauf bezeichnet ein rechteckiger Rahmen einen Modul, wobei die Abkürzung des Modulnamens 2041 eingeschrieben ist. Pfeile bezeichnen einen Inhaltskode 2021. Ein Modul als Ausgangspunkt eines Pfeils nimmt den Inhaltskode 21 als Ausgangsinhaltskode 2046 an (Fig. 20). Der Ausgangsinhaltskode 2046 wird unten im Diagramm dargestellt. Ein Modul als Ziel eines Pfeiles nutzt den Inhaltskode 2021 als Eingangsinhaltskode 2043 (Fig. 20). Wenn ein rechteckiger Rahmen spezifiziert wird, stellt das System im unteren Bereich der Anzeige den Eingabeinhaltskode 2043 (YB1003), die Ausgabeinhaltskodes 2046 (YG4S6 und YG4G) und die Datengrößennamen 2031 (subcc, wrktbno usw.) dar, die zum Ausgabeinhaltskode 2046 gehören.
Fig. 25 zeigt im einzelnen die Verarbeitung von Fig. 17 zum automatischen Erzeugen von I/O-Programmbefehlen.
Die Anordnung von Fig. 25 beinhaltet eine Funktionskodedatei 2131, eine Datengrößendatei 2132, eine Funktionsmoduldatei 2133, ein Programm 2124 zum automatischen Erzeugen eines I/O-Programms und ein I/O-Spezifizierungsprogramm 2091. Das I/O-Spezifizierungsprogramm 2091 weist einen Eingabebefehlsteil 2096 und einen Ausgabebefehlsteil 2097 auf.
Das Programm 2124 zum automatischen Erzeugen eines I/O-Programms liest von der Funktionsmoduldatei 2133 einen Eingabeinhaltskode 2043 und einen Ausgabeinhaltskode 2046 (Fig. 20), die sich auf einen spezifizierten Modul beziehen, um eine Suche in der Funktionskodedatei 2131 auszuführen, wobei ein zugeordneter Inhaltskode 2121 (Fig. 18) als Suchschlüssel gesetzt ist, wodurch die zugeordneten Datengrößennamen 2031 (Fig. 19) aufgefunden werden. Anschließend werden den Datengrößennamen 2031 zugeordnete Attribute aus der Datengrößennamendatei 2132 gelesen. Auf Grundlage der Attribute (Fig. 19), die durch die Dateneinheitslänge 2032, den Arrayzählwert 2033 für ein Element, den Datenkode 2034 und den Hinweis 2035 auf das Vorhandensein oder Fehlen eines Vorzeichens repräsentiert sind, wird ein Eingabebefehl 2092 des I/O-Spezifizierprogramms 2091 ausgeführt, um Daten zu erhalten. Mit Hilfe der erhaltenen Daten erzeugt das Programm 2091 einen Befehl 2094 zum Unterteilen von Eingabedaten entsprechend den Attributen für jeden Datengrößennamen 2031, also entsprechend der Dateneinheitslänge 2032, dem Arrayzählwert 2033 für jedes Element, dem Datenkode 2034 und dem Hinweis 2035 auf ein Vorzeichen, wodurch der Eingabebefehlsteil 2096 entwickelt wird. Um Daten entsprechend einem Ausgabeintegrationsbefehl 2093 des I/O-Spezifizierungsprogramms 2091 auszugeben, wird ein Ausgabebefehlsteil 2097 verwendet, der einen Prozeß zum Integrieren von Ausgabefunktionen auf Grundlage der Attribute für jeden Ausgangsdatengrößennamen 2031 herbeiführt. In diesem Hinblick führt der Eingabebefehlsteil 2096 Verarbeiten zum Unterteilen von Gruppen von Funktionen in kleinere Funktionsgruppen aus, wohingegen der Ausgabebefehlsteil Verarbeitung zum Zusammensetzen von einander getrennter Funktionen in geeignete Funktionsgruppen ausführt.
Fig. 26 zeigt einen Prozeß von Abläufen bis zum Initialisieren des I/O-Spezifizierungsprogramms 2091.
Information, die zum Erzeugen eines I/O-Spezifizierungsprogramms 2091 erforderlich ist, wird von der Datengrößendatei 2132, der Funktionsmoduldatei 2133 und der Inhaltskodedatei 2134 erfaßt. Es wird dann das automatische Erzeugen 2124 für das I/O-Befehlsprogramm ausgeführt, um die erhaltene Information so zu verarbeiten, daß ein I/O-Spezifizierungsprogramm 2091 erstellt wird. Danach wird das Programm 2091 einer Kompilier- und Linkverarbeitung 2101 unterworfen, um einen ausführbaren Modul 2102 zu erzeugen.
Eine Verarbeitung 2103 zum Registrieren und Speichern von Funktionsmodulen registriert und speichert dann den Modul 2102 für spätere Ausführung. Dabei führt die Kompilier- und Linkverarbeitung 2102 ein Kompilieren zum Übersetzen des Programms 2091 in ein Programm in Rechner- oder Maschinensprache um und führt dann ein Linken des Programms aus, um das erhaltene Programm in eine Einheit umzuwandeln, die von einem Rechner ausführbar ist. Ein Skelettlademodul 2102 beinhaltet nur Eingabe- und Ausgabebefehle, also keine interne Verarbeitung.
Fig. 28 ist ein Flußdiagramm, das den Verarbeitungsablauf des Inhaltskodeeditierens oder des Editierprogramms 2121 von Fig. 17 veranschaulicht.
Im Inhaltskodeeditierprogramm 2121 wird zunächst der Editiertyp bestimmt (Schritt 2121). Für ein neues Registrieren wird die Inhaltskodedatei 2131 durchsucht, um eine Doppelprüfung auszuführen, um zu bestimmen, ob die Registrierdaten bereits in der Daten 2131 registriert wurden oder nicht (Schritt 2122). Falls dies nicht der Fall ist, werden die Daten in die Inhaltskodedatei 2131 eingetragen (Schritte 2123 und 2124). Wenn Daten bereits registriert wurden (Schritt 2123), wird die Verarbeitung an dieser Stelle beendet. Wenn der Editiertyp Korrektur anzeigt, wird die Inhaltskodedatei 2131 durchsucht, um eine Prüfung in ähnlicher Weise wie beim Registrieren vorzunehmen (Schritt 2128). Wenn die gesuchte Stelle in der Inhaltskodedatei 2131 gefunden wird (Schritt 2129), wird der Inhalt an der Stelle korrigiert (Schritt 2130). Wenn der Editiertyp Löschung ist, wird die Inhaltskodedatei 2131 durchsucht, um mit den gesuchten Daten dieselbe Prüfung auszuführen wie oben beschrieben (Schritt 2125). Wenn die gesuchten Daten gefunden werden (Schritt 2126), wird der Inhaltskode aus der Datei 2131 gelöscht (Schritt 2127).
Fig. 29 ist ein Flußdiagramm, das den Verarbeitungsablauf des Datengrößeneditierprogramms 2122 von Fig. 17 veranschaulicht.
Zunächst wird der Editiertyp festgelegt (Schritt 2131). Wenn der Typ Neuregistrierung angibt, wird die Datengrößendatei 2132 durchsucht, um die zu registrierenden Daten auf doppelte Definition hin zu überprüfen (Schritt 2132). Falls dies nicht der Fall ist (Schritt 2133), werden die Daten in der Datengrößendatei 2132 gespeichert (Schritt 2134). Wenn eine Doppeldefinition aufgefunden wird (Schritt 2133), wird die Verarbeitung an dieser Stelle beendet. Wenn der Editiertyp Korrektur angibt, wird die Datengrößendatei 2132 durchsucht (Schritt 2138), um eine Prüfung in ähnlicher Weise wie beim Registrieren vorzunehmen. Wenn ein gesuchter Ort im Datengrößenspeicher 2132 gefunden wird (Schritt 2139), wird der Inhalt an dieser Stelle korrigiert (Schritt 2140). Wenn der Editiertyp Löschung angibt, wird der Datengrößenspeicher 2132 durchsucht, um die gesuchten Daten aufzufinden (Schritt 2135). Wenn diese gefunden werden (Schritt 2136), werden sie aus der Daten 2132 gelöscht (Schritt 2137).
Fig. 30 ist das Flußdiagramm, das den Verarbeitungsablauf des Funktionsmoduleditierprogramms 2125 von Fig. 17 zeigt.
Bei diesem Programm 2125 wird zunächst der Editiertyp bestimmt (Schritt 2141). Wenn der Typ Neuregistrierung ist, wird die Funktionsmoduldatei 2133 durchsucht, um eine Überprüfung auf Doppeldefinition in bezug auf die Registrierdaten vorzunehmen (Schritt 2142). Ist dies nicht der Fall (Schritt 2143), werden die Daten in der Funktionsmoduldatei 2133 abgelegt (Schritt 2144). Wenn eine Doppeldefinition gefunden wird (Schritt 2143), wird die Verarbeitung an dieser Stelle beendet. Wenn der Editiertyp Korrektur anzeigt, wird die Funktionsmoduldatei 2133 durchsucht (Schritt 2148), um eine Überprüfung in ähnlicher Weise wie oben angegeben auszuführen. Wenn die zu korrigierenden Daten in der Datei 2133 gefunden werden, werden diese korrigiert (Schritt 2150).
Wenn der angegebene Editiertyp Löschen ist, wird die Funktionsmoduldatei 2133 durchsucht, um die gesuchten Daten aufzufinden (Schritt 2145). Wenn die gesuchten Daten vorhanden sind (Schritt 2146), werden sie aus der Datei 2133 gelöscht (Schritt 2147).
Fig. 31 zeigt den Inhalt der Systemflußtabelle 2181 von Fig. 17.
Wenn der Systemfluß dargestellt wird, wird die Systemflußtabelle 2181 mit einem Kopfteil geladen, der eine Seitennummer 2811, eine Spaltennummer 2812 der Seite und einen zugehörigen Funktionsmodulzählwert 2813 für in der Spalte zu beschreibende Module angibt. Für jeden zugehörigen Modulnamen 2814 werden nach jedem Kopfteil ein Eingabeinhaltskodezählwert 1815, Eingabeinhaltskodes 2816, ein Ausgabeinhaltskodezählwert 2817 und zugeordnete Ausgabeinhaltskodes 2818 angegeben.
Fig. 32 zeigt den Inhalt der Inhaltskode/Datengrößen-Kreuztabelle 2182 von Fig. 17.
Die Inhaltskode/Datengrößen-Kreuztabelle 2182 weist Elemente auf, die jeweils einen Datengrößennamen 2821, einen diesem zugeordneten Inhaltskodezählwert 2822 und zugeordnete Inhaltskodenamen 2823 umfassen.
Fig. 33 zeigt den Inhalt der Funktionsmodul/Inhaltskode-Kreuztabelle 2183 von Fig. 17.
Diese Funktionsmodul/Inhaltskode-Kreuztabelle 2183 ist aus Elementen aufgebaut, von denen jedes einen Funktionsmodulnamen 2835 und zugeordnete Größen wie einen Eingabeinhaltskodezählwert 2831, Eingabeinhaltskodes 2832, einen Ausgangsinhaltskodezählwert 2833 und Ausgangsinhaltskodes 2834 aufweist.
Fig. 34 zeigt den Inhalt der Funktionsmodul/Datengrößen-Kreuztabelle 2184 von Fig. 17.
Diese Funktionsmodul/Datengrößen-Inhaltstabelle 2184 weist Elemente auf, die jeweils einen Funktionsmodulnamen 2841 und zugeordnete Größen wie einen Eingangsdatengrößenzählwert 2842, Eingangsdatengrößennamen 2843, einen Ausgangsdatengrößenzählwert 2844 und Ausgangsdatengrößennamen 2845 umfaßt.
Fig. 35 zeigt den Inhalt der I/O-Befehlsprogramm-Quelldatei 2186 von Fig. 17. Diese I/O-Befehlsprogramm-Quelldatei 2186 wird aus Elementen gebildet, von denen jedes einen Programmnamen 2861 und die zugeordnete Programmlänge 2862 angibt.
Fig. 36 ist ein Flußdiagramm, das den Verarbeitungsablauf des Systemflußintegrationsprogramms 2126 von Fig. 17 zeigt.
Dieses Programm 2126 liest die Funktionsmoduldatei 2133 (Schritt 2201), um Daten für einen Funktionsmodul zu erfassen (Schritt 2202). Eine Suchfunktion wird mit einem Eingabeinhaltskode desselben ausgeführt (Schritt 2203), um aufeinanderfolgend Funktionsmodule aufzuspüren, die den Eingabeinhaltskode ausgeben, bis die Dateidaten ganz verarbeitet sind (Schritt 2206). Anschließend wird ein Suchablauf in ähnlicher Weise mit einem Ausgangsinhaltskode ausgeführt, um Funktionsmodule aufzufinden, die den Ausgangsinhaltskode annehmen. Die vorstehend angegebenen Abläufe werden aufeinanderfolgend für einen Funktionsmodul, der einen Ausgangsinhaltskode annimmt, und dann für einen Funktionsmodul, der den Ausgang von einem Funktionsmodul annimmt, wiederholt ausgeführt (Schritt 2204), bis die Datendaten vollständig abgearbeitet sind (Schritt 2206). Auf diese Weise werden für einen Funktionsmodul ein Aufwärtsfluß und ein Abwärtsfluß durch einen Editierablauf erzeugt (Schritt 2205).
Fig. 37 ist ein Flußdiagramm, das den Verarbeitungsablauf des Inhaltskode/Datengrößen-Integrationsprogramms 2127 von Fig. 17 zeigt.
Das Programm 2127 liest zunächst die Inhaltskodedatei 2131 (Schritt 2211), um Inhaltskodedaten zu erhalten (Schritt 2212), um Inhaltskodedaten zu erfassen (Schritt 2213). Es wird dann für Datengrößen mit anderen Inhaltskodes gesucht, um Anwesenheit oder Fehlen von Datengrößen mit demselben Namen festzustellen (Schritt 2214). Ist eine solche Größe vorhanden (Schritt 2215), wird registriert, daß die betreffende Datengröße zum erfaßten Inhaltskode und zu dem aus der Überprüfung resultierenden Inhaltskode gehört (Schritt 2216). Dieser Ablauf wird für jede Datengröße in Zuordnung zu jedem Inhaltskode ausgeführt (Schritte 2217 und 2218), wodurch die Inhaltskode/Datengrößen-Kreuztabelle 2183 erzeugt wird.
Fig. 38 zeigt den Verarbeitungsablauf des Funktionsmodul/In­ haltskode-Integrationsprogramms 2128 von Fig. 17.
Das Programm 2128 liest zunächst die Funktionsmoduldatei 2133 (Schritt 2221), um einen Funktionsmodul zu erfassen (Schritt 2222). Von den I/O-Inhaltskodes des Moduls wird ein Inhaltskode erhalten (Schritt 2223), um eine Suche auszuführen, um zu entscheiden, ob der Inhaltskode bereits als I/O-Inhaltskode eines anderen Funktionsmoduls gesetzt wurde (Schritt 2224). Wenn die Suche ergibt, daß dies der Fall ist (Schritt 2225), wird registriert, daß der Inhaltskode zu den so ermittelten Funktionsmodulen gehört (Schritt 2226). Das Verarbeiten wird wiederholt für die I/O-Inhaltskodes jedes Funktionsmoduls ausgeführt (Schritte 2227 und 2228), um die Funktionsmodul/Inhaltskode-Kreuztabelle 2183 zu erzeugen.
Fig. 39 zeigt den Verarbeitungsablauf des Funktionsmodul/Da­ tengrößen-Integrationsprogramms 2129 von Fig. 17.
Dieses Programm 2129 liest zunächst die Funktionsmoduldatei 2133 (Schritt 2331), um eine Datengröße zu erhalten, die zum zugehörigen I/O-Inhaltskode gehört (Schritt 2232 und 2233). Es wird dann eine Suche ausgeführt, um einen Inhaltskode zu erfassen, der der Datengröße zugeordnet ist (Schritt 2234). Darüber hinaus wird eine Suche ausgeführt, um andere Funktionsmodule zu ermitteln, die den Inhaltskode als I/O-Inhaltskode aufweisen (Schritt 2235). Obige Funktion wird wiederholt für alle I/O-Datengrößen der jeweiligen Funktionsmodule ausgeführt (Schritte 2237 und 2238), um die Funktions­ modul/Datengrößen-Kreuztabelle 2184 zu erzeugen.
Fig. 40 ist ein Flußdiagramm, das den Verarbeitungsablauf des Strukturplausibilitäts-Überprüfungsprogramms 2123 von Fig. 17 zeigt.
In diesem Programm 2123 wird zunächst eine Lesefunktion mit der Funktionsmoduldatei 2133 ausgeführt (Schritt 2241), um einen I/O-Inhaltskode zu erhalten (Schritt 2242). Mit dem Inhaltskode wird eine Suchfunktion ausgeübt, um Stromaufwärts- und Stromabwärts-Funktionsmodule (Schritt 2243) zu bestimmen, um eine Schleifenprüfung zu bewerkstelligen, um dadurch festzustellen, ob ein identischer Funktionsmodul zweimal oder noch öfter auftritt (Schritt 2244). Ist dies der Fall (Schritt 2245), wird eine Fehlermitteilung ausgegeben (Schritt 2250). Anschließend wird überprüft, ob ein Ausgabeinhaltskode des Funktionsmoduls als Eingabeinhaltskode eines anderen Funktionsmoduls angenommen wird (Schritt 2246). Wenn der Ausgabeinhaltskode nicht als Eingabeinhaltskode verwendet wird (Schritt 2247), wird eine Warnmitteilung ausgegeben, um darauf hinzuweisen, daß die Ausgabe nicht verwendet wird (Schritt 2251). Anschließend wird eine Überprüfung ausgeführt, um festzustellen, ob ein anderer Funktionsmodul den Eingabeinhaltskode des Funktionsmoduls ausgibt (Schritt 2248). Ist dies nicht der Fall (Schritt 2249), wird eine Warnmitteilung ausgegeben, um zu melden, daß keine Eingabe erzeugt wurde (Schritt 2252).
Fig. 41 ist ein Flußdiagramm, das den Verarbeitungsablauf des Programms 2124 des automatischen Erzeugens von I/O-Befehlen von Fig. 17 darstellt.
Dieses Programm 2124 liest zunächst die Funktionsmoduldatei 2133 (Schritt 2251), um Daten für einen Funktionsmodul aus der Daten 2132 zu erhalten, um aufeinanderfolgend Eingabeinhaltskodes zu erfassen (Schritt 2252), wodurch eine unterteilende Verarbeitung mit den Datengrößen vorgenommen wird, um Datengrößen abzutrennen, die zum Inhaltskode gehören (Schritt 2253). Die Verarbeitung wird für alle Datengrößen der jeweiligen Eingabeinhaltskodes ausgeführt (Schritt 2254). Anschließend führt das System für einen Ausgabeinhaltskode eine Verarbeitung aus, um Datengrößen mit zugeordneten Ausgabeinhaltsgrößen in ähnlicher Weise zu kombinieren (Schritte 2255 und 2256). In diesem Fall wird eine Verarbeitung auch für jede Datengröße des zugehörigen Ausgabeinhaltskodes ausgeführt (Schritt 2257).
Durch den vorstehend beschriebenen Verarbeitungsablauf wird die I/O-Programm-Quelldatei 2186 erzeugt.
Wie oben angegeben, werden bei den Ausführungsbeispielen der Erfindung Softwaremodule gleichzeitig erzeugt, und die Integrität zwischen denselben wird automatisch überprüft. Dies erhöht demgemäß die Produktivität der Programme gesehen über den gesamten Programmerzeugungsprozeß. Da darüber hinaus I/O-Befehle eines Programms für sich automatisch erzeugt werden können, wird die Effizienz beim Programmieren erhöht.

Claims (8)

1. Programmverarbeitungsverfahren in einem verteilten Verarbeitungssystem mit einem Übertragungsmedium (3) und mehreren mit diesem verbundenen Prozessoren (21, 22, 23), bei dem eine Verarbeitungsfolge in verteilter Weise ausgeführt wird und bei dem Programme, die die Verarbeitungsfolge ausführen, an die mehreren Prozessoren verteilt und in diesen gespeichert werden, mit:
  • - einem Schritt (202, 206) zum Ermitteln eines Programmkodes für Eingabebefehle und eines Programmkodes für Ausgabebefehle in einem neuen Programm durch die Prozessoren, das in Übereinstimmung mit einem vorgegebenen Programmkode geschrieben ist, welcher Schritt von den Prozessoren ausgeführt wird, wenn sie das Programm speichern;
  • - einem Schritt (203, 204, 205) zum Umordnen der ermittelten Programmkodes im Programm, wobei der Programmkode für Eingabebefehle an einem Ort vor einem anderen Verarbeitungsteil und der Programmkode für Ausgabebefehle an einem Ort nach dem anderen Verarbeitungsteil angeordnet wird;
  • - einem Schritt (207, 208, 209) zum Ausführen der Eingabebefehle des Programms vor der anderen Verarbeitung und zum Ausführen der Ausgabebefehle nach der anderen Verarbeitung, wenn Information, die zum Ausführen des Programms erforderlich ist, ganz empfangen wurde, welche Information als Eingangsinformation verwendet wird; und
  • - einem Schritt (210) zum Übertragen von Information, die aus der so ausgeführten Verarbeitung resultiert, an das Übertragungsmedium.
2. Programmverarbeitungsverfahren nach Anspruch 1, bei dem die über das Übertragungsmedium übertragene Information mit einem Inhaltskode (152) versehen wird, der den Inhalt der Information anzeigt, mit:
  • - einem Schritt zum Speichern von Inhaltskodes für Informationen durch den Prozessor, wie sie zum Ausführen eines neuen Programms erforderlich sind, das in Übereinstimmung mit einem vorgegebenen Programmkode geschrieben ist, welcher Schritt ausgeführt wird, wenn der Prozessor das Programm speichert;
  • - einem Beurteilungsschritt durch den Prozessor zum Bestimmen, wenn der Prozessor die Information vom Übertragungsmedium erhält, ob die Information für die Ausführung eines Programms auf Grundlage der gespeicherten Inhaltskodes erforderlich ist;
  • - einem Schritt zum Betreiben des Programms durch den Prozessor zum Ausführen der Verarbeitung, wenn die zum Ausführen des Programms erforderliche Information ganz empfangen wurde; und
  • - einem Schritt zum Zuordnen eines Inhaltskodes zu Information durch den Prozessor, die aus der Ausführung des Programms resultiert, und zum Übertragen der Information an das Übertragungsmedium, wobei der Inhaltskode den Inhalt der Information anzeigt.
3. Programmverarbeitungsvorrichtung in einem verteilten Verarbeitungssystem mit einem Übertragungsmedium (3) und mehreren an dieses angeschlossenen programmverarbeitenden Vorrichtungen oder Prozessoren (21, 22, 23), durch welche Vorrichtung eine Folge von Verarbeitungen in verteilter Weise ausgeführt wird und in der Programme, die die Folge von Verarbeitungen ausführen, an die mehreren Prozessoren verteilt und in diesen gespeichert werden, mit:
  • - einer Einrichtung (21, 22, 23) zum Ermitteln eines Programmkodes für Eingabebefehle und eines Programmkodes für Ausgabebefehle in einem neuen Programm, das in Übereinstimmung mit einem vorgegebenen Programmkode bei seinem Speichern geschrieben wird;
  • - einer Einrichtung (21, 22, 23) zum Umordnen der ermittelten Programmkodes im Programm, wobei der Programmkode für Eingabebefehle an einem Ort vor einem anderen Verarbeitungsteil und der Programmkode für Ausgabebefehle an einem Ort nach dem anderen Verarbeitungsteil angeordnet wird;
  • - einer Einrichtung (21, 22, 23) zum Ausführen der Eingabebefehle des Programms vor der anderen Verarbeitung und zum Ausführen der Ausgabebefehle nach der anderen Verarbeitung, wenn Information, die zum Ausführen des Programms erforderlich ist, ganz empfangen wurde, welche Information als Eingangsinformation verwendet wird; und
  • - einer Einrichtung (11, 12, 13) zum Übertragen von Information, die aus der so ausgeführten Verarbeitung resultiert, an das Übertragungsmedium.
4. Programmverarbeitungsvorrichtung nach Anspruch 1, bei der über das Übertragungsmedium übertragene Information mit einem Inhaltskode (152) versehen ist, der den Inhalt der Information (2121) anzeigt, mit:
  • - einer Einrichtung (21, 22, 23) zum Speichern von Inhaltskodes von Information, wie sie zum Ausführen eines neuen Programms erforderlich ist, das in Übereinstimmung mit einem vorgegebenen Programmkode geschrieben ist, welcher Schritt ausgeführt wird, wenn der Prozessor das Programm speichert;
  • - einer Einrichtung (21, 22, 23) zum Beurteilen, wenn der Prozessor die Information vom Übertragungsmedium erhält, ob die Information für die Ausführung eines Programms auf Grundlage der gespeicherten Inhaltskodes erforderlich ist;
  • - einer Einrichtung (21, 22, 23) zum Betreiben des Programms zum Ausführen der Verarbeitung, wenn die zum Ausführen des Programms erforderliche Information ganz empfangen wurde; und
  • - einer Einrichtung (11, 12, 13) zum Zuordnen eines Inhaltskodes zu Information, die aus der Ausführung des Programms resultiert, und zum Übertragen der Information an das Übertragungsmedium, wobei der Inhaltskode den Inhalt der Information anzeigt.
5. Programmverarbeitungsverfahren zum Verarbeiten eines Programms mit mehreren Softwaremodulen, die miteinander durch das Austauschen von Mitteilungsdaten verbunden sind, mit:
  • - einem Schritt (Fig. 26) zum Unterteilen des Programms mit den Softwaremodulen in einen Eingabebefehlsteil, einen Ausgabebefehlsteil und einen Anwendungsverarbeitungsteil und zum Erzeugen hieraus eines Programms, das Befehle enthält, die nur dem Eingabe- und Ausgabebefehlsteil zugeordnet sind;
  • - einem Schritt (2101) des Kompilierens des Programms zum Erzeugen eines Objektmoduls desselben;
  • - einem Schritt (2101) zum Linken des Objektmoduls zum Erzeugen eines ausführbaren Moduls; und
  • - einem Schritt (2103) zum Registrieren des Ausführungsmoduls für eine tatsächliche Umgebung des Programms.
6. Programmverarbeitungsverfahren nach Anspruch 5, bei dem der Schritt des Erzeugens des Programms, das nur den Eingabe- und Ausgabebefehlsteil enthält, einen Schritt (2124) des automatischen Erzeugens durch eine Programmverarbeitung von Beschreibungen von Datenspezifikationen umfaßt, die Eingabe- und Ausgabeabläufe festlegen.
7. Programmverarbeitungsverfahren nach Anspruch 5, bei dem der Schritt des Erzeugens des ausführbaren Moduls aus dem Objektmodul einen Schritt (2091) des automatischen Erzeugens des Ausführungsmoduls nur durch Programmverarbeitung aufweist.
8. Programmverarbeitungsverfahren nach Anspruch 5, bei dem der Schritt des Registrierens des ausführbaren Moduls für die tatsächliche Umgebung einen Schritt (2103) des automatischen Registrierens des ausführbaren Moduls alleine durch Programmverarbeitung aufweist.
DE4104568A 1990-02-15 1991-02-14 Verfahren und vorrichtung zur programmverarbeitung Ceased DE4104568A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP3471290A JPH03238571A (ja) 1990-02-15 1990-02-15 データフロー型プログラム生成方法
JP6942490A JPH03269623A (ja) 1990-03-19 1990-03-19 入出力仕様プログラム作成方法

Publications (1)

Publication Number Publication Date
DE4104568A1 true DE4104568A1 (de) 1991-08-29

Family

ID=26373548

Family Applications (1)

Application Number Title Priority Date Filing Date
DE4104568A Ceased DE4104568A1 (de) 1990-02-15 1991-02-14 Verfahren und vorrichtung zur programmverarbeitung

Country Status (2)

Country Link
US (1) US5511167A (de)
DE (1) DE4104568A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0877982A1 (de) * 1996-01-17 1998-11-18 Nathen P. Edwards Verarbeitungssystem

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3552258B2 (ja) * 1993-12-27 2004-08-11 株式会社日立製作所 分散計算機システム及びその情報管理方法
DE19520030C1 (de) * 1995-05-31 1996-05-15 Siemens Ag Verfahren zur Aktualisierung der Programmstruktur einer modularen Kommunikationsanlage
US5805829A (en) * 1996-10-01 1998-09-08 International Business Machines Corp Process for running applets over non-IP networks
US5946489A (en) * 1997-12-12 1999-08-31 Sun Microsystems, Inc. Apparatus and method for cross-compiling source code
US6745384B1 (en) * 1998-05-29 2004-06-01 Microsoft Corporation Anticipatory optimization with composite folding
US6973560B1 (en) 1999-07-16 2005-12-06 Lamarck, Inc. Fault tolerant and combinatorial software environment system, method and medium
US6634019B1 (en) 1999-07-16 2003-10-14 Lamarck, Inc. Toggling software characteristics in a fault tolerant and combinatorial software environment system, method and medium
WO2001006358A1 (en) * 1999-07-16 2001-01-25 Lamarck, Inc. Fault tolerant and combinatorial software environment system, method and medium
JP2002073348A (ja) * 2000-08-31 2002-03-12 Mitsubishi Electric Corp シナリオ解析型制御システム装置
US20030061349A1 (en) * 2001-09-24 2003-03-27 George Lo Method and system for collaboratively developing programming code for programmable controllers
JP2003150602A (ja) * 2001-11-15 2003-05-23 Hitachi Ltd 文書情報管理方法および装置
US7426570B2 (en) * 2003-07-25 2008-09-16 Hewlett-Packard Development Company, L.P. Determining placement of distributed application onto distributed resource infrastructure
US20050137836A1 (en) * 2003-12-23 2005-06-23 Clark Noel E. Computer system architecture transformation
KR101092438B1 (ko) * 2004-08-05 2011-12-13 엘지전자 주식회사 케이블 방송 수신기 및 그의 진단 방법

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS57146361A (en) * 1981-03-06 1982-09-09 Hitachi Ltd Decentralized processing method
US4901274A (en) * 1984-07-11 1990-02-13 Hitachi, Ltd. Method and system for data driven information processing
JPH0632056B2 (ja) * 1985-05-31 1994-04-27 松下電器産業株式会社 デ−タ処理装置
JPS63106044A (ja) * 1986-10-22 1988-05-11 Nec Corp フロ−指向プログラム開発方式
US5127104A (en) * 1986-12-29 1992-06-30 Dataflow Computer Corporation Method and product involving translation and execution of programs by automatic partitioning and data structure allocation
US4965724A (en) * 1987-03-05 1990-10-23 Oki Electric Industry Co., Ltd. Compiler system using reordering of microoperations to eliminate interlocked instructions for pipelined processing of assembler source program
JP2580592B2 (ja) * 1987-04-17 1997-02-12 株式会社日立製作所 データ構造駆動型処理装置とその制御方法
US5117489A (en) * 1987-04-22 1992-05-26 Mitsubishi Denki Kabushiki Kaisha Data-driven processor having an internal tag-generating system for generating a distinct tagged information and assembling with un-tagged information of an input/output data packet
US5185873A (en) * 1988-02-19 1993-02-09 Hitachi, Ltd. Control system with flag indicating two or less data inputs and counter indicating two or more controlling data driven execution method
US5241635A (en) * 1988-11-18 1993-08-31 Massachusetts Institute Of Technology Tagged token data processing system with operand matching in activation frames
US5197137A (en) * 1989-07-28 1993-03-23 International Business Machines Corporation Computer architecture for the concurrent execution of sequential programs
US5175843A (en) * 1989-10-30 1992-12-29 General Electric Company Computer-aided design method for restructuring computational networks to minimize shimming delays
US5099418A (en) * 1990-06-14 1992-03-24 Hughes Aircraft Company Distributed data driven process

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DE-Firmenschrift der IBM Deutschland GmbH, "Neue Methoden und Techniken der Programmierung", Teil 7, S. 11-19, 1976 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0877982A1 (de) * 1996-01-17 1998-11-18 Nathen P. Edwards Verarbeitungssystem
EP0877982A4 (de) * 1996-01-17 1999-09-01 Nathen P Edwards Verarbeitungssystem

Also Published As

Publication number Publication date
US5511167A (en) 1996-04-23

Similar Documents

Publication Publication Date Title
EP0346801B1 (de) Verfahren und Anordnung zur Ausführung eines Programms in einem heterogenen Mehrrechnersystem
DE4235193C2 (de) Netzwerksystem und zugehöriges Softwareverwaltungsverfahren
DE3416939C2 (de)
DE3587034T2 (de) Verfahren und einrichtung zur steuerung automatischer geraete.
EP1034475B1 (de) Verfahren zum testen von systemkomponenten eines objektorientierten programms
DE4104568A1 (de) Verfahren und vorrichtung zur programmverarbeitung
DE3503119A1 (de) Verfahren zum automatischen erzeugen eines quellenprogramms
DE4011278A1 (de) Programmierbare steuereinheit
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
EP1699005A1 (de) Integration von MES- und Controls-Engineering
EP1638028A2 (de) Rechnergestützte Erzeugung und Änderungsmanagement für Bedienoberflächen
DE19960048A1 (de) Zeitgesteuerte Startbedingungen für Aktivitäten in Workflow-Management-Systemen
EP1005215B1 (de) Verfahren und Vorrichtung zum Editieren von Konfigurationsdaten für Telekommunikationssysteme
EP0838054B1 (de) Verfahren und steuereinrichtung für eine graphische steuerung von abläufen in einem netzwerkmanagementsystem
DE10041072A1 (de) Verfahren zur automatischen Erzeugung von Programmcode
DE3937532C2 (de) Mehrprozessoranlage
EP0503256A1 (de) Programmierbare Steuer- und Regeleinrichtung
EP1079306B1 (de) Verfahren zum Testen eines Programmsystems sowie zugehörige Datenverarbeitungsanlage und zugehöriges Programm
DE19637883B4 (de) Datenverarbeitungsanlage zur Ausführung großer Programmsysteme
EP2093663A1 (de) Engineering-System für die Entwicklung eines Projektes und Verfahren
WO2021245247A1 (de) Verfahren zum erstellen und ausführen eines steuerprogramms zum steuern eines automatisierungssystems und automatisierungssystem
DE19828611C2 (de) Datenverarbeitungsvorrichtung und zugehöriges Verfahren
EP1621945B1 (de) Konsistenzsicherung in einem Automatisierungssystem
DE102019005150A1 (de) Numerische Steuervorrichtung

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8131 Rejection