Hintergrund der Erfindung
Gebiet der Erfindung
-
Die Erfindung bezieht sich auf Analyse- und
Steuersysteme und insbesondere Analyse- und Steuersysteme,
die aus Verfahren bestehen, welche in Computern ausgeführt
werden.
Beschreibung des Standes der Technik
-
Ein wichtiger Teil des Aufbaus von großen Systemen
ist die Fehlerbeseitigung, d. h. die Feststellung, Analyse
und Korrektur von Fehlern bei der Realisierung des Systems.
Wenn ein System durch Programme verwirklicht wird, die im
Computer ausgeführt werden, gibt es viele Werkzeuge (Tools)
zur Fehlerbeseitigung in den Programmen. Es gibt
Aufdeckungsprogramme, wie CIA, welche den Programmierern
beim Verständnis helfen, wie ein Programm organisiert ist,
und es gibt als Fehlerbeseitiger bezeichnete Programme,
welche es dem Programmierer ermöglichen zu sehen, was
geschieht, wenn ein Programm während der Fehlerbeseitigung
ausgeführt wird. Moderne Fehlerbeseitiger ermöglichen es dem
Programmierer, interaktiv die Ausführung des Programms
während der Fehlerbeseitigung zu steuern. Ein Beispiel
eines solchen Fehlerbeseitigers ist der GDB-
Fehlerbeseitiger, verfügbar von der Free Software
Foundation. Fehlerbeseitiger beginnen auch, graphische
Flächen - Schnittstellen - zu benutzen, um Information, wie
die Rufvergangenheit eines Programms, ferner durch
Parallelprogramme in verteilten Speichern erzeugte
Ereignisse oder eine Ablaufverfolgung einer parallelen
Ausführung eines Programms zu zeigen. Ein Beispiel einer
solchen graphischen Schnittstelle kann in IEEE Computer,
Juni 1993, Seite 88-95, "Visualization and Debugging in a
Heterogeneous Environment" von Adam Beguelin et al.
angetroffen werden.
-
Die gerade beschriebenen Aufdeckungsprogramme und
Fehlerbeseitiger sind für ihre Aufgabe gut angepaßt, jedoch
werden moderne Systeme typischerweise nicht gerade als Sätze
von zusammenarbeitenden Unterprogrammen implementiert,
vielmehr als Sätze von zusammenarbeitenden Verfahren oder
Prozessen. Zu Zwecken der vorliegenden Diskussion kann ein
Verfahren oder Prozeß als die Instanz in einem
Computersystem definiert werden, welche ein Programm für
einen Anwender tatsächlich ausführt. In vielen Systemen
werden zusammenarbeitende Verfahren oder Prozesse auf
unterschiedlichen Computern ausgeführt. Wenn ein System als
Satz von zusammenarbeitenden Prozessen implementiert wird,
bedeutet die Fehlerbeseitigung im System nicht nur das
Verstehen und die Fehlerbeseitigung der von dem Prozeß
ausgeführten, individuellen Programme, sondern auch das
Verständnis und die Fehlerbeseitigung der Zusammenarbeit der
Prozesse. Die letzteren Aufgaben können nicht durch die
Programmaufdeckungswerkzeuge und die gerade beschriebenen
Fehlerbeseitiger ausgeführt werden.
-
Heutige Computersysteme bieten nur magere Quellen für
Fehlerbeseitigungssysteme, die aus zusammenarbeitenden
Prozessen bestehen. Bei Computersystemen unter Verwendung
des UNIX-Betriebssystems (Warenzeichen der UNIX Systems
Laboratories) gibt es beispielsweise ein
Ablaufverfolgungswerkzeug, das eine Liste der Aufrufe
ausgibt, welche von dem Prozeß zu dem Betriebssystem
gerichtet worden ist. Es gibt auch ein sogenanntes Ofiles-
Werkzeug, welches dem Benutzer mitteilt, welche Dateien ein
gegebenes Verfahren geöffnet haben, und eine sogenanntes
Fuser-Werkzeug, welches die Prozesse identifiziert, die in
einer gegebenen Datei benutzt werden. Ein Nachteil gerade
dieser mageren Fehlerbeseitigungswerkzeuge besteht darin,
daß sie nur Informationen über Prozesse liefern können, die
auf einem einzelnen Prozessor ablaufen und deshalb nur
begrenzte Nützlichkeit beim Verständnis und der
Fehlerbeseitigung von Systemen haben, in denen die
zusammenarbeitenden Prozesse auf unterschiedlichen
Prozessoren ablaufen.
-
Es ist eine Zielrichtung der vorliegenden Erfindung,
die obigen Probleme bei Fehlerbeseitigungssystemen zu
überwinden, die aus zusammenarbeitenden Prozessen aufgebaut
sind, indem Techniken zur Verfügung gestellt werden, welche
die enge Analyse und Steuerung oder Regelung solcher Systeme
ermöglichen.
Zusammenfassung der Erfindung
-
Eine Analysevorrichtung gemäß der Erfindung ist in
Anspruch 1 angegeben. Die Technik der Erfindung ist in einem
visuellen Prozeßmanager verkörpert. Der visuelle
Prozeßmanager hat zwei Teile:
-
1. einen Monitor, welcher Nachrichten aussendet, wenn die
Prozesse in dem System Betriebssystemaufrufe für Operationen
ausführen, wie Schaffung eines abhängigen Verfahrens ("Child
Process") oder Zugang zu einer Quelle, beispielsweise einer
Datei, und
-
2. einen Generator für graphische Darstellung, der ein
Display in Abhängigkeit von den Nachrichten erzeugt.
Das Display zeigt den Zustand des Systems der Verfahren und
ändert sich, wie von den Nachrichten verlangt. Der Anwender
kann so vom Display aus bestimmen, was in dem System der
Verfahren vor sich geht. Der Anwender kann ferner eine
Zeigervorrichtung, beispielsweise eine Maus, anwenden, um
das Display zu steuern und selbst das System der Verfahren.
-
In der bevorzugten Ausführungsform stellt das Display
ein ausgerichtetes, acyclisches Diagramm von Knoten und
Verbindungslinien, sogenannten Kanten, dar. Die
angesprochenen Verfahren und Resourcen sind die Knoten in
dem Diagramm und die die Knoten verbindenden Kanten stellen
Verhältnisse zwischen den Knoten dar. Beispielsweise ist ein
ein Prozeß darstellender Knoten mit dem Knoten für den
Vorgänger über eine Kante verbunden, und der Knoten für eine
Datei, die gerade von einem Prozeß angesprochen wird, ist
mit dem Knoten für den Prozeß über eine weitere Kante
verbunden.
-
Ein wichtiger Vorteil des visuellen Prozeßmanagers
besteht darin, daß keine Änderung des von dem Verfahren
ausgeführten Codes erforderlich ist. Der Monitor wird
mittels einer dynamisch angeschlossenen Bibliothek
implementiert, welche die Bibliothek der
Betriebssystemaufrufe ersetzt, welche von dem Computersystem
mit einer neuen Bibliothek geliefert wird, welche nicht nur
die Systemaufrufe durchführt, sondern auch die Nachrichten
erzeugt. Masken pro Prozeß in dem Monitor ermöglichen es dem
Benutzer anzuzeigen, welche Systemaufrufe zu Nachrichten
führen, welche Form von Nachrichten es sein sollten, und ob
das Bibliothekunterprogramm für den Systemaufruf die
Bestätigung von dem Nutzer abwarten sollte, bevor
weitergefahren wird.
-
Während die bevorzugte Ausführungsform die hier
offenbarten Techniken zur Analyse von Prozeßsystemen
benutzt, sind die Techniken generell anwendbar und können in
jeder Situation verwendet werden, wenn eine Bibliothek von
Unterprogrammen von einer dynamisch angeschlossenen
Bibliothek von Unterprogrammen ersetzt werden kann, welche
die gleiche Funktion erfüllen, jedoch auch Nachrichten als
Seiteneffekt aussenden. Ein spezieller Vorteil dieser
Technik besteht darin, daß ein System analysiert werden
kann, ohne daß der Systemcode auf der Anwendungsebene
modifiziert oder rekompiliert werden müßte. Andere
zielrichtungen und Vorteile des Geräts und der hier
offenbarten Verfahren werden nach genauer Durchsicht der
folgenden zeichnungen und Einzelbeschreibung für den
Fachmann ersichtlich.
Kurze Beschreibung der Zeichnungen
-
Fig. 1 ist eine Konzeptzeichnung eines verteilten
Computersystems, bei welchem die Erfindung
implementiert werden kann;
-
Fig. 2 stellt ein Beispiel eines von der Erfindung erzeugten
Displays dar;
-
Fig. 3 stellt ein weiteres Beispiel eines von der Erfindung
erzeugten Displays dar;
-
Fig. 4 ist eine Übersicht einer Verwirklichung der
Erfindung;
-
Fig. 5 ist ein weiteres Beispiel eines von der Erfindung
erzeugten Displays;
-
Fig. 6 ist eine Skizze einer bei der Erfindung verwendeten
Nachricht und
-
Fig. 7 ist eine Skizze einer graphischen Datenstruktur, wie
sie in der Erfindung verwendet wird.
-
Die Bezugszeichen in der Zeichnung bestehen aus zwei
Teilen: die beiden niedrigen Stellen sind die Nummern eines
Teils in einer Figur, und die verbleibenden Ziffern sind die
Nummern der Figur, in welcher das Teil zuerst erscheint.
Demgemäß erscheint ein Teil mit dem Bezugszeichen 201 zuerst
in Fig. 2.
Detaillierte Beschreibung einer bevorzugten Ausführungsform
-
Die folgende Detailbeschreibung beschreibt zunächst
ein System, in welchem die Erfindung ausgeführt werden kann,
zeigt dann, wie eine bevorzugte Ausführungsform des Systems
einem Benutzer erscheint, und beschreibt schließlich die
Realisierung eines bevorzugten Beispiels im einzelnen.
System, in welchem der visuelle Prozeßmanager verkörpert
sein kann: Fig. 1
-
Fig. 1 zeigt ein konventionelles, modernes,
verteiltes Computersystem. Eine Anzahl von Prozessoren 103
steht untereinander über ein Kommunikationssystem 111 in
Verbindung, welches ein beliebiges System sein kann, welches
die Aussendung von Nachrichten zwischen den Prozessoren 103
ermöglicht. Ausführungsprogramme bei jedem Prozessor stellen
eine Anzahl von Prozessen 105 dar. Die Prozesse 105 können
Nachrichten zu anderen Prozessen 105 senden, die auf dem
gleichen oder anderen Prozessoren 103 ablaufen;
Nachrichtenprozesse, die auf anderen Prozessoren 103
ablaufen, werden über das Kommunikationssystem 111 gesendet.
Prozesse 109 können auch Zugriff zu Dateien 109 im
dauerhaften Speicher 107 erlangen. Die Dateien können auf
dem dauerhaften Speicher 107 sein, der dem Prozessor 103
angehört, auf dem der Prozeß 105 ausgeführt wird, oder auf
dem dauerhaften Speicher 107 sein, der einem anderen
Prozessor 103 angehört.
-
Ein Anwender des visuellen Prozeßmanagers verfügt
über eine Wiedergabevorrichtung 112 und
Eingangsvorrichtungen, beispielsweise ein Tastenfeld 117 und
eine Maus 119, die an einen der Prozessoren 103, in diesem
Fall der Prozessor 103a, angeschlossen sind. Mittels des
Tastenfeldes 117 oder der Maus 119 kann der Benutzer
Eingangssignale an den Prozessor 103a in Abhängigkeit von
Displays auf der Wiedergabe 113 der Wiedergabevorrichtung
112 eingeben. Im einzelnen kann der Benutzer die Maus 119
dazu benutzen, den Zeiger 115 im Display 113 zu bewegen, und
kann die Knöpfe der Maus 119 dazu benutzen, Befehle
einzugeben.
Anwenderansicht des visuellen Prozeßmanagers:
Fig. 2, 3 und 5
-
Ein Benutzer des visuellen Prozeßmanagers arbeitet
gewöhnlich mit einem Display, wie es ähnlich in Fig. 2
gezeigt ist. Die Graphik 201 erscheint auf der
Wiedergabevorrichtung 112. In den meisten Ausführungsformen
betreibt der Prozessor 103 ein Fenstersystem, und die
Graphik 201 erscheint in dem Fenster des Displays 113. Die
Graphik 201 stellt ein gerichtetes( acyclisches Diagramm
dar, welche ein System von miteinander kooperierenden
Prozessen zeigt, die auf vier Computern ablaufen. Jeder
Computer wird durch ein Cluster 203 mit dem Namen des
Computers (beispielsweise kiwi) dargestellt. Innerhalb jedes
Clusters ist eine Gruppe von Prozeßblöcken 205 vorgesehen.
Jeder Prozeßblock 205 stellt einen Prozeß 105 dar, der auf
dem von dem Cluster dargestellten Computer abläuft. Die Zahl
innerhalb des Prozeßblocks 205 stellt die
Prozeßidentifikation (pid) für den Prozeß dar. Die
Prozeßidentifikation ist die von dem Betriebssystem des
Computers 203 benutzte Zahl zur Identifizierung des
Prozesses. Der Zeichenzug ist der Name des Programms, das
gerade von dem Prozeß ausgeführt wird. Daher führt der
Prozeß 105 mit pid 23087 das gcc-Programm aus. Prozesse 105,
deren Prozeßblöcke 205 das Fragezeichen enthalten, führen
ein Prozeßinitialisationsprogramm aus. Die gestrichelten
Kanten 207 deuten "Eltern-Kind"-Verhältnisse zwischen den
Prozessen an. Ein Prozeß 105 ist ein Vorgänger (Elternteil)
eines anderen Prozesses 105, wenn der Vorgängerprozeß den
Befehl des Betriebssystems ausführte, welche den anderen
Prozeß 105 geschaffen hat. Demgemäß stellt der Prozeß 23086
den Vorgänger (Elternteil) des Prozesses 23088 dar.
-
Der Prozeß 105 hat natürlich Zugriff zu den Dateien
109. Die Dateien erscheinen in der Graphik 201 als
Dateiellipsen 209. Jede Dateiellipse 209 enthält einen
Buchstabenzug, welche der Name der von der Ellipse 209
dargestellten Datei ist. Wenn ein Prozeß 105 eine Datei 109
geöffnet hat, gibt es eine ausgezogene Kante 213, welche die
Prozeßblöcke 205 für den Prozeß und die Dateiellipse 209 für
die Datei einschließen. Wenn der Prozeß 105 die Datei zum
Auslesen geöffnet hat, gibt es einen Pfeil am Prozeßblock
205; wenn der Prozeß 105 die Datei zum Einschreiben geöffnet
hat, gibt es einen Pfeil an der Dateiellipse 209; wenn die
Datei sowohl zum Lesen als auch Schreiben geöffnet worden
ist, gibt es einen Pfeil an beiden Enden der Kante 213.
-
Die Prozesse 105 kommunizieren in den Systemen, in
welchen die Erfindung verwendet wird, und zwar über
sogenannte "Pipes" und "Sockets", die das UNIX-
Betriebssystem bereitstellen. "Pipes" werden nur für auf dem
kleinen Computer 103 ablaufende Prozesse und "Sockets" nur
für Kommunikationen zwischen auf unterschiedlichen Computern
103 ablaufenden Prozessen verwendet. Im Fall der "Sockets"
laufen die Nachrichtenverbindungen über das
Kommunikationssystem 111. "Pipes" und "Sockets" erscheinen
in der Graphik 201 als Pipe-Kreise 215 und Socket-Kreise
211. Ein Socket-Kreis 211 enthält den Namen des Computers,
welcher der Bestimmungsort des Sockets war, als der Kreis
und die Zahl in dem Anschluß des Bestimmungscomputers
geschaffen worden ist. Die Kanten 213 werden mit den Pipe-
Kreisen 215 und den Socket-Kreisen 211 in der gleichen Weise
wie bei den Dateiellipsen 209 benutzt: Wenn die
Verbindungsart "Pipe" oder "Socket zum Schreiben geöffnet
ist, liegt der Pfeil beim Kreis 211 oder 215 an; wenn die
Verbindungsart "Pipe" oder "Socket" zum Lesen geöffnet ist,
liegt der Pfeil an dem Prozeßblock 205 an. In der Version
des UNIX-Betriebssystems, in welchem die bevorzugte
Ausführungsform verwirklicht wird, ist die Betriebsart
"Pipe" unidirektional (in einer Richtung gerichtet). Ein
Prozeß schreibt in die Verbindungsart "Pipe" und der andere
liest aus der Verbindungsart "Pipe". Die Verbindungsart
"Socket" ist andererseits bidirektional.
Betrieb des visuellen Prozeßmanagers: Fig. 3 und 5
-
In einer bevorzugten Ausführungsform besteht der
visuelle Prozeßmanager aus zwei Hauptbestandteilen, wovon
der eine die Prozesse in einem System überwacht, wie sie
ablaufen, und der andere Nachrichten von der
Überwachungskomponente empfängt und eine Graphik 201 in
Abhängigkeit von den Nachrichten erzeugt. Die im bevorzugten
Ausführungsbeispiel verwendeten Komponenten sind ein
Monitor, basierend auf dem n-dimensionalen Dateisystem
(nDFS), beschrieben von Glenn Fowler, Yennun Huang, David
Korn und Herman Rao, "A user-level replicated file system"
in USENIX Cincinnati 1993 Summer Conference Proceedings,
Seiten 279-290, 1993, und einen Display-Erzeuger, basierend
auf den Programmen dot, erläutert von Emden R. Gansner,
Eleftherios Koutsofios, Stephen C. North und Kiem-Phong Vo,
"A technique for drawing directed graphs" in IEEE
Transactions on Software Engingeering, Band 19, Nr. 3, März
1993, und auf dem Programm lefty basierend, beschrieben von
Eleftherios Koutsofios und David Dobkin "Lefty: a two-view
editor for technical pictures" in Graphics Interface '91,
Seiten 68-76, Calgary, Alta, 1991.
-
Um den Betrieb des visuellen Prozeßmanagers in einer
bevorzugten Ausführungsform zu beginnen, startet der
Benutzer einen ersten Prozeß, welcher den Display-Erzeuger
betreibt, und einen zweiten Prozeß, welcher den Monitor
betreibt. Jeder Prozeß weist sein eigenes Fenster in der
Wiedergabevorrichtung 112 auf. Sobald der zweite Prozeß
läuft, führt der Benutzer einen Einrichtbefehl in der
zweiten Hülle ("shell") des Prozesses aus, welche eine
Protokolldatei spezifiziert, an welche der Monitor
Nachrichten sendet und von dem der Display-Erzeuger seinen
Eingang zu empfangen hat und das Betriebssystemm seine
Systemaufrufe empfängt, die von dem Monitor zu überwachen
sind. In einer bevorzugten Ausführungsform kann ein Nutzer
nur prozeßbezogene Betriebssystemaufrufe, prozeßbezogene
Betriebssystemaufrufe und dateizugangsbezogene
Betriebssystemaufrufe sowie die beiden vorgehenden Klassen
zusammen mit Eingangs/Ausgangs-Systemaufrufen spezifizieren.
In der bevorzugten Ausführungsform betreffend die
prozeßbezogenen Betriebssystemaufrufe die UNIX-Gabel
("fork"), "exec", und ausgehenden Aufrufen. Die
dateizugangsbezogenen Auf rufe sind: open, dose, dup, pipe,
und die Eingangs/Ausgangs-Aufrufe sind: Lesen (read) und
Schreiben (write). Wenn der zuvor erwähnte Einrichtbefehl
ausgeführt worden ist, beginnt der Monitor, Nachrichten zu
der Protokolldatei zu senden, die von dem Displayerzeuger
gelesen werden und der laufende Zustand des Prozesses, in
welchem der Einrichtbefehl ausgeführt wird, und diese
prozeßabhängigen Größen können in der Graphik 201
dargestellt werden. Alles, was für die Überwachung eines
gegebenen Systems von Prozessen benötigt wird, ist demnach,
den ersten Prozeß des Systems als Nachfolger (Kind) des
Prozesses zu starten, in welchem der Einrichtbefehl
ausgeführt wird.
-
Der Display-Erzeuger wird in zwei Betriebsweisen
tätig: Realzeit und Einzelschritt. In der Realzeit-
Betriebsweise liest der Display-Erzeuger die Nachrichten in
der Protokolldatei, wie der Monitor diese in der
Protokolldatei ablegt. In der Einzelschritt-Betriebsweise läuft das
überwachte System so lange, bis es endet, wobei alle
Nachrichten vom Monitor in der Protokolldatei abgelegt
werden. Danach liest der Display-Erzeuger die Nachrichten in
der Protokolldatei. In der bevorzugten Ausführungsform wird
die Betriebsweise mittels einer Option auf den Befehl
spezifiziert, der die Ausführung des Display-Erzeugers in
Gang setzt. In jedem Fall wird die Graphik 201 dynamisch au
dem laufenden gehalten, in dem Maße, wie die Nachrichten von
der Protokolldatei ausgelesen werden.
-
Der Betrieb des Display-Erzeugers in beiden
Betriebsweisen wird durch ein globales Menü gesteuert,
welches in der Graphik 201 erscheint, wenn der Zeiger 115
nicht über einen Knoten in der Graphik 201 positioniert ist
und der rechte Mausknopf gedrückt wird. Fig. 3 zeigt ein
globales Menü 301 für die Realzeit-Betriebsart. Die
Menüoptionen sind folgende:
-
- do layout: das Layout der Graphik 201 wird erneut
erstellt;
-
- redraw: die Graphik wird aufgefrischt;
-
- save graph: die Graphik wird in einer Datei gerettet;
-
- zoom in: die Graphik wird vergrößert;
-
- zoom out: die Graphik wird verkleinert;
-
- cleanup: aus der Graphik 201 werden Knoten entfernt,
welche tote Prozesse darstellen;
-
- find node: die Darstellung wird so verschoben, daß ein
durch pid oder einen Namen spezifizierter
Knoten im Mittelpunkt der Darstellung der
Graphik 201 steht;
-
- start/stop: die Aktualisierung der Graphik wird
unterbrochen, bis der Gegenstand erneut
ausgewählt wird;
-
- textview: Ansicht des Programms, welches zur Zeit von
dem Display-Erzeuger interpretiert wird, und
-
- exit: Endausführung des Display-Erzeugers.
-
Optionen werden dadurch ausgewählt, daß die Maus mit
dem Zeiger 115 auf den gewünschten Eingang in dem Menü
bewegt und der linke Mausknopf gedrückt wird. Wenn die
Graphik 201 größer als das Fenster ist, in welchem es
dargestellt wird, kann der Benutzer Zeilenverschiebung
(scroll bars) am Fenster benutzen, um die nicht
dargestellten Teile der Graphik in das Fenster zu bringen.
-
Das globale Menü für die Einzelschritt-Betriebsweise
unterscheidet sich von dem Menü für Realzeit-Betriebsweise
darin, daß die Funktionen "start/stop" und "cleanup" durch
die folgenden beiden Wahlmöglichkeiten ersetzt werden:
-
- play non-stop: der Display-Erzeuger reagiert auf die
Nachrichten der Protokolldatei, ohne
anzuhalten; und
-
- play until: der Nutzer kann einen Systemrufnamen
oder eine Nachrichtensequenznummer
spezifizieren.
-
Der Display-Erzeuger reagiert auf Nachrichten in der
Protokolldatei, bis der genannte Systemruf oder die
spezifizierte Nachricht in der Sequenz erreicht ist.
-
Wenn weder play-nonstop noch play-until ausgewählt
worden sind, steuert der Benutzer die Geschwindigkeit, mit
der die Nachrichten gelesen werden, mit der Maus: Wenn der
Benutzer mit dem linken Mausknopf klickt, wird die
Textnachricht gelesen und die Graphik 201 demgemäß
modifiziert. Die Einzelschritt-Betriebsweise gibt dem Nutzer
somit die Option, nur solche Teile des Betriebs des Systems
des Prozesses anzuschauen, an denen er interessiert ist.
-
Menüs für die Knoten der Graphik 201 ermöglichen es
dem Benutzer, Informationen über individuelle Knoten
herauszfinden und im Falle der Prozeßblöcke 205 die Prozesse
zu manipulieren. Um ein Knotenmenü zu erhalten, bewegt der
Nutzer den Zeiger 115 auf den gewünschten Knoten und klickt
mit dem rechten Mausknopf. Der Inhalt eines Knotenmenüs
hängt von der Art des Knotens und davon ab, ob der Display-
Erzeuger in Realzeit oder in Einzelschritt-Betriebsweise
läuft. Fig. 5 zeigt das Knotenmenü 501 für den Prozeßblock
66, 78 in Realzeit-Betriebsweise. Die mögliche Menüauswahl
ist wie folgt:
-
- print entry: Druckinformation über die von dem Knoten
dargestellte Instanz; bei einem Prozeßknoten
umfaßt die Information die Knotenart, die
Identifizierung (id) der Maschine, auf der
Prozeß läuft, der Name der Maschine, das pid
des Prozesses und der Wegname des gerade von
dem Prozeß ausgeführten Programms;
-
- print attributes: die Display-Attribute für den Knoten
werden ausgedruckt, beispielsweise die
Farbe, Gestalt, der Fontname und die
Fontgröße;
-
- kill: das Tötungskommando für das UNIX-
Betriebssystem wird auf den Prozeß
ausgeführt, um ihn zu beenden; der Prozeß
kann den Befehl ignorieren;
-
- kill-9: der Tötungsbefehl wird in einer Form
ausgeführt, welche es erforderlich macht, daß
der Prozeß beendet wird; und
-
- run dbx: ein Fehlerbeseitigungsbetrieb wird von dem
Prozeß auf das Programm betrieben.
-
In der Einzelschritt-Betriebsweise sind nur die
Wahlmöglichkeiten print entry und print attr verfügbar.
-
Die Menüs für die Dateiellipsen 209 umfassen nur die
Wahlmöglichkeiten print entry und print attr in beiden
Betriebsweisen. Wenn print entry gewählt wird, werden der
Dateiname, der Vorrichtungsname und der sogenannte Inode-
Name dargestellt. Die Menüs für die Pipe- und Socket-Kreise
211 umfassen diese Wahlmöglichkeiten und zusätzlich eine
Wahlmöglichkeit der Anzeigenachricht, welche die durch die
ausgewählte Pipe oder Socket laufende Nachricht zeigt, wenn
der Monitor I/O Systemaufrufe überwacht. Mit einer
Druckeinsprungadresse für die Betriebsart Pipe wird der
Identifizierer wiedergegeben, durch welchen jeder Prozeß,
der die Betriebsart Pipe benutzt, den betreffenden Pipe
kennt, und mit Sockets werden Socket-Name und Quelle und die
Bestimmungsmaschinennamen und -anschlüsse dargestellt.
Detaillierte Implementation: Fig. 4, 6 und 7
-
Ein Überblick der bevorzugten Ausführungsform des
visuellen Prozeßmanagers wird in Fig. 4 gebracht. Der
visuelle Prozeßmanager 401 weist die zuvor erwähnten
Hauptkomponenten auf: Monitor 418, der das Verhalten des
Prozesses 105 überwacht, das zu dem studierten System
gehört, und der Display-Erzeuger 419, welcher die Wiedergabe
201 auf der Wiedergabevorrichtung 113 erzeugt und auf
Eingangssignale des Tastenfeldes 117 und der Maus 119
reagiert. Die Kommunikation zwischen den Bauteilen findet in
der bevorzugten Ausführungsform über die Protokolidatei 411
statt, in welcher der Monitor 418 von den überwachten
Prozessen 109 empfangene Information 406 einschreibt und von
welchen der Wiedergabegenerator 419 die Information
ausliest.
Monitor 418
-
Auf Einzelheiten des Monitors 418 eingehend bestehen
dessen Komponenten aus einem Nachrichtengenerator 403 für
jeden Prozeß 105, die zu dem gerade studierten System
gehören, und ein Serverprozeß 409 für das hintere Ende. Der
Nachrichtengenerator 419 erzeugt Nachrichten, wenn der
Prozeß 105 zu überwachende Nachrichtenaufrufe ausführt. Der
Serverprozeß 409 für das rückwärtige Ende empfängt die
Nachrichten von den Prozessen 105 und schreibt sie in die
Protokolldatei 411 ein. Die Kommunikation zwischen den
Prozessen 105 und dem Serverprozeß 409 für das rückwärtige
Ende erfolgt über die Sockets, die von dem UNIX-
Betriebssystem bereitgestellt werden.
-
Wie im einzelnen von Fowler et al. in dem erwähnten
Artikel und in EP-A-0 629 950 beschrieben, wird der
Nachrichtengenerator 409 durch dynamische Verbindung jedes
Prozesses 105 mit dem ausführbaren Code für einen Satz von
Bibliothekunterprogrammen implementiert. Der überwachte
Prozeß 105 führt den dynamisch angeschlossenen Code anstelle
des Codes für Standardsystemaufrufe durch, der von dem UNIX-
Betriebssystem bereitgestellt wird. Die dynamische
Verbindung findet statt, wenn der Prozeß initialisiert wird.
Weil der ausführbare Code bei Prozeßbeginn dynamisch
angeschlossen ist, besteht keine Notwendigkeit, den von dem
Prozeß ausgeführten Anwendungscode zu ändern oder erneut zu
verknüpfen. Eine detaillierte Erörterung der dynamischen
Verknüpfungen kann in Shared Libraries, Sun Microsystems,
Inc., Mountain View, CA, 1988, angetroffen werden.
-
Der Code in den Bibliothek-Unterprogrammen für einen
gegebenen UNIX-Systemaufruf führt den Systemaufruf herbei;
zusätzlich produziert er jedoch auch Seiteneffekte. In dem
visuellen Prozeßmanager umfassen die Seiteneffekte die
Nachrichten 406. Fig. 6 zeigt Einzelheiten einer Nachricht
406. Die Nachricht umfaßt die folgenden Felder:
-
- Quellen-pid (SPID) 601, das pid des Prozessors 105,
welcher den Systemaufruf erzeugt hat, der zu der
Nachricht führte;
-
- Quellenmaschine (SMACH) 603, ein Identifizierer für den
Computer, auf welchem der Prozeß 105 abläuft;
-
- Systemaufrufname (Syscall Name) 605, der Name des
Systemaufrufs, der von dem Prozeß 105 erzeugt wird;
-
- Systemaufrufargumente (Syscall Args) 607, die Argumente
des Systemaufrufs, der von dem Prozeß 105 erzeugt wird;
und
-
- Systemaufrufresultate (Syscall results) 609, die
Ergebnisse des Systemaufrufs, geliefert von dem Prozeß
105.
-
In einer Nachricht 406 für einen Offensystemaufruf
umfassen die Argumente 607 beispielsweise den Wegnamen der
zu öffnenden Datei und die Betriebsweise, in welcher die
Datei zu öffnen ist, und das Ergebnis 609 umfaßt die
Vorrichtungsnummer der neueröffneten Datei und die Inode-
Nummer.
-
Wie in der Beschreibung der Benutzeransicht des
visuellen Prozeßmanagers angedeutet, kann ein Benutzer in
dem Einrichtbefehl spezifizieren, welche Arten von
Systemaufrufen zu überwachen sind. Diese Information wird in
einer Maske 405 für jeden Prozeß 105 gespeichert. Die
Unterprogramme in der dynamisch verknüpften Bibliothek
prüfen die Maske 405 für ein Verfahren 105 vor Aussendung
einer Nachricht und senden die Nachricht 406 nur dann, wenn
die Maske 405 anzeigt, daß die Nachricht für diese Klasse
von Systemaufrufen auszusenden ist. In der bevorzugten
Ausführungsform werden Masken in dem Einrichtbefehl
eingestellt und werden für Klassen von Systemaufrufen
eingerichtet. Die Masken werden dann von allen zu
überwachenden Prozessen übernommen. In anderen
Ausführungsformen können die Benutzer die Menüs zur
Einstellung der Masken für individuelle Prozesse und
Systemaufrufe verwenden. Die bevorzugte Ausführungsform
umfaßt zusätzlich eine sogenannte Terse-Maske
(Knappheitsmaske), die mit Systemaufrufen spezifiziert sein
kann, welche auf sogenannte Strings (geordnete Teilfolge
eines zu sortierenden Datenbestandes) zurückspringen.
Wenn die Terse-Maske nicht für den Systemaufruf eingestellt
worden ist, springt der Systemaufruf auf den String in der
Nachricht 406; wenn die Terse-Maske gesetzt ist, kehrt der
Systemaufruf den String in der Nachricht 406 um; wenn die
Terse-Maske gesetzt wird, kehrt der Systemaufruf einen
Zeiger zu dem String. Sobald eine Prozeßmaske gesetzt wird,
entweder über den Einrichtbefehl oder interaktiv, wird er
von den prozeßabhängigen Größen übernommen.
Display-Generator 419
-
Der Display-Generator 419 wird als zwei Prozesse
verwirklicht, und zwar als ein
Nachrichteninterpretationsprozeß 415 und als ein Graphikerzeugungsprozeß 417. In einer
bevorzugten Ausführungsform führt der
Nachrichteninterpretationsprozeß 415 das lefty-Programm aus, das von
der zitierten Literaturstelle Koutsofios beschrieben wird,
und der Graphikerzeugungsprozeß 417 führt das dot-Programm
aus, das in der zitierten Literaturstelle North beschrieben
ist.
-
Der Nachrichteninterpreter 415 liest die Nachricht
406 aus der Programmdatei 411; in Realzeit-Betriebsart liest
er die Nachrichten 406 in dem Maße wie der Rückendserver 409
die Nachrichten in die Programmdatei 411 einschreibt; in
Einzelschritt-Betriebsweise beginnt der
Nachrichteninterpreter 415 mit dem Auslesen von Nachrichten
406 aus der Programmdatei 411 erst dann, wenn der Prozeß 105
in dem zu überwachenden System abgeschlossen worden ist. Für
jede Nachricht bestimmt der Nachrichteninterpreter 415 die
Art des Systemaufrufs von der Nachricht 406 und führt die
erforderlichen Anderungen in der Graphikdatenstruktur 421
durch, welche die Graphik 201 darstellt, und zwar infolge
der Nachricht. Wenn keine weiteren Nachrichten 406 anliegen
oder wenn eine gegebene Anzahl von Nachrichten 406 seit dem
letzten Nachziehen verarbeitet worden sind, wird das Display
201 nachgezogen oder nachgezeichnet. Was eintritt, wenn die
Graphik 201 nachgezogen wird, hängt von der Art der durch
die Nachrichten 406 erforderlichen Änderungen ab. Wenn die
Änderungen kein neues Layout der Graphik 201 erforderlich
machen, nimmt der Nachrichteninterpreter 415 einfach
Information aus der Graphikdatenstruktur 421 und liefert sie
an das Fenstersystem 427, welches die Information dazu
benutzt, die Graphik 201 auf der Wiedergabevorrichtung 112
aktuell wiederzugeben. Wenn die Änderungen ein neues Layout
erforderlich machen, nimmt der Nachrichteninterpreter 415
die erforderliche Information für das neue Layout aus der
Graphikdatenstruktur 421 und liefert es an den
Graphikgenerator 417 als logische Graphikbeschreibung 423.
Der logische Graphikgenerator 423 springt auf eine
physikalische Graphikbeschreibung 425 zurück, die auf der
logischen Graphikbeschreibung an den Nachrichteninterpreter
415 basiert; der Nachrichteninterpreter 415 nimmt dann die
neue physikalische Graphikbeschreibung in die
Graphikdatenstruktur 421 auf und liefert Information von der
aktualisierten Graphikdatenstruktur 421 zum Fenstersystem
427, wie zuvor beschrieben.
-
Fig. 7 liefert Einzelheiten der Graphikdatenstruktur
421. Die Graphikdatenstruktur 421 weist zwei
Hauptkomponenten auf, nämlich ein Knotenfeld 701, welches
eine Knoteneinsprungadresse 703 für jeden Knoten in der
Graphik 201 enthält, und ein Kantenfeld 713, welches eine
Kanteneinsprungadresse 715 für jede Kante in der Graphik 201
enthält.
-
Jede Knoteneinsprungadresse 703 enthält vier Arten
von Information:
-
logische Knoteninformation 705, die der
Nachrichteninterpreter 415 als logische Graphikdaten 423 an
den Graphikgenerator 417 liefert;
Knotendisplayinformation 707, welche der Graphikgenerator
417 an den Nachrichteninterpreter 415 als physikalische
Graphikdaten 425 in Abhängigkeit von den logischen
Graphikdaten 423 liefert;
visuelle Prozeßmanagerinformation 709 und
Kantenzeigerliste 711.
-
Die visuelle Prozeßmanagerinformation 709 stellt die
Information dar, die in dem Knoten in der Wiedergabe 201 und
in dem Menü erscheint, die dem durch die
Knoteneinsprungadresse 703 dargestellten Knoten zugeordnet
ist. Die Kantenzeigerliste 711 enthält einen Zeiger zu jeder
Kanteneinsprungadresse 715 für eine Kante, die an dem durch
die Knoteneinsprungadresse 703 dargestellten Knoten beginnt
oder dort endet.
-
Die Kanteneinsprungadresse 715 enthält die gleiche
Klasse von Information für jede Kante. Logische
Kanteninformation 715 enthält die Information über die
Kante, welche der Nachrichteninterpreter 415 an den
Graphikgenerator 417 liefert; die Kantendisplayinformation
719 enthält die Information, welche von dem Graphikgenerator
417 an den Nachrichteninterpreter 415 rückgegeben wird; VPM-
Information 721 stellt die Information dar, die in dem der
Kante zugeordneten Menü erscheint; Ausgangszeiger 723 ist
ein Zeiger zu der Knoteneinsprungadresse 703 im Knotenfeld
701, welches die Quelle der Kante darstellt; Endzeiger 725
ist ein Zeiger zur Knoteneinsprungadresse 703 in dem
Knotenfeld 701, welches die Bestimmung der Kante darstellt.
Eine Beschränkung des Monitors 418, wie in der
bevorzugten Ausführungsform realisiert, besteht darin, daß
der Nachrichteninterpreter 415 nicht immer von der Nachricht
406 sagen kann, ob ein Prozeß 105 gestorben ist. In einer
bevorzugten Ausführungsform wird dieses Problem dadurch
behandelt, daß der Nachrichteninterpreter 415 die Zeitspur
seit der letzten Nachricht aus einem gegebenen Prozeß 105
hält. Wenn eine gewisse Zeitgrenze überschritten wird, fragt
der Nachrichteninterpreter 415 einen pit-Server 429 am
Computer, an dem der gegebene Prozeß lief, zur Bestimmung
darüber ab, ob der Prozeß 105 noch lebt. Wenn dies nicht der
Fall ist, entfernt der Nachrichteninterpreter 415 die
Information für den Prozeß 105 von der Graphikdatenstruktur
421, und beim nächsten Nachziehen der Graphik 201
verschwinden der Knoten für den Prozeß 105 und die Knoten
für jegliche Dateien oder Pipes, auf die einzig von dem
Prozeß zugegriffen worden ist.
-
Der Nachrichteninterpreter 415 behandelt ferner
Eingänge vom Tastenfeld 117 und der Maus 119, wie von dem
Fenstersystem 427 geliefert. Wenn beispielsweise ein Nutzer
den rechten Mausknopf drückt, um ein globales Menü oder ein
Knotenmenü anzufordern, bestimmt der Nachrichteninterpreter
415, welche Art von Menü erforderlich ist, und liefert die
Information für das Menü an das Fenstersystem 427, welche
das Fenster wiedergibt. Wenn der Nutzer eine
Menüeinsprungadresse wählt, welche die Wiedergabe von
Informationen erforderlich macht, zeigt das Fenstersystem
427 in ähnlicher Weise, daß die Auswahl stattgefunden hat,
und der Nachrichteninterpreter 415 erhält die Information
von der Graphikdatenstruktur 421 und liefert sie an das
Fenstersystem 427 zur Wiedergabe. Wenn ein Nutzer die
Tötungseinsprungadresse auf dem Knotenmenü für einen
speziellen Prozeß wählt, führt der Nachrichteninterpreter
415 den Systembefehl aus, welche den Prozeß 105 tötet.
Eine interaktive Version des visuellen Prozeßmanagers 401
-
In der bevorzugten Ausführungsform kann ein Nutzer am
Terminal nur die Geschwindigkeit bestimmen, mit welcher
Nachrichten in die logische Datei 411 durch den
Nachrichteninterpreter 415 eingelesen werden; er kann nicht
die Ausführung des Prozesses in dem System mittels des
visuellen Prozeßmanagers 401 steuern. In einer anderen
Ausführungsform kann der Nutzer den visuellen Prozeßmanager
401 zur aktuellen Steuerungsausführung des Systems des
Prozesses benutzen. In dieser Ausführungsform wird die
logische Datei 411 durch eine Socket 420 ersetzt, das den
Server 409 für das rückwärtige Ende direkt an den
Nachrichteninterpreter 415 anschließt; weiterhin verbinden
die bidirektionalen Sockets 416 den Server 409 für das
rückwärtige Ende mit den Nachrichtengeneratoren 403 für die
zu überwachenden Prozesse 105.
-
Es werden auch Änderungen in den Nachrichten 406, der
Maske 405 und dem Code für die dynamisch verknüpfte
Bibliothek erforderlich. Die Nachricht 406 führt nun ein
zusätzliches Feld, nämlich das ACK-Feld 611, welches
anzeigt, ob der Nachrichteninterpreter 415 eine vom Server
409 für das rückwärtige Ende empfangene Nachricht zu
bestätigen hat. Die Maske 405 umfaßt nunmehr eine
Bestätigungsmaske, welche auf der Basis "pro- Systemaufruf"
anzeigt, welcher Systemaufruf einer Bestätigung bedarf.
Schließlich werden die dynamisch verknüpften
Bibliothekunterprogramme modifiziert, um einen Code zu umfassen,
welcher die Bestätigungsmaske prüft, bevor die Nachricht
ausgesendet wird. Wenn die Maske anzeigt, daß der
Systemauf ruf einer Bestätigung bedarf, setzt das
Bibliothekunterprograrnm, welches den Systemaufruf ersetzt, das
Bestätigungsfeld 611 in der Nachricht und wartet eine
Bestätigungsnachricht vom Server 409 für das rückwärtige
Ende ab; nur wenn die Nachricht ankommt, führt das
Bibliothek-unterprogramm die Ausführung komplett durch.
-
Die Betriebsweise des interaktiven Betriebs ist wie
folgt: Um einen Prozeß 105 in den interaktiven Modus zu
setzen, benutzt ein Benutzer die Maus 119 wie zuvor
beschrieben, um das Menü 501 für den Prozeß zu erhalten. Das
Menü 501 enthält eine zusätzliche Einsprungadresse, welche
den interaktiven Modus spezifiziert. Wenn der Nutzer die
Einsprungadresse wählt, erscheint ein anderes Menü, welches
es dem Nutzer ermöglicht zu spezifizieren, welche
Systemaufrufe für diesen Prozeß zu bestätigen sind. Der
Nachrichteninterpreter 415 entnimmt den Eingang vom Menü und
belegt Felder für den Knoten, der anzeigt, welche
Systemaufrufe gerade bestätigt werden. Der
Nachrichteninterpreter 415 sendet auch eine Nachricht über
das Socket 420 zum Server 409 für das rückwärtige Ende aus,
der den Prozeß 409 spezifiziert, in welchem die
Systemaufrufe zu bestätigen sind und zu bestätigende
Systemaufrufe. Der Server 409 für rückwärtiges Ende sendet
dann eine Nachricht über das Socket 416 zu dem
spezifizierten Prozeß 105 aus, und der Code im
Nachrichtengenerator 403 spricht auf den Code an, in dem die
Bestätigungsmaske wie erforderlich von der Nachricht besetzt
wird.
-
Von der Zeit an, von der die Bestätigungsmaske
gesetzt ist, arbeitet das System 401 wie folgt: Wenn der
Prozeß 105 einen Systernaufruf ausführt, überprüft das
Bibliotheksunterprograrnm für den Systemaufruf die
Bestätigungsmaske 405 für den Systemaufruf. Wenn die Maske
gesetzt ist, ist auch das Bestätigungsfeld 611 der Maske 406
gesetzt, und das Bibliothekunterprogramm pausiert nach
Ausführung des Systemaufrufs und Aussenden der Nachricht
406. Wenn die Nachricht über den Sockel 416, den Server 409
für das rückwärtige Ende und den Sockel 420 im
Nachrichteninterpreter 415 ankommt, spricht der
Nachrichteninterpreter 415 auf das gesetzte Bestätigungsfeld
611 durch Änderung der Graphik 201 an, wie durch die
Nachricht 406 gefordert, und ändert das Aussehen des
Prozeßblocks 205 für den Prozeß. In der Wiedergabe, um zu
zeigen, daß der von dem Prozeßblock 205 dargestellte Prozeß
105 auf eine Bestätigung wartet. Der Nutzer sorgt für die
Bestätigung, indem er den Zeiger 115 auf den Prozeßblock 205
bewegt und mit dem linken Knopf klickt. In Abhängigkeit von
der Stellung des Zeigers 115 und dem Klick des linken Knopf s
sendet der Nachrichteninterpreter 415 eine
Bestätigungsnachricht über den Sockel 420, den Server 409
für das rückwärtige Ende und den Sockel 416 zum
Nachrichtengenerator 403 für den Prozeß. In Abhängigkeit von
der Nachricht beendet das Bibliotheksunterprogramm seine
Ausführung. Während dies so abläuft, ändert der
Nachrichteninterpreter 415 weiterhin das Aussehen der
Graphik 201, um anzudeuten, daß der Prozeß nicht weiter auf
Bestätigung wartet.
-
Es ist aus Vorstehendem ersichtlich, daß der Nutzer
des Systems 401 die Ausführung eines Prozesses 401 bis zu
jeglichem Grad von Granularität steuern kann. Andere
Ausführungsformen können eine Einsprungadresse im globalen
Menü 301 umfassen, welche das globale Setzen von
Bestätigungsmasken ermöglichen.
Schlußfolgerungen
-
Die vorhergehende Detailbeschreibung hat für
Fachleute die besten den Erfindern bekannten
Ausführungsarten zur Durchführung des visuellen
Prozeßmanagers offenbart. Jedoch sind die angewendeten
Techniken zur Implementierung des visuellen Prozeßmanagers
keineswegs auf die Analyse von Systemen von Prozessen
begrenzt, sondern können in jedem System benutzt werden, in
welchem eine vorn System benutzte Biblioteck dynamisch durch
eine andere Bibliothek ersetzt werden kann.
-
Wie weiter für Fachleute ersichtlich ist, gibt es
viele andere Arten der Implementierung des hier offenbarten,
visuellen Prozeßmanagers. Beispielsweise sind die hier
offenbarten, dynamischen Verknüpfungs- und graphische
Zeichnungstechniken speziell zur Implementierung der
Erfindung vorteilhaft, jedoch könnten die
Bibliothekunterprogramme im Monitor 418 statisch mit dem vom Prozeß
ausgeführten Code verknüpft werden, und es könnten außer
"lefty" und "dot" noch andere Graphikzeichnungsprogramme
verwendet werden, um den Displaygenerator 419 zu
realisieren. Die Auswahl der zu überwachenden
Betriebssystemaufrufe ändert sich von Betriebssystem zu
Betriebssystem und kann sich auf gemäß der Anwendung ändern,
für die der visuelle Prozeßmanager beabsichtigt ist. In
ähnlicher Weise können sich die Arten der verfügbaren
Maskierung von Implementation zu Implementation
unterscheiden.
-
In gleicher Art sind die in der Graphik 201
verwendeten Gestalten, Etiketten und Farben in einer
bevorzugten Ausführungsform alle speziell vorteilhaft,
jedoch könnten andere Ausführungsformen, andere Gestalten
und andere Farben verwendet werden, und es können auch
unterschiedliche Entscheidungen hinsichtlich der Information
getroffen werden, welche direkt auf einem Knoten gezeigt
wird, und was über ein Menü zugänglich ist. Weiterhin können
andere Ausführungsformen dem Benutzer mehr oder weniger
Steuerung des Displays 201 oder des Betriebssystems der
Prozessen offerieren oder könnten auch unterschiedliche
Techniken zur Ingangsetzung der Ausführung des Systems
bieten. Weil dies der Fall ist, ist die vorhergehende
Detailbeschreibung in allen Aspekten exemplarisch und
illustrativ zu betrachten und nicht einschränkend, und der
volle Schutzumfang der offenbarten Erfindung wird nicht von
der Detailbeschreibung bestimmt, sondern von den angefügten
Ansprüchen interpretiert in voller Breite, wie durch durch
die Patentgesetze ermöglicht.