DE3842289C2 - Verfahren zur Entwicklung von Programmen für ein verteiltes Datenverarbeitungssystem - Google Patents

Description

Die Erfindung bezieht sich auf ein Verfahren gemäß dem Oberbegriff des Patentanspruchs 1 zur Entwicklung von Pro­ grammen für ein verteiltes Datenverarbeitungssystem zur an­ teilsweisen Ausführung einer Serie von Prozessen durch eine Mehrzahl von Prozessoren, wobei ein Entwicklungsprozessor zur Programmentwicklung Anwendungsprogramme entwickelt, die durch die jeweiligen Prozessoren ausgeführt werden, und wo­ bei die entwickelten Anwendungsprogramme in die jeweiligen Prozessoren geladen werden.

Die Entwicklung von Programmen in einem verteilten Verar­ beitungssystem ist in der US-P 4,627,055 beschrieben. Die JP-A-57-146361 offenbart bereits ein verteiltes Verarbei­ tungsverfahren zur unterteilten Bearbeitung einer Serie von Aufgaben durch Prozessoren, die mit einer gemeinsamen Über­ tragungsleitung verbunden sind. Bei diesem Verfahren sind Programme zur jeweiligen Ausführung eines zu einer Serie von Prozessen gehörenden Prozesses verteilt in den jeweili­ gen Prozessoren gespeichert. Die Programme in den jeweili­ gen Prozessoren werden gestartet, wenn zur Ausführung der Programme notwendige Daten, die über die Übertragungslei­ tung erhalten worden sind, in dem jeweiligen Prozessor ge­ laden worden sind. Dieses Verfahren ermöglicht eine aufge­ teilte Bearbeitung einer Serie von Prozessen durch jeweili­ ge Prozessoren, ohne daß ein Steuerprozessor zur Steuerung des Gesamtsystems erforderlich ist.

Die JP-A-61-286 959 offenbart ein Verfahren zur Übertragung von durch jeweiligen Prozessoren auszuführenden Programmen in Form einer Nachricht über eine Übertragungsleitung, so daß jeder Prozessor die über die Übertragungsleitung über­ tragenen Programme aufnehmen und in seinem Inneren spei­ chern kann.

In der Vergangenheit wurden Programme kollektiv entwickelt. Soll daher ein Programm geändert und angepaßt werden, um eine neue Version des Programms zu entwickeln, so lassen sich die neue und die alte Version der entwickelten Pro­ gramme durch bloßes Hinzufügen einer Seriennummer (Erzeu­ gungs- bzw. Generationsnummer) identifizieren, die angibt, wie oft das Originalprogramm aktualisiert bzw. auf den neuesten Stand gebracht worden ist. Aufgrund dieser Nummer kann bestimmt werden, ob das entwickelte Programm weiter aktualisiert werden soll (Modifikation oder Ergänzung), oder ob das entwickelte Programm in einem ausführenden Com­ puter verwendet werden soll.

Dieses Verfahren berücksichtigt jedoch nicht den Fall, bei dem Programme in separaten Entwicklungssystemen modifiziert oder ergänzt werden, und zwar auf der Grundlage eines Pro­ gramms in einem verteilten Verarbeitungssystem mit einer Mehrzahl von Entwicklungssystemen.

Bei einem herkömmlichen verteilten bzw. verzweigten Verar­ beitungssystem ist es möglich, jeweilige Programme indivi­ duell zu entwickeln, da Verbindungen bzw. Schnittstellen (Interfaces) zwischen den Programmen nur durch die Ein­ gangs-/Ausgangsdaten der Programme definiert sind. Es be­ steht bei diesem herkömmlichen Verfahren jedoch keine Mög­ lichkeit zu prüfen, ob eine Konsistenz bzw. Verträglichkeit zwischen den individuell entwickelten Programmen oder zwi­ schen den Programmen und definierter Information für die Programme vorhanden ist. Dies führt zu gewissen Problemen bei der Programmentwicklung.

Beim herkömmlichen Verfahren ist es erforderlich, beim La­ den der jeweiligen Prozessoren mit den entwickelten Pro­ grammen die Eingangs-/Ausgangsnachrichten der Programme zu definieren, um die Eingangs-/Ausgangsdaten der Programme identifizieren zu können. Wird eine falsche Information de­ finiert, so würde das Programm den Prozeß aufgrund einer von der gewünschten Nachricht völlig verschiedenen Nach­ richt ausführen.

Aus DE 37 11 273 A1 ist ein Verfahren zur Entwicklung von Programmen für ein verteiltes Datenverarbeitungssystem be­ kannt, in dem mehrere Prozessoren über eine gemeinsame Über­ tragungsleitung untereinander verbunden sind. Den über die Leitung übertragenen Nachrichten (Daten, Programmen usw.) wird dabei ein Funktionscode und eine Ereignisnummer hinzuge­ fügt, die aus der Nummer des Prozessors und des Verarbei­ tungsschrittes, durch den die Nachricht erzeugt wurde, be­ steht. Beim Ablauf der Programme wird anhand des Funktions­ codes und der Ereignisnummer ein Protokoll der über die Lei­ tung übertragenen Nachrichten erstellt. Das bekannte Verfah­ ren dient zur Fehlersuche in Programmpaketen, deren Entwick­ lungsarbeit nahezu abgeschlossen ist. In vielen Fällen, ins­ besondere zu Beginn der Programmentwicklung, ist aber ein protokollierbarer Testlauf des Programms noch nicht durch­ führbar oder wegen der dafür erforderlichen Rechenzeit un­ wirtschaftlich.

Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren zur Entwicklung von Programmen für ein verteiltes Datenverarbei­ tungssystem anzugeben, das es gestattet, die Verträglichkeit zwischen Programmen zu prüfen, um eine "kooperative" Pro­ grammentwicklung zu ermöglichen.

Die erfindungsgemäße Lösung dieser Aufgabe ergibt sich aus dem Anspruch 1; vorteilhafte Weiterbildungen sind in den Un­ teransprüchen angegeben.

Die Erfindung wird nachfolgend unter Bezugnahme auf die Zeichnung näher beschrieben. Es zeigen:

Fig. 1 ein Beispiel eines in einen Entwicklungsprozessor zu ladenden Programms zwecks Durchführung eines Programmentwicklungsverfahrens nach der Erfindung,

Fig. 2 ein System, in das nach der Erfindung entwickelte Programme geladen werden können,

Fig. 3 ein Beispiel eines Formats eines Quellenprogramms, das Gegenstand des Programmentwicklungsverfahrens nach der Erfindung ist,

Fig. 4 bis 7 das Verfahren nach der Erfindung im einzelnen,

Fig. 8 ein Blockdiagramm eines verteilten Prozessorsy­ stems zur Durchführung des erfindungsgemäßen Ver­ fahrens,

Fig. 9 ein Beispiel eines Nachrichtenformats von Informa­ tion, die über ein Übertragungsmedium übertragen und empfangen wird,

Fig. 10 bis 12 Beispiele von Änderungen des Programms nach der Erfindung, und

Fig. 13 ein Flußdiagramm eines Prozesses in einem Prozes­ sor in Übereinstimmung mit dem erfindungsgemäßen Verfahren.

Die Fig. 2a bis 2c zeigen ein System zur Durchführung des Verfahrens nach der Erfindung. Die Gesamtansicht dieses Sy­ stems ist in Fig. 2a dargestellt. Die Ziffern 11 bis 14 be­ zeichnen Prozessoren, die in ihnen gespeicherte Anwendungs­ programme ausführen. Mit der Ziffer 15 ist ein Prozessor zur Entwicklung der Programme bezeichnet, die durch die Prozessoren 11 bis 14 ausgeführt werden. Mit diesem Prozes­ sor 15 sind eine Speicherplatte 1502 und ein Kathoden­ strahlröhren-Terminal 1501 verbunden. Jene Einheiten werden nachfolgend als Entwicklungssystem bezeichnet. Die entwic­ kelten Programme werden durch ein Ausführungssystem ausge­ führt. Die Prozessoren 11 bis 15 sind mit einem Netzwerk 1 verbunden, das in beliebiger Weise ausgebildet sein kann. Die erhaltenen Verarbeitungsergebnisse (data) der Prozesso­ ren 11 bis 14 werden zum Netzwerk 1 übertragen bzw. gesen­ det. Aus den über das Netzwerk 1 gesendeten Nachrichten nimmt jeder Prozessor Nachrichten (einschließlich Programme und Daten) auf, die zur Ausführung der in ihm gespeicherten Programme erforderlich sind und startet das Programm, wenn er alle Nachrichten, die zur Durchführung erforderlich sind, erhalten hat. Das gestartete Programm führt seinen eigenen Prozeß aus und liefert ein Ergebnis.

Die Fig. 2b zeigt das Format der Nachricht, die über das Netzwerk 1 gesendet wird. Jeder Prozessor bestimmt, ob die über das Netzwerk empfangene Nachricht für sein eigenes Programm erforderlich ist, und zwar anhand eine Inhalts­ codes (CC) 202 (content code), der den Dateninhalt bezeich­ net. Eine Quellenadresse (SA) 203 ist eine Adresse desjeni­ gen Prozessors, der eine Nachricht ausgegeben hat, während C 204 eine Seriennummer ist, die die Sequenz der Übertra­ gung angibt. Data 205 gibt den Inhalt des durch das Pro­ gramm erhaltenen Ergebnisses an, während FCS 206 Fehler­ prüfdaten für die Übertragungsdaten sind. F 201 und F 207 sind Steuerkennzeichen (flgas), die den Anfang und das Ende der Nachricht angeben.

Die Fig. 2c zeigt eine Tabelle, die ein jeder Prozessor zur Bestimmung des Starts seines eigenen Programms aufweist. Die Zeilen 1051, 1052, . . . in der Tabelle nach Fig. 2c stimmen mit entsprechenden Programmen überein. In der er­ sten Zeile ist Prog 10512 ein Bereich zur Speicherung von Information des zu startenden Programms, während IData 10511 ein Bereich ist, in dem eine vom Netzwerk erhaltene Nachricht gespeichert ist, die zur Ausführung des Programms Prog 10512 notwendig ist. Die zweite Zeile 1052 ist so auf­ gebaut, daß das Programm nur dann ausgeführt wird, wenn zwei Nachrichten IData-1 10521 und IData-2 10522 gespei­ chert worden sind. Die dritte und die nachfolgenden Zeilen sind von ähnlicher Struktur. Der Inhaltscode der Nachricht, die zur Programmausführung nötig ist, wurde bereits zuvor in IData 10511 der Tabelle für jedes Programm gespeichert. Jeder Prozessor vergleicht den Inhaltscode CC 202 der vom Netzwerk erhaltenen Nachricht mit dem Inhaltscode der in ihm gespeicherten Tabelle und speichert die Nachricht im Übereinstimmungsfall im Bereich IData 10511. Wurden alle erforderlichen Nachrichten im Bereich IData 10511 gespei­ chert, so benutzt der Prozessor die Daten der Nachrichten zur Ausführung des Programms im Bereich Prog 10512. Wurden alle erforderlichen Nachrichten in den Bereichen IData-1 und I-Data-2 gespeichert, so wird das Programm im Bereich Prog 10523 ausgeführt.

Das Programmentwicklungssystem für das durch das obige System auszuführende Programm wird nachfolgend unter Bezug­ nahme auf die Fig. 1, 3, 4a, 4b, 5a, 5b, 6a, 6b, 6c, 7a und 7b im einzelnen erläutert.

Die Fig. 1 zeigt ein Programm zur Behandlung einer Nach­ richt im Entwicklungsprozessor 15. Im Prozessor 15 sind Programme 15001, 15002 und 15003 geladen. Diese Programme werden in Antwort auf Eingaben vom Anzeigeterminal 1501 (Kathodenstrahlröhren-Terminal) gestartet. Das Programm 15001 ist ein Attributerzeugungsprogramm, das Lademodul- Files 3501 bis 350n und ein Attribut-File 3500 für ein be­ stimmtes von mehreren Quellenprogramm-Files 3011, 3012, . . . , 301n erzeugt. Das Programm 15002 ist ein Rundfunkpro­ gramm, das eine Ladenachricht durch Kombination von Lademo­ dul-File und Attribut-File erzeugt und über das Netzwerk 1 sendet. Dagegen ist das Programm 15003 ein Konsistenzprüfprogramm, das Programme korreliert, und zwar auf der Grund­ lage des Attribut-Files 3500. Die Prozeßinhalte der jewei­ ligen Programme werden nachfolgend im einzelnen erläutert. Zunächst wird das Verfahren gemäß Programm 15001 unter Be­ zugnahme auf die Fig. 3 und 4 genauer beschrieben. Die Fig. 3 zeigt Inhalte der Quellenprogramme 3011 bis 301n in Fig. 1. Diese Quellenprogramme wurden zuvor eingegeben, und zwar durch einen Programmentwickler vom CRT-Terminal 1501. Das Quellenprogramm als Gegenstand des vorliegenden Verfahrens besteht aus einem Attributteil 401 und einem Prozedurteil 402. Der Attributteil 401 enthält ein Programmnamen-Defini­ tionsfeld 4011, ein Eingabenachricht-Inhaltscode-Defini­ tionsfeld 4012, ein Ausgabenachricht-Inhaltscode-Defini­ tionsfeld 4013 sowie eine Information zum Testen des Pro­ gramms 4014 (z. B. Testeingang und das daraus erhaltene Er­ gebnis). Der Prozedurteil 402 enthält ein codiertes Pro­ gramm.

Die Fig. 4a zeigt den Verfahrensablauf gemäß dem Programm 15001. Das Compile-Programm 15001 beginnt seinen Betrieb, wenn ein Sourceprogramm-File, das in ein Lademodul umgewan­ delt werden soll, über die Eingabeeinheit 1501 (Terminal) bestimmt worden ist. Das Attributerzeugungsprogramm 15001 unterteilt das bestimmte Sourceprogramm in einen Attribut­ teil und in einen Prozedurteil (Schritt 551). Das Format des separierten Attributteils wird geprüft (Schritt 552). Beim Prüfen des Formats wird festgestellt, ob der Inhalt des Attributteils gleich dem in 401 von Fig. 3 ist. Ist das Ergebnis der Formatprüfung in Ordnung, so wird nachfolgend Schritt 554 erreicht. Ist dagegen das Ergebnis der Format­ prüfung nicht in Ordnung, so wird eine Fehlernachricht (Schritt 557) erzeugt, wonach das Verfahren endet. Der ent­ sprechende Vergleich erfolgt in Schritt 553. Im Schritt 554 wird der im Schritt 551 abgetrennte Prozedurteil kompi­ liert, um ein Lademodul-File zu erzeugen.

Wird das Kompilieren normal beendet, so wird nachfolgend Schritt 556 erreicht. Erfolgt dagegen eine nicht normale Beendigung des Kompilierens, so wird im Schritt 557 eine Fehlernachricht erzeugt, wonach das Verfahren endet. Im Schritt 556 werden die rechten Seiten der Ausdrücke der At­ tributteile 401, die die Formatprüfung durchlaufen haben, gesammelt, um ein Attribut-File (3500 in Fig. 1) zu erstel­ len (Schritt 556). Strukturen des so erhaltenen Attribut- Files und des so erhaltenen Lademodul-Files sind in Fig. 4b dargestellt. Das Attribut-File 3500 enthält Attributtabel­ len 35001, 35002, . . ., deren jede einem Lademodul- File 3501, 3502, . . . zugeordnet ist, die in Schritt 554 er­ zeugt worden sind. Die Tabelle 35001 enthält einen Bereich PN 350011, der einen im Quellenprogramm-Attributteil 401 in Fig. 3 definierten Programmnamen 4011 aufweist, einen Be­ reich ICC 350012, der einen im Attributteil 401 definierten Eingangsnachricht-Inhaltscode 4012 aufweist, einen Bereich OCC 350013, der einen Ausgangsnachricht-Inhaltscode 4013 aufweist und eine File-Hinweisadresse (file pointer) FP 350014 zur Markierung eines Lademodul-Files, das durch ein Quellenprogramm mit Beiträgen der Bereiche PN, ICC und OCC hergestellt worden ist. Die Tabellen 35002, 35003, . . ., 3500n weisen dieselbe Struktur auf. Auf die Lademodul-Files 3501, 3502, . . ., 350n wird über die Attributtabellen 35001, 35002, . . ., 3500n immer zugegriffen. Insbesondere erfolgt ein Zugriff auf die Lademodul-Files durch die Programmna­ men. Soll daher ein Lademodul-File gelöscht werden, so sollte die entsprechende Attributtabelle ebenfalls gelöscht werden. Existiert bereits eine Attributtabelle mit demsel­ ben Programmnamen PN, so sollten in Schritt 556 von Fig. 4a die existierende Attributtabelle und das entsprechende La­ demodul-File gelöscht und eine Attributtabelle hergestellt werden.

Im folgenden wird unter Bezugnahme auf die Fig. 5 das Lade­ programm 15002 nach Fig. 1 zur Erzeugung einer in einen Prozessor zu ladenden Nachricht erläutert. Dieses Programm wird ausgeführt, wenn der Programmname des Programms be­ stimmt worden ist, das von der CRT-Eingabeeinheit (1501 in Fig. 2) über das Netzwerk 1 geladen werden soll. Eine At­ tributtabelle mit einem PN-Feld (Fig. 4b) identisch zum be­ nannten Programmnamen wird aus dem Attribut-File herausge­ sucht (Schritt 581). Dann werden die aufgefundene Attribut­ tabelle und der entsprechende Lademodul miteinander kombi­ niert, um eine zu ladende Nachricht zu erstellen (Schritt 582). Der Inhalt des Datenfeldes (205 in Fig. 2b) der zu ladenden Nachricht, die in Schritt 582 erstellt worden ist, ist in Fig. 5b gezeigt. PN 591 speichert den Programmnamen PN der Attributtabelle, während ICC 592 und OCC 593 jeweils den Eingangs-Inhaltscode ICC und den Ausgangs-Inhaltscode OCC der Attributtabelle speichern.

LM 594 speichert den Inhalt des Lademodul-Files. Das CC- Feld (202 in Fig. 2b) der zu ladenden Nachricht speichert den Inhaltscode in Übereinstimmung mit dem Programm, wenn die Erstellung der Nachrichten gemäß den Fig. 5b und 2b vollständig beendet ist. Das Rundfunkprogramm 15002 (broad­ cast program) sendet die Nachrichten über das Netzwerk aus (Schritt 583). Die durch das Verfahren nach Fig. 5 herge­ stellte und über das Netzwerk gesendete Nachricht wird durch die mit dem Netzwerk verbundenen Prozessoren empfan­ gen. Auf der Grundlage des CC-Feldes in der Nachricht be­ stimmt der Prozessor, ob das Programm in der Nachricht für ihn selbst bestimmt bzw. erforderlich ist. Ist das Programm in der Nachricht für diesen Prozessor erforderlich, so nimmt der Prozessor die empfangene Nachricht auf. Nach der Aufnahme der Nachricht durch den Prozessor speichert er den Inhalt von LM des Datenfeldes der Nachricht in seinen Spei­ cherbereich und übernimmt ferner das in die Programmspei­ chertabelle nach Fig. 2c geladene Programm auf der Grundla­ ge der Inhalte von PN, ICC und OCC des Datenfeldes der Nachricht (vgl. Fig. 5b). Anschließend wird das geladene Programm zu Testzwecken gestartet, und zwar unter Verwen­ dung von Testinformation in der Attributinformation, also unter Verwendung von Testeingangsdaten, um bestimmen zu können, ob die durch das Programm erstellten Ausgangsdaten eine vorbestimmte Beziehung zu den Eingangsdaten aufweisen. Ist das Testergebnis in Ordnung, wird das Programm On-Line ausgeführt bzw. wiedergegeben. Beim oben beschriebenen Pro­ zeß sei angenommen, daß der Inhaltscode, der das für den Prozessor erforderliche Programm angibt, in diesem Prozes­ sor gespeichert worden ist.

Unter Bezugnahme auf die Fig. 6 und 7 wird nachfolgend das Konsistenz-Prüfprogramm 15003 (Fig. 1) näher beschrieben, das die Programme auf der Grundlage des Inhalts des Attri­ but-Files korreliert. Dieses Programm kann auch als Ver­ träglichkeitsprogramm oder als Programm zur Überprüfung der Übereinstimmung bezeichnet werden. Die Fig. 6a zeigt eine Tabelle mit einer Beziehung zwischen Eingangs-/Ausgangspro­ grammen, hergestellt durch das Programm 15003. Das Ein­ gangs/Ausgangs-Beziehungsprogramm enthält Zeilen 601, 602, . . . entsprechend den jeweiligen Inhaltscodes. Die erste Zeile 601 enthält einen Bereich CC 6011 zur Speicherung des Inhaltscodes, einen Bereich IPROG 6012 zur Speicherung des Namens des Programms, das die Nachricht mit dem Inhaltscode im Bereich CC 6011 eingibt bzw. liefert, und einen Bereich OPROG 6013 zur Speicherung des Namens des Programms, das die Nachricht mit dem Inhaltscode im Bereich CC 6011 aus­ gibt. Die zweite Zeile und die nachfolgenden Zeilen weisen dieselbe Struktur auf.

Die Fig. 6b zeigt einen Programmablauf zur Erstellung der Eingangs/Ausgangsbeziehungstabelle in Fig. 6a. Zunächst wird ein Zähler auf den Zählwert i gesetzt (Schritt 651). Auf der Grundlage des Inhalts der i-ten Attributtabelle (Fig. 4b) wird die Eingangs/Ausgangs-Beziehungstabelle in Übereinstimmung mit dem in Fig. 6c gezeigten Flußdiagramm erstellt (Schritt 652). Eine Zeile innerhalb des CC-Feldes, die den gleichen Inhaltscode wie den im ICC-Feld der Attri­ buttabelle eingestellten Inhaltscode aufweist, wird aus der Eingangs/Ausgangs-Beziehungstabelle (Schritt 681) herausge­ sucht. Existiert die entsprechende Zeile, so wird der In­ halt des PN-Feldes der Attributtabelle im Bereich IPROG 6012 der Zeile gesetzt (Schritt 682). Existiert die ent­ sprechende Zeile nicht, so wird eine neue Zeile zur Ein­ gangs/Ausgangs-Beziehungstabelle hinzugefügt bzw. hinzuad­ diert, wobei die Inhalte des ICC-Feldes und des PN-Feldes der Attributtabelle im CC-Feld und im IPROG-Feld dieser Zeile jeweils gesetzt werden (Schritt 683). Anschließend wird eine Zeile, die einen Inhaltscode gleich dem Inhalts­ code innerhalb des OCC-Feldes der Attributtabelle aufweist, aus der Eingangs/Ausgangs-Beziehungstabelle herausgesucht (Schritt 684). Existiert die entsprechende Zeile, so wird der Inhalt des PN-Feldes der Attributtabelle im Ausgangs­ programmbereich (OPROG) dieser Zeile gesetzt (Schritt 685). Existiert die entsprechende Zeile nicht, so wird der Pro­ grammname in Fig. 4 in eine neue Zeile der Eingangs/Aus­ gangs-Beziehungstabelle eingeschrieben, wobei die Inhalte des OCC-Feldes und des PN-Feldes der Attributtabelle im CC- Feld und im OPROG-Feld dieser Reihe jeweils gesetzt werden (Schritt 686). Nach Ablauf des Prozesses gemäß Fig. 6c wird geprüft, ob alle Attributtabellen im Attribut-File auf die­ se Weise verarbeitet worden sind oder nicht (Schritt 653). Ist dies nicht der Fall, so wird die Zählervariable i um den Wert 1 heraufgesetzt (Schritt 654), wonach das Verfah­ ren zum Schritt 652 zurückspringt.

Auf der Grundlage der so erstellten Eingangs/Ausgangs-Be­ ziehungstabelle lassen sich ein Programm, das durch eine Nachricht mit irgendeinem Inhaltscode gestartet wird, und ein Programm, das die Nachricht mit diesem Inhaltscode aus­ gibt, erfassen bzw. ausführen. Durch Aufsuchen einer Zeile, in der der IPROG-Bereich oder der OPROG-Bereich der Tabelle nicht gesetzt worden sind, lassen sich das Programm, wel­ ches kein Programm zur Ausgabe der Eingangsnachricht ent­ hält, und das Programm, welches kein Programm zur Aufnahme der Ausgangsnachricht enthält, detektieren. Dies ist ein Beispiel einer Fehlerdetektion in der Programmbeziehung. Durch diese Eingangs/Ausgangs-Beziehungstabelle kann eine Serie von Programmen detektiert werden, die für irgendeine Nachricht gestartet worden sind. Unter Bezugnahme auf die Fig. 7a und 7b wird ein hierfür geeigneter Prozessor genau­ er beschrieben. Der Prozeß beginnt mit der Benennung eines Inhaltscodes einer Nachricht, die als sogenannter Trigger arbeitet. Ein interner Zähler l wird auf den Wert "0" ge­ setzt (Schritt 700). Ein Programm, das die Nachricht mit dem Inhaltscode empfängt, der durch einen Benutzer über die Eingabeeinheit 1501 eingegeben worden ist, wird aus der Eingangs/Ausgangs-Beziehungstabelle herausgesucht und als Pegel l Programm bezeichnet (Schritt 701). Für jedes aufge­ suchte Pegel l Programm wird dasjenige Programm, das dessen Ausgangsnachricht empfängt, aufgesucht und als Pegel (l+1) Programm definiert (Schritt 702). Dies wird dadurch er­ reicht, daß der Inhaltscode der Ausgangsnachricht von der Attributtabelle für das Programm detektiert und das Pro­ gramm aufgesucht wird, welches die Nachricht mit dem Code von der Eingangs/Ausgangs-Beziehungstabelle empfängt. Es wird geprüft, ob unter den bisher aufgesuchten Programmen (Pegel 0 bis l Programme) ein Programm existiert, das gleich dem in Schritt 702 aufgefundenen Pegel (l+1) Pro­ gramm ist. Existiert ein solches Programm, so wird das Pe­ gel (l+1) Programm keiner Schleifenprüfung unterworfen (Schritt 703). Dies ist ein Prozeß zum Detektieren einer abnormalen Struktur, wie in Fig. 7b gezeigt, in der die Ziffern 761 und 762 Programme, die Ziffer 751 eine Nach­ richt mit einem Inhaltscode CC1 und die Ziffer 752 eine Nachricht mit einem Inhaltscode CC2 bezeichnen. In dieser Struktur erfolgt der Prozeßablauf für den Start des Pro­ gramms 761 durch die Ausgangsnachricht des Programms 762 innerhalb einer Schleife, so daß die Möglichkeit besteht, daß eine abnormale Beziehung zwischen den Programmen vor­ handen ist. Schritt 703 stellt demzufolge auch ein Bespiel für das Detektieren einer abnormalen Beziehung zwischen den Programmen dar. In einem Schritt 704 wird geprüft, ob das Pegel (l+1)-Programm existiert oder nicht. Existiert es nicht, so endet der Prozeß. Existiert es dagegen, so wird die interne variable l um den Wert 1 heraufgesetzt, wonach der Prozeß zurück zum Schritt 702 springt. Im Schritt 704 wird das Programm, das keiner Schleifenprüfung unterzogen worden ist, so behandelt, als wenn kein Pegel (l+1)-Pro­ gramm vorhanden wäre.

Durch einfaches Definieren der Information bezüglich der Eingangs/Ausgangsnachricht in einem Quellenprogramm ist es auf diese Weise möglich, die Information zum Laden des Programms in den ausführenden Prozessor automatisch zu er­ zeugen. Es ist ebenfalls möglich, die Beziehung zwischen Programmen zu erfassen und eine abnormale Beziehung zwi­ schen den Programmen zu detektieren.

Beim vorliegenden Ausführungsbeispiel wird die Attributta­ belle des Programms zusammen mit dessen Lademodul erzeugt. Alternativ kann auch nur die Attributtabelle ohne Erzeugung des Lademoduls gebildet werden. Die Beziehung zwischen Pro­ grammen läßt sich auch dann überprüfen, wenn nur das Attri­ butfeld im Quellenprogramm definiert ist. Beim vorliegenden Ausführungsbeispiel ist die Attributtabelle in anderen Files als der Lademodul gespeichert. Alternativ dazu können der Lademodul und die entsprechende Attributtabelle aber auch in einem File gespeichert sein und als Einheit behan­ delt werden.

Bei der vorliegenden Erfindung testet der mit einem Pro­ gramm geladene Prozessor das Programm auf der Grundlage der Testinformation in der Programmattributinformation. Im Ent­ wicklungsprozessor ist ein automatischer Test des entwic­ kelten Programms auf der Grundlage der Programmattributin­ formation möglich.

Die Fig. 8 zeigt ein Blockdiagramm eines verteilten Verar­ beitungssystems zur Durchführung des erfindungsgemäßen Ver­ fahrens. Beim verteilten Verarbeitungssystem nach Fig. 8 stehen n Prozessoren 111, 112, . . . 11n in Verbindung mit­ einander, und zwar über ein gemeinsames Übertragungsmedium 3, wobei die Verbindung zwischen den Prozessoren mit Hilfe von Übertragungssteuereinheiten 121, 122, . . . 12n zustande kommt, die einerseits mit den Prozessoren und andererseits mit dem gemeinsamen Übertragungsmedium verbunden sind. Je­ der Prozessor kann Programme ändern und erzeugen.

Die Fig. 9 zeigt ein Übertragungsformat für Information, die über das gemeinsame Übertragungsmedium 3 übertragen wird. Im verteilten Prozessorsystem wird die über das Über­ tragungsmedium übertragene Information durch die Übertra­ gungssteuereinheiten empfangen, die den Inhaltscode 200 der Information lesen und bestimmen, ob sie für die Prozessoren erforderlich ist. Ist sie für die Prozessoren erforderlich, so wird die Information zu dem mit der Übertragungssteuer­ einheit verbundenen Prozessor übertragen. Wenn die Informa­ tion mit diesem Inhaltscode vollständig von dem im Prozes­ sor gespeicherten Programm empfangen worden ist, so wird sie als Eingangsdateninformation des auszuführenden Pro­ gramms gelesen und verarbeitet. (Es sei angenommen, daß der Eingangscode im Speicher der Übertragungssteuereinheit ge­ speichert worden ist.) Beim vorliegenden Ausführungsbei­ spiel erfolgt eine datenflußweise verteilte Verarbeitung in Übereinstimmung mit dem Inhaltscode. Die Information läßt sich ferner zwischen den Prozessoren mittels eines Übertra­ gungsprotokolls bzw. Kommunikationsprotokolls austauschen, welches die einzelnen Ziele bestimmt, ohne den Inhaltscode zu verwenden.

Ein durch wenigstens einen der Prozessoren des verteilten Verarbeitungssystems erzeugtes und über das gemeinsame Übertragungsmedium übertragenes Programm wird in das Daten­ feld 220 der Fig. 9 eingeschrieben. Die nachfolgende Infor­ mation bezüglich des in das Datenfeld eingeschriebenen Pro­ gramms wird in das Programminformationsfeld 210 einge­ schrieben. Die Programminformation enthält (i) Programmin­ haltsinformation, (ii) Programmerzeugungsinformation und (iii) Programmcharakteristikinformation (Programmeigen­ schaftsinformation).

Die Programminhaltsinformation repräsentiert Funktion und Inhalt des Programms. Beispielsweise beschreibt sie eine Eingangs/Ausgangsbeziehung des Programms. Beim Programm nach dem vorliegenden Ausführungsbeispiel, bei dem eine da­ tenflußweise Verarbeitung unter Verwendung des Inhaltscodes erfolgt, kann die Eingangs/Ausgangsbeziehung den Inhalts­ code der für den Prozeß erforderlichen Information und den Inhaltscode der Information enthalten, die nach Durchfüh­ rung des Prozesses ausgegeben wird.

Die Programmerzeugungsinformation repräsentiert die Modifi­ kationen für ein Programm durch die Mehrzahl der Prozesso­ ren. Im verteilten Verarbeitungssystem nach dem vorliegen­ den Ausführungsbeispiel fließt ein Programm durch die Pro­ zessoren und durch das gemeinsame Übertragungsmedium, wobei jeder Prozessor den Programmen etwas hinzufügt, Löschungen in den Programmen vornimmt oder die Programme ersetzt. Die Programmerzeugungsinformation wird zum Diskriminieren des Quellenprogramms vor der Modifikation durch das Quellenpro­ gramm und danach verwendet. Diese Information kann durch Zusammenfassen aller Modifikationsprozesse beschrieben wer­ den, so daß die Programmentwicklungsstruktur im verteilten Verarbeitungssystem erkannt werden kann. Alternativ kann entsprechend Fig. 10 die Anzahl der Änderungen des Origi­ nalprogramms jedesmal dann gezählt werden, wenn der Prozes­ sor eine Änderung vornimmt. Modifizieren bei diesem Verfah­ ren in Fig. 10 mehrere Prozessoren jeweils individuell ein Programm A₁, so existieren mehrere Programme A₂ im verteil­ ten Verarbeitungssystem (der Index 2 gibt eine Programmer­ zeugungs- und -modifikationsversion an). Dies kann erfol­ gen, wenn die Änderungsarbeiten in den jeweiligen Prozesso­ ren im Entwicklungsprozeß des Programms vorbestimmt worden sind und ein Quellenprogramm durch Sammlung der Programme derselben Version erstellt werden soll. Die Programmerzeu­ gungsinformation kann Information bezüglich der Version oder Anzahl von Änderungen als auch Information bezüglich des Änderungsbereichs enthalten. Die Änderungs- bzw. Modi­ fikationsbereichsinformation kann den Änderungsbereich durch eine Anweisungsmarke des Programms angeben. Es kann aber auch eine Quellenmodulmarke (Quellenmodulpegel) des geänderten Bereichs nur unter Berücksichtigung einer Quel­ lenprogramm-Modulstruktur in einem Quellenprogramm be­ schrieben werden, wie in Fig. 11 gezeigt ist. Dieses Ver­ fahren ist ausreichend, wenn das Programm für jeden Modul­ pegel entwickelt wird. Entsprechend Fig. 12 wird ein Pro­ gramm A₁ durch die Prozessoren modifiziert bzw. verändert (die Übertragungssteuereinheiten sind nicht mit eingezeich­ net). A₁, A₂, A₃, . . . geben die Anzahl der Modifikationen bzw. Änderungen an, während 1-1 und 1-2 die Änderungsberei­ che (Modulpegel) bezeichnen.

Die Programmcharakteristikinformation bezieht sich auf eine Eigenschaft eines Programms bei der Ausführung des Pro­ gramms und enthält die Ausführungszeit, eine Programm­ größe und die Speicherkapazität. Diese Information wird in dem Prozessor hinzugefügt, in dem das Programm modifi­ ziert worden ist, und verwendet, wenn das Programm ausge­ führt wird.

Die oben beschriebene (i) Programminhaltsinformation, die (ii) Programmerzeugungsinformation und die (iii) Programm­ eigenschaftsinformation stimmen mit einer externen Spezifi­ kation des Programms überein. Gemäß der Erfindung wird die externe Spezifikation zum Programm hinzugefügt und eben­ falls über das gemeinsame Übertragungsmedium übertragen, so daß die weitere Programmentwicklung und Programmausführung im Prozessor erfolgen können, und zwar bei einer durch den Prozessor getroffenen Entscheidung, ohne daß irgendeine zentrale Steuerfunktion erforderlich ist.

Das Programminformationsfeld 210 in Fig. 9 enthält die ge­ samte oder einen Teil der Information (i) bis (iii).

Die Fig. 13 zeigt einen Programmablauf im Prozessor in Übereinstimmung mit dem erfindungsgemäßen Verfahren. Jeder Prozessor empfängt gemäß Fig. 13 das Quellenprogramm, das über das gemeinsame Übertragungsmedium übertragen worden ist (Schritt 61) und prüft die Programminhaltsinformation, die Programmerzeugungsinformation und die Eigenschaftsin­ formation innerhalb des Programms, um zu bestimmen, ob das Programm geändert werden muß oder nicht (Schritte 62 und 63).

Soll es geändert werden und ist kein weiteres Programm er­ forderlich (Schritt 64), so erfolgt eine Änderung des Pro­ gramms in Schritt 65, derart, daß neue Programminhaltsin­ formation, Erzeugungsinformation und Eigenschaftsinforma­ tion zum Programm (Schritt 66) hinzuaddiert werden. Sie werden über das gemeinsame Übertragungsmedium übertragen (Schritt 67). Ist ein anderes Programm erforderlich, so wird das Programm gespeichert (Schritt 68).

Claims (5)

1. Verfahren zur Entwicklung von Programmen für ein verteil­ tes Datenverarbeitungssystem, in dem mehrere Prozessoren (11 . . . 15) über eine gemeinsame Übertragungsleitung (1) unterein­ ander verbunden sind,
wobei in einen ersten Prozessor (15) ein von einer Be­ dienperson gerade entwickeltes Quellenprogramm (3011) geladen wird, das einen Prozedurteil (402) und einen Attributteil (401) enthält, wobei der Prozedurteil (402) die von einem weiteren Prozessor (11 . . . 14) auszuführenden Operationen be­ schreibt und der Attributteil (401) zur Ausführung des Pro­ gramms benötigte, auf den Inhalt der Ein- und Ausgangsdaten dieses Programms bezogene Informationen (4012, 4013) sowie einen Programmnamen (4011) definiert,
wobei der erste Prozessor (15) den Prozedurteil (402) von dem Attributteil (401) des Quellenprogramms (3011) separiert, aus dem Prozedurteil (402) ein auf dem weiteren Prozessor (11 . . . 14) ablauffähiges Programm (594) erzeugt, aufgrund des Attributteils (401) Attributinformationen (591 . . . 593) zur Benutzung durch den weiteren Prozessor (11 . . . 14) erzeugt und das Programm (594) zusammen mit den Attributinformationen (591 . . . 593) dem weiteren Prozessor (11 . . . 14) zuführt, und
wobei der weitere Prozessor (11 . . . 14) das empfangene Pro­ gramm (594) anhand der Attributinformationen (591 . . . 593) auf Verträglichkeit mit einem bereits bestehenden Programm prüft.

2. Verfahren nach Anspruch 1, wobei jeder Prozessor (11 . . . 15) das für ihn erforderliche Programm (594) aufgrund der mit­ geführten Attributinformationen (591 . . . 593) von der Übertra­ gungsleitung (1) übernimmt.

3. Verfahren nach Anspruch 1 oder 2, wobei jedem über die Übertragungsleitung (1) gesendeten Programm eine Programm­ erzeugungs-, eine Programminhalts- und eine Programmänderungs­ information hinzugefügt, das Programm in dem jeweiligen Pro­ zessor (11 . . . 15) aufgrund dieser Informationen unter deren gleichzeitiger Aktualisierung geändert und das geänderte Pro­ gramm mit den aktualisierten Informationen an die Übertra­ gungsleitung zurückgegeben wird.

4. Verfahren nach einem der Ansprüche 1 bis 3, wobei auf­ grund der Attributinformationen (591 . . . 593) eine Tabelle (Fig. 6a) zur Darstellung der Beziehung der Programme untereinander erstellt wird.

5. Verfahren nach einem der Ansprüche 1 bis 4, wobei die Attributinformationen (591 . . . 593) eine Information zum Testen der Programme enthält.