DE69733739T2

DE69733739T2 - Rechnersystem und Verfahren zum Testen eines Netzwerkmanagement-Agenten (TMN-Agenten)

Info

Publication number: DE69733739T2
Application number: DE69733739T
Authority: DE
Inventors: Paul Fort Collins Stoecker; Mark D. Fort Collins Smith
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Development Co LP
Priority date: 1996-10-28
Filing date: 1997-10-08
Publication date: 2006-04-27
Anticipated expiration: 2017-10-09
Also published as: JPH10187483A; EP0843441B1; US5850511A; EP0843441A3; DE69733739D1; EP0843441A2

Description

Gebiet der Erfindung
Diese Erfindung bezieht sich auf Computer-implementierte Verfahren und Vorrichtungen, die das Testen eines Telekommunikationsverwaltungsnetzwerk- (TMN-) Agenten vor der Entwicklung, Installation und Konfiguration einer TMN-Verwaltungseinrichtung ermöglichen. Insbesondere bezieht sich die Erfindung auf eine Computersoftware zum Erzeugen, Editieren, Ausführen und Auswerten von TMN-Agententests.
Hintergrund der Erfindung
TMN-Standards definieren ein Verwaltungseinrichtungs-/Agenten-Paradigma für den hierarchischen Austausch von Verwaltungsinformationen über ein Kommunikationsnetzwerk. Bei dem TMN-Paradigma 200 (2) übernimmt ein Verwaltungssystem 202 die Rolle einer Verwaltungseinrichtung 204, sendet Anforderungen 206 an verwaltete Systeme 210 und empfängt Mitteilungen 208 von den verwalteten Systemen 210. Ein verwaltetes System 210 übernimmt die Rolle eines Agenten 212, empfängt und antwortet auf Anforderungen 206, 214 von einem Verwaltungssystem 202 und emittiert Mitteilungen 208, 216 für die verwalteten Objekte 220–224, die in dem Objektmodell 218 des Agenten definiert sind.
Da die Entwicklung und Implementierung eines Kommunikationsnetzwerks 300 von den Beiträgen verschiedener Personen abhängt (z. B. kann eine Person einen TMN-Agenten 212 konfigurieren, eine andere kann eine TMN-Verwaltungseinrichtung 204 konfigurieren usw.), ist es außerordentlich wichtig, Standards für die Entwicklung, Implementierung und den Betrieb eines derartigen Systems zu definieren.
Zu diesem Zweck hat die ISO (Internationale Standardorganisation) eine Anzahl von Standards, die den Austausch von Verwaltungsinformationen über ein Kommunikationsnetzwerk 200 regeln, übernommen. Ein erster dieser Standards ist GDMO (Richtlinien für die Definition von verwalteten Objekten, ITU-T X.722). GDMO ist eine Sprache, die verwendet wird, um eine Verwaltungseinrichtungs-/Agentenschnittstelle 218 zu definieren. Unter Verwendung von GDMO können verwaltete Objektklassen definiert werden, die zu verwaltende tatsächliche System- und Netzwerkressourcen (d. h. Schalter usw.) darstellen. Eine verwaltetet Objektklasse (MOC) spezifiziert alle Attribute, Aktionen und Mitteilungen einer verwalteten Ressource. Verwaltete Objektklassen können von abstrakteren verwalteten Objektklassen erben, wie es durch TMN-Standards, wie z. B. X.721 und M.3100, definiert ist. GDMO verwendet ASN. 1 (Abstrakte Syntax-Notation Eins, ITU-T X.208), um die Syntax dieser verschiedenen Datenelemente zu spezifizieren. Eine Sammlung von verwalteten GDMO-Objektklassen und ihren unterstützenden Definitionen kann zusammen zu einer logischen Entität gruppiert werden, die als ein GDMO-Dokument (oder GDMO-Modell 218) bekannt ist. MOCs sind C++-Klassen sehr ähnlich.
Eine Instanz einer MOC, die ihre eigenen gesonderten Zustandsinformationen aufweist, wird ein verwaltetes Objekt 220–224 genannt. Ein verwaltetes Objekt 220 unterscheidet sich von einem herkömmlichen Softwareobjekt darin, dass seine Zugriffsverfahren nicht in sich geschlossen sind. Stattdessen liefert ein Agent 212 einen Satz von standardisierten Zugriffsverfahren für alle verwalteten Objekte 220–224 unter seiner Steuerung. Diese standardisierten Zugriffsverfahren sind als Dienste bekannt und sind durch CMIS 226 (allgemeine Verwaltungsinformationsdienstdefinition, ITU-T X.710) definiert. Dienste weisen Erzeugen, Erhalten, Setzen, Aktion, Mitteilung oder Ereignis sowie Löschen auf. Ein Agent 212 dient deshalb als ein Kommunikationspunkt für die verwalteten Objekte 220–224 unter seiner Steuerung (und eine CMIS-Kommunikation 226 wird deshalb als eine Verwaltungseinrichtungs-/Agenten-Kommunikation anstatt Verwaltungseinrichtungs-/Verwaltetes-Objekt-Kommunikation bezeichnet).
Verwaltete Objekte 220–224 werden unter Verwendung eines hierarchischen Benennungsschemas benannt, das durch einen Baum 300 (3) dargestellt werden kann. TMN-Standards bezeichnen diesen Baum als einen Enthaltenseinsbaum, da Bögen 308, 310 zwischen Baumknoten eine Enthaltenseinsbeziehung darstellen. Es sei darauf hingewiesen, dass die Enthaltenseinsbeziehung eine Beziehung zwischen verwalteten Objekten 220–224 und nicht verwalteten Objektklassen ist. Es sei ebenfalls darauf hingewiesen, dass ein verwaltetes Objekt 302 in nur einem enthaltenden verwalteten Objekt 304 enthalten ist, das wiederum in einem anderen enthaltenden verwalteten Objekt 306 enthalten sein kann, usw.
3 veranschaulicht einen einfachen Enthaltenseinsbaum 300. Der Name jedes verwalteten Objekts 302–306 in einem Enthaltenseinsbaum 300 ist aus dem Namen seines enthaltenden verwalteten Objekts (d. h. seines Übergeordneten) und einem Attributwert gebildet, der das verwaltete Objekt in dem Bereich des enthaltenden verwalteten Objekts eindeutig identifiziert. Das Attribut, dessen Wert ein verwaltetes Objekt eindeutig identifiziert, wird allgemein als ein „Benennungsattribut" oder „Kennzeichnungsattribut" eines verwalteten Objekts bezeichnet.
Der Satz von möglichen Enthaltenseinsbeziehungen, die in einem Enthaltenseinsbaum 300 repräsentiert sein können, ist in einem GDMO-Modell 218 definiert, das „Namenverbindungs"-Schablonen verwendet. Eine Namenverbindungsschablone definiert eine einzige Enthaltenseinsbeziehung zwischen einer übergeordneten und einer untergeordneten verwalteten Objektklasse (und liefert deshalb den Namen einer übergeordneten verwalteten Objektklasse, den Namen einer untergeordneten verwalteten Objektklasse und den Namen eines Attri buts, das verwendet wird, um eine Instanz der untergeordneten verwalteten Objektklasse zu kennzeichnen). Ein voller Satz von möglichen Enthaltenseinsbeziehungen 402–420 kann durch einen Baum dargestellt sein, der „Benennungsbaum" 400 genannt wird. Wenn ein bestimmter Weg durch den Benennungsbaum (und möglicherweise ein Kennzeichnungsattribut) ausgewählt wird, um ein verwaltetes Objekt zu benennen, wird das verwaltete Objekt ein Teil des Enthaltenseinsbaums 300 eines Agenten. Es sei darauf hingewiesen, dass der Name eines verwalteten Objekts von einem von vielen Wegen durch einen Benennungsbaum 400 abgeleitet werden kann, dass jedoch, wenn derselbe einmal abgeleitet ist, der Name eines verwalteten Objekts durch nur einen Weg durch einen Enthaltenseinsbaum 300 dargestellt wird. Es sei ebenfalls darauf hingewiesen, dass jeder Weg durch einen Benennungsbaum 400 mit einer „Wurzel" beginnt, bei der es sich um eine Nullobjektklasse handelt, die durch TMN-Standards definiert ist.
Beim Entwickeln eines TMN-Agenten 212 muss ein Agentenentwickler seinen oder ihren Agenten 212 testen, um zu bestimmen, ob derselbe mit seinem GDMO-Modell 218 konform ist, Testanforderungen geeignet handhabt und bei Bedarf Mitteilungen emittiert. Bevorzugt wird ein Agent 212 während seiner gesamten Entwicklung getestet. Auf diese Weise ist es einfacher, Zusätze und/oder Veränderungen bei dem Agenten 212 zu bereinigen (debug). Ein Agententesten ist jedoch schwierig, da das Testen erfordert, dass ein zweiendiger Kommunikationskanal 226 eingerichtet wird.
In der Vergangenheit stand ein Agentenentwickler oft vor den Aufgaben, gleichzeitig sowohl einen Agenten 212 als auch eine Verwaltungseinrichtung 204 zu entwickeln und beide gleichzeitig zu bereinigen. Dies macht es jedoch sehr schwierig, Fehler zu ihrer Grundursache zu verfolgen, da es wahrscheinlich ist, dass anfangs beide Enden eines Kommunikationskanals Fehler aufweisen (d. h. sowohl der Agent als auch die Veraltungseinrichtung weisen Fehler auf).
Einige Softwarepakete ermöglichen die Erzeugung einer „Voreinstellungsverwaltungseinrichtung, die in der Lage ist, einfache Testanforderungen an einen Agenten 212 zu senden. Diese Voreinstellungsverwaltungseinrichtungen sind jedoch oft nicht in der Lage, einen Agenten 212 voll auszutesten.
Frohnhoff B, Schulz-Sternkopf P: „An advanced TMN test system-TSE-P" (IEEE Network Operations and Management Symposium, Bd. 1, 15.–19. April 1996, S. 444–453, XP002106579 Kyoto) beschreibt ein Testsystem, bei dem eine Verwaltungseinrichtung oder ein Agent eine komplementäre Rolle beim Testen eines zu testenden Systems übernimmt. Die Verwaltungseinrichtung oder der Agent implementiert das gleiche Informationsmodell wie das zu testende System.
Es ist deshalb eine primäre Aufgabe dieser Erfindung, Verfahren und Vorrichtungen zu schaffen, die das Testen eines TMN-Agenten 212 vor der Entwicklung, Installation und Konfiguration einer TMN-Verwaltungseinrichtung 204 ermöglichen.
Es ist eine weitere Aufgabe dieser Erfindung, Verfahren und Vorrichtungen zu schaffen, die in einer Computersoftware ausgeführt sind, die die Erzeugung, das Editieren, die Ausführung und die Auswertung von TMN-Agententests ermöglichen.
Es ist eine weitere Aufgabe dieser Erfindung, eine TMN-Agententestvorrichtung zu schaffen, die gesonderte Testerzeugungs- und Testausführungsmaschinen aufweist. Auf diese Weise erfordern Veränderungen bei einem GDMO-Modell eines Agenten nur die Erzeugung von neuen Agententests und machen nicht ein Neukompilieren der Testausführungsmaschine erforderlich.
Zusammenfassung der Erfindung
Bei der Lösung der vorhergehend genannten Aufgaben haben die Erfinder Softwareverfahren und -vorrichtungen zum Erzeugen, Editieren, Ausführen und Auswerten von TMN-Agententests entwickelt.
Bei einem ersten Aspekt der vorliegenden Erfindung wird eine Vorrichtung zum Testen einer Funktionalität eines Telekommunikationsverwaltungsnetzwerkagenten außerhalb einer Laufzeitnetzwerkumgebung geschaffen, wobei die Vorrichtung folgende Merkmale aufweist: a) ein oder mehr computerlesbare Speichermedien; und b) einen computerlesbaren Programmcode, der in den ein- oder mehr computerlesbaren Speichermedien gespeichert ist, wobei der computerlesbare Programmcode folgende Merkmale aufweist: i) einen Code 100, 108 zum Erstellen eines internen Enthaltenseinsbaums 700, der einen Laufzeitenthaltenseinsbaum 228 des Telekommunikationsverwaltungsnetzwerkagenten spiegelt, wobei der interne Enthaltenseinsbaum eine Anzahl von Knoten 702, 704 aufweist, die verwalteten Objekten 220, 222 in dem Laufzeitenthaltenseinsbaum entsprechen; ii) einen Code 108 zum Erzeugen von Funktionstests 110, die jedem Knoten des internen Enthaltenseinsbaums entsprechen; und iii) einen Code 116 zum Ausführen der Tests über den Telekommunikationsverwaltungsnetzwerkagenten.
Gemäß einem zweiten Aspekt der vorliegenden Erfindung wird ein Computer-implementiertes Verfahren zum Testen einer Funktionalität eines Telekommunikationsverwaltungsnetzwerkagenten außerhalb einer Laufzeitnetzwerkumgebung geschaffen, wobei das Verfahren folgende Schritte aufweist: a) Erstellen eines internen Enthaltenseinsbaums 700, der eine rechnergestützte Datenstruktur von verbundenen Knoten 702–710 aufweist, die verwalteten Objekten 220–224 des Laufzeitenthaltenseinsbaums 228 des Telekommunikationsverwaltungsnetzwerkagenten entsprechen und dieselben spiegeln; b) Erzeugen von Funktionstests 110, die jedem Knoten 702, 704 des internen Enthaltenseinsbaums entsprechen; und c) Ausführen der Tests durch ein Codieren derselben und ein Senden derselben über einen Telekommunikationskanal 226 an den zu testenden Telekommunikationsverwaltungsnetzwerkagenten.
Ein erstes Merkmal der Software ist eine Testerzeugungsmaschine, ovatgen 108, die ein GDMO-Modell 102 liest und automatisch eine Folge von Tests 110 erzeugt, um einen Agenten 118 konform zu dem Modell 102 auszutesten. Bei dem Prozess wird eine interne Darstellung eines Laufzeitenthaltenseinsbaums eines Agenten (ein interner CT-Baum) durch die Testerzeugungsmaschine erstellt. Der interne CT-Baum spiegelt einen Laufzeitenthaltenseinsbaum 228 eines Agenten (2).
Eine erzeugte Testfolge 110 weist CMIS-Anforderungen auf, die CMIS-Dienste (wie z. B. Erzeugen, Erhalten, Setzen und Löschen) bei einer MOC-Instanz durchführen, die durch das GDMO-Modell 102 definiert ist.
Voreinstellungs-MOC-Attributwerte, die auf ASN.1-Syntax-Definitionen basieren, werden erzeugt und durch die Tests 110 verwendet.
Zusätzlich wird eine Testdatei-„Stapelliste" 112 erzeugt, die Befehle enthält, um die erzeugten Tests 110 auszuführen. Die Stapelliste 112 wird in Textform geliefert und kann durch einen Agentenentwickler kundenspezifisch gemacht werden, um die Sequenz, in der Tests ausgeführt werden, zu ändern, zusätzliche Tests hinzuzufügen, die Datenwerte, die bei einem oder mehr Tests verwendet werden, zu verändern oder Befehle hinzuzufügen, um Mitteilungen und dergleichen auszulösen (vielleicht über den Editor, der in den Figuren mit ovated 114 bezeichnet ist).
Per Voreinstellung werden die Tests 110 für jede MOC eines GDMO-Dokuments 102 erzeugt. Tests können jedoch für einen Teilsatz von MOCs erzeugt werden, indem der Testerzeugungsmaschine 108 entweder eine MOC-Auswahlliste 106 oder eine Enthaltenseinsbaumspezifikationsdatei (CT-Spez-Datei 104) geliefert wird. Eine CT-Spez-Datei 104 ermöglicht es einem Agentenentwickler, die Form eines Enthaltenseinsbaums 228 zu liefern, für den die Tests 110 erzeugt werden sollen. Spezifische Verwaltetes-Objekt-Instanznamen, die Namen von Verzeichnissen, in denen Tests für eine Verwaltetes-Objekt-Instanz gespeichert werden, das Kennzeichnungsattribut eines verwalteten Objekts und selbst der Wert eines Kennzeichnungsattributs eines verwalteten Objekts können in der CT-Spez-Datei 104 bereitgestellt sein.
Falls es erwünscht ist, kann eine allgemeine CT-Spez-Datei 104 unter Verwendung der Komponente ovatct 100 der Software erzeugt werden. Eine CT-Spez-Datei, die auf diese Weise erzeugt wird, wird von GDMO-Dokumenten 102 abgeleitet und kann Voreinstellungswerte für MOC-Kennzeichnungsattribute aufweisen. Die CT-Spez-Datei 104 kann dann editiert werden, wie es bei einer CT-Spez-Datei 104 der Fall wäre, die ganz neu geschrieben wird.
Eine MOC-Auswahlliste 106 liefert nur eine Liste von MOCs, für die Tests 110 erzeugt werden sollen. Da jedoch eine CT-Spez-Datei 104 zusätzliche Informationen bezüglich der MOCs liefert (einschließlich Instanznamen und ihren Beziehungen), werden die MOC-Listendateien 106 ignoriert, wenn eine CT-Spez-Datei 104 der Testerzeugungsmaschine 108 verfügbar gemacht wird.
Die erzeugten Tests 110 werden in eine Verzeichnisstruktur platziert, die den Agentenenthaltenseinsbaum 228 spiegelt, der durch die Tests 110 erzeugt werden soll. Auf diese Weise können die Tests 110 und/oder ein Agent 118 mit größerer Leichtigkeit bereinigt werden.
Die Software weist auch eine Testausführungsmaschine ovatrun 116 auf, die die Tests ausführt, Testergebnisse 120 mit erwarteten Ergebnissen 124 vergleicht und dann einen Bericht 126 erzeugt, der den Erfolg oder den Fehlschlag von kürzlich ausgeführten Tests anzeigt. Als ein integrierter Teil der Testausführungsmaschine 116 ist eine Testbefehlssprache bereitgestellt, die alle CMIS-Dienstanforderungen (d. h. Erzeugen, Erhalten, Setzen, Aktion, Löschen, Abbrechen-Erhalten), das Senden von synchronen oder asynchronen Anforderungen, das Senden von bestätigten oder unbestätigten Anforderungen, eine automatische oder explizite Zuordnungssteuerung, das Empfangen von Ereignissen und Systemaufrufe unterstützt.
Die Testausführungsmaschine 116 liefert ein Ausführen der Tests 110 in einem interaktiven oder Stapelmodus. Durch ein Ausführen von Tests in einem interaktiven Modus können der Erfolg oder Fehlschlag jedes Tests überwacht werden und Fehler können unmittelbar diagnostiziert werden. Eine interaktive Testausführung kann verwendet werden, um eine Datei von bekannten fehlerfreien Testergebnissen 120 zu erzeugen. Die bekannten fehlerfreien Ergebnisse 120 können dann unter Verwendung des Werkzeugs ovatexp 122 in ein Erwartete-Ergebnisse-Verzeichnis 124 kopiert werden.
Diese und andere wichtige Vorteile und Ziele der vorliegenden Erfindung werden in der Beschreibung, den Zeichnungen und Ansprüchen, die beiliegen, näher erläutert oder werden aus denselben ersichtlich.
Kurze Beschreibung der Zeichnungen
Ein veranschaulichendes und derzeit bevorzugtes Ausführungsbeispiel der Erfindung ist in den Zeichnungen veranschaulicht. Es zeigen:
1 die Wechselwirkung von verschiedenen Softwarekomponenten, die ein Erzeugen, Editieren, Ausführen und Auswerten von Tests eines TMN-Agenten liefern;
2 die Komponenten eines einfachen Telekommunikationsverwaltungsnetzwerks;
3 einen einfachen TMN-Agentenenthaltenseinsbaum;
4 einen einfachen Benennungsbaum;
5 und 6 einen bevorzugten Codefluss zum Implementieren der Testerzeugungsmaschine ovatgen von 1;
7 die Struktur eines einfachen internen Enthaltenseinsbaums (interner CT-Baum);
8 bis 11 eine bevorzugte Struktur für einen Intern-CT- Baum-Knoten;
12 eine INFO-Datei, die durch die Testerzeugungsmaschine der 5 und 6 erzeugt wird;
13 eine Erzeugargument- (CreateArgument-) Datei, die durch die Testerzeugungsmaschine der 5 und 6 erzeugt wird;
14 eine Erhaltargument- (GetArgument-) Datei, die durch die Testerzeugungsmaschine der 5 und 6 erzeugt wird;
15 eine Setzargument- (SetArgument-) Datei, die durch die Testerzeugungsmaschine der 4 und 6 erzeugt wird;
16 eine Gruppen-GetArgument-Datei, die durch die Testerzeugungsmaschine der 5 und 6 erzeugt wird;
17 eine Gruppen-SetArgument-Datei, die durch die Testerzeugungsmaschine der 5 und 6 erzeugt wird;
18 eine Aktionsargument- (ActionArgument-) Datei, die durch die Testerzeugungsmaschine der 5 und 6 erzeugt wird;
19 eine Bedingtes-Paket- (Conditional Package) Datei, die durch die Testerzeugungsmaschine der 5 und 6 erzeugt wird;
20 ein Attribut-Modifikationsliste- (modification-List-) Dateifragment, das durch die Testerzeugungsmaschine der 5 und 6 erzeugt wird;
21 ein Modifizieroperator- (modifyOperator-) Fragment, das durch die Testausführungsmaschine der 5 und 6 erzeugt wird;
22 ein Attributlisten- (attributeList-) Dateifragment, das durch die Testerzeugungsmaschine der 5 und 6 erzeugt wird;
23 eine Löschargument- (DeleteArgument-) Datei, die durch die Testerzeugungsmaschine der 5 und 6 erzeugt wird;
24 eine Ereignisweiterleitungsdiskriminator- (Event Forwarding Discriminator) Datei, die durch die Testerzeugungsmaschine der 5 und 6 erzeugt wird;
25 Eingaben für sowohl einen Enthaltenseinsbaumspezifikationsdateigenerator und die Testerzeugungsmaschine der 5 und 6;
26 einen bevorzugten Codefluss zum Implementieren des Enthaltenseinsbaumspezifikationsdateigenerators ovatct von 1; und
27 einen bevorzugten Codefluss zum Implementieren der Testausführungsmaschine ovatrun von 1.
Beschreibung des bevorzugten Ausführungsbeispiels
Eine Vorrichtung zum Testen eines Telekommunikationsverwaltungsnetzwerk- (TMN) Agenten ist in den 1, 5, 6, 26 und 27 dargestellt und kann allgemein ein oder mehr computerlesbare Speichermedien und einen computerlesbaren Programmcode aufweisen, der in den ein oder mehr computerlesbaren Speichermedien gespeichert ist. Ein erster Teil des computerlesbaren Programmcodes 100, 108 (1) kann einen Code (5 und 26) zum Erstellen eines internen Enthaltenseinsbaums 700 (7) aufweisen, der den Laufzeitenthaltenseinsbaum 228 (2) eines TMN-Agenten 212 spiegelt, wobei der interne Enthaltenseinsbaum 700 eine Anzahl von Knoten 702, 704 aufweist, die verwalteten Objekten 220, 222 in einem Laufzeitenthaltenseinsbaum 228 entsprechen. Ein zweiter Teil des Codes 108 kann einen Code (6) zum Erzeugen von Tests 110 für jeden Knoten 702, 704 des internen Enthaltenseinsbaums 700 aufweisen. Ein dritter Teil des Codes 116 kann einen Code (27) zum Ausführen der erzeugten Tests 110 aufweisen.
Nachdem somit die Vorrichtung zum Testen eines TMN-Agenten allgemein beschrieben worden ist, wird die Vorrichtung nun genauer beschrieben. Das folgende bevorzugte Ausführungsbeispiel einer Agententestsoftware ist speziell für eine Kompatibilität mit der OpenView Distributed Management Platform (Verteilte-Verwaltung-Plattform) von Hewlett-Packard konzipiert. Folglich ist hiermit „HP OpenView Integration Series Distributed Management Developer's Reference for HP 9000 Series and Sun Systems" (April 1996) durch Bezugnahme bezüglich allem, was darin offenbart wird, aufgenommen (es sei speziell hingewiesen auf die Seiten 1–7 – 1–11, 1–39–1–57, 1–192–1–193, 1–202–1–203, 1–210–1–214 und 1–223–1–225).
I. Testerzeugungsmaschine
Allgemein kann die Testerzeugungsmaschine 108 von 1 zwei Module, ovatgen und atgen, aufweisen, wobei ovatgen ein Shell-Script-Treiber für das atgen-Ausführelement ist.
Die Testerzeugungsmaschine 108 kann durch ein Ausgeben eines Befehls der folgenden Syntax gestartet werden:
ovatgen [-t test_dir] [-f file] [-c file] [-m file] [-p file] [-M moc] [-P moc] [-s string] [-x721] [-noX721] [-a] [-h] [-v] [-w] [-y] [gdmo.mib | gdmo.md...]
Befehlszeilenoptionen sind ferner wie folgt definiert:
-a Wenn die -a-Option gegeben ist, werden Testverzeichnisnamen nicht abgekürzt. Per Voreinstellung werden Testverzeichnisnamen durch ein Stutzen jedes Abschnitts eines MOC-Namens auf einige wenige Schriftzeichen erzeugt (MOC-Namen beginnen mit einem Kleinschriftzeichen, und ein Großschriftzeichen beginnt jeden Abschnitt). Die -a-Option umgeht diese Heuristik und stellt die Verwendung von vollen MOC-Namen sicher. Falls jedoch optionale Abkürzungsfelder in einer CT-Spez-Datei 104 gegeben sind (siehe unten), haben die Abkürzungsfelder Vorrang gegenüber sowohl gestutzten als auch vollen Namen.
-c file
Die Datei, die unter Verwendung der -c-Option spezifiziert wird, ist eine Enthaltenseinsbaumspezifikationsdatei (CT-Spez-Datei 104). Die CT-Spez-Datei 104 spe zifiziert, für welche MOCs Tests erzeugt werden, die Namen von Verzeichnissen, in denen Tests platziert werden, und den Wert des Kennzeichnungsattributs jeder Verwaltetes-Objekt-Instanz:
-f file
Die Datei, die durch die -f-Option spezifiziert wird, ist eine Dokumentnamendatei. Die Dokumentnamendatei listet GDMO-Dokumente 102 auf, die als die Basis zur Testerzeugung (d. h. GDMO-Eingabe) dienen, und weist jedem einen Dokumentnamen zu.
-h Die -h-Option ist trivial und druckt lediglich eine Hilfe- (oder Verwendungs-) Nachricht.
-M moc
-P moc
Die -M- und -P-Optionen liefern jede den Namen einer einzigen MOC, für die Tests erzeugt werden. Da eine CT-Spez-Datei 104 genauere Informationen bezüglich MOCs, die in eine Testerzeugung eingeschlossen werden sollen, liefert, wird diese Option ignoriert, wenn die -c-Option verwendet wird.
-m file
-p file
Die -m- und -p-Optionen liefern jede den Namen einer MOC-Listendatei. Die Listendatei liefert die Namen von mehreren MOCs, für die Tests erzeugt werden. Wieder wird diese Option ignoriert, wenn die -c-Option verwendet wird.
-noX721
Wenn dieselbe verwendet wird, ist weder die minimale noch die volle Version des ITU-T X.721-Standards in der GDMO-Eingabe enthalten.
-s string
Die -s-Option liefert ein Mittel zum Ersetzen der ersten Zeile einer INFO-Datei 1200 (12; eine Datei, die informative Benutzerdaten bezüglich Tests in einem Verzeichnis aufweist, einschließlich Informationen darüber, wann und durch wen die Tests erzeugt wurden) in jedem Testverzeichnis durch die Inhalte von string.
-t test_dir
Die -t-Option liefert ein Mittel zum Benennen des Verzeichnisses, in dem erzeugte Testdateien gespeichert werden. Das Voreinstellungstestverzeichnis ist das aktuelle Verzeichnis.
-v Die weitschweifige Option -v bewirkt, dass der Name jeder Testdatei in stdout geschrieben wird, wenn der Test erzeugt wird.
-w Wenn die -w-Option verwendet wird, drucken GDMO-Warnungen nicht.
-x721
Wenn dieselbe verwendet wird, ist eine volle Version des ITU-T X.721-Standards bei der GDMO-Eingabe enthalten.
-y Diese Option unterdrückt das Drucken von nicht aufgelösten GDMO-Referenzen.
Nachdem der ovatgen-Befehl ausgegeben worden ist, und falls die -c-Option nicht verwendet wird, analysiert das ovatgen-Modul 1) Befehlszeilenoptionen syntaktisch und 2) erzeugt eine Datei 106 (1), die eine Liste von erweiterten regelmäßigen Ausdrücken aufweist, die auf alle MOCs verweist, die durch die -M-, -m-, -P- und -p-Optionen spezifiziert sind. Bei einer bevorzugten Implementierung weisen alle Listendateien (einschließlich der erzeugten Listendatei und der Listendateien, die durch die -m- und -p- Optionen bestimmt sind) eine oder mehr Zeilen auf, die mit der folgenden Syntax konform sind:
[<documentName>:]<erweiterter regelmäßiger Ausdruck>
Erweiterte regelmäßige Ausdrücke sind in der allgemein verfügbaren Bibliothek UNIX regexp() definiert. Falls der optionale Dokumentname fehlt, werden alle Dokumente, die die GDMO-Eingabe 102 aufweisen, nach dem spezifizierten erweiterten regelmäßigen MOC-Ausdruck durchsucht. Erweiterte regelmäßige Ausdrücke müssen deshalb mit dem kompletten MOC-Namen vom Anfang bis zum Ende und nicht nur mit einer Teilzeichenfolge des MOC-Namens übereinstimmen. Das heißt, falls ein ^ am Anfang des gelieferten regelmäßigen Ausdrucks hinzugefügt wird und ein $ an seinem Ende hinzugefügt wird, müssen die enthaltenen Inhalte einen kompletten MOC-Namen aufweisen. Kommentarzeilen (diejenigen, die mit einem # beginnen) und leere Zeilen in einer Listendatei werden ignoriert.
Das ovatgen-Modul analysiert dann syntaktisch die Dokumentnamendatei, die der -f-Option folgt, und ruft ansprechend auf jede .mib-Datei (d. h. GDMO-Dokument), die in der Dokumentnamendatei aufgelistet ist, ovgdmoparse (ein HP-OpenView-Programm, das GDMO-Textdateien zu .md-Metadatendateien kompiliert, wie es in „HP OpenView Integration Series Distributed Management Developer's Reference for HP 9000 Series and Sun Systems", S. 1–7–1–11 beschrieben ist) und ovmdt (ein HP-OpenView-Werkzeug, das .md-Dateien zu .per-Dateien umwandelt) auf. Es sei darauf hingewiesen, dass eine .per-Datei eine Datei von kompilierten Daten ist, die ASN.1-Datentypen beschreibt.
Die -f-Option ermöglicht, dass jedem von mehreren GDMO-Dokumenten 102 ein Name zugewiesen wird und zusammen verarbeitet wird, um einen Satz von Tests 110 zu erzeugen. Die Dokumentnamendatei weist bevorzugt einen oder mehr Einträge (einen Eintrag für jedes GDMO-Dokument) der folgenden Syntax auf:
DOCUMENT NAME „GDMO-Dokumentname"
OM_PACKAGE FILE Dateiname
GDMO_FILES Dateiname (Dateiname ...)
END
Die OM_PACKAGE_FILE-Zeile ist optional und ist nur zur Kompatibilität mit dem HP OpenView Managed Object Toolkit (Verwaltetes-Objekt-Toolkit) (speziell das Programm mit dem Titel ovmotccgen, das einen C++-Code von einem GDMO-Dokument erzeugt) enthalten. Die Zeile wird durch das ovatgen-Modul ignoriert.
Nachdem das ovatgen-Modul die obigen Operationen abgeschlossen hat, ruft dasselbe das ausführbare atgen-Modul auf. Ein bevorzugter Codefluss für das atgen-Ausführelement ist in den 5 und 6 veranschaulicht und beginnt mit der Überschrift main.
Auf ein Starten des atgen-Ausführelements hin werden ovatgen-Befehlszeilenoptionen erneut syntaktisch analysiert, und OVmdLoadMDFile (eine HP-OpenView-Routine, Id. bei 1–210 –1–214) wird aufgerufen, um .md-Dateien in den Speicher zu laden. Danach wird OVmdGenNameTree (eine weitere HP-OpenView-Routine, Id. bei 1–192–1–193) aufgerufen, um einen Benennungsbaum von den geladenen .md-Dateien zu erzeugen (der hier bisweilen als ein OVmd-Bennungsbaum bezeichnet wird). Es sei erneut darauf hingewiesen, dass ein Benennungsbaum 400 (4) die möglichen Beziehungen von MOCs darstellt, jedoch eventuell nicht die tatsächlichen Namen von MOCs darstellt, da derselbe keine MOCs umfasst, die in einer UND-UNTERKLASSEN-Klausel aufgelistet sind.
Das atgen-Modul führt zwei zusätzliche Aufgaben durch, die das Herzstück der Testerzeugungsmaschine 108 aufweisen.
Zuerst erstellt dasselbe eine interne Darstellung eines Enthaltenseinsbaums eines TMN-Agenten (der im Folgenden als ein „interner CT-Baum" 700 bezeichnet wird, 7). Zweitens erzeugt und speichert dasselbe Netzwerkagententests 110 in einer Verzeichnisstruktur (bevorzugt einer UNIX-Verzeichnisstruktur), die die Struktur von sowohl dem internen CT-Baum 700 als auch des Laufzeitenthaltenseinsbaums 228 eines Agenten (2) spiegelt.
Allgemein weist ein interner CT-Baum 700 eine Anzahl von verbundenen Knoten 702–710 auf, wobei jeder Knoten Zeiger zu anderen Knoten eines internen CT-Baums 700 aufweist. Ein Tochterzeiger zeigt auf die erste der Töchter eines Knotens, ein Schwesternzeiger zeigt auf die nächste der Schwestern eines Knotens, und ein Mutterfeld zeigt auf die Mutter eines Knotens. Ein exemplarischer interner CT-Baum ist in 7 gezeigt. Der Ursprungsknoten 710 des internen CT-Baums 700 ist der Voreinstellungsknoten ct_root. Unter ct_root 710 befinden sich verschiedene „Separatbenennungsbaum"-Knoten (z. B. „Wurzel" 706 oder „System" 708). Unter den „Benennungsbaum"-Knoten 706, 708 befinden sich verschiedene Ebenen von Knoten 702, 704, die auf tatsächliche zu erzeugende MOCs verweisen (die MOCs aufweisen können, die in einer UND-UNTERKLASSEN-Klausel aufgelistet sind). Datenzeiger, die in jedem der Knoten eines Baums gespeichert sind, zeigen auf OVmdTreeNodes (HP-OpenView-Datenstrukturen, die Knoten des Benennungsbaums aufweisen, der durch OVmdGenNameTree erzeugt wird) für MOC-Name, Namenverbindung, Verzeichnisname, Kennzeichnungsattribut und Kennzeichnungsattributwert. Eine bevorzugte C++-Struktur für einen Intern-CT-Baum-Knoten ist in den 8–11 veranschaulicht.
Das atgen-Modul erstellt einen internen CT-Baum 700 auf eine von zwei Weisen – entweder aus einer Benutzereingabe-CT-Spez-Datei 104 (was realistische Informationen bezüglich der Form und der Struktur eines Laufzeitenthaltenseinsbaums 228 eines Agenten liefert) oder ganz neu (nur unter Verwen dung von .md-Dateien und des Benennungsbaums, der daraus erzeugt wird).
A. Erstellen eines internen CT-Baums aus einer CT-Spez-Datei
Ein bevorzugter C++-Programmfluss zum Erstellen eines internen CT-Baums 700 aus einer CT-Spez-Datei 104 ist in 5 veranschaulicht. Der Code weist verschiedene Funktionen auf, die zusammen die Routine build_ct_from_file aufweisen. Die Routine wird gestartet, wenn der ovatgen-Befehl mit der -c-Option ausgegeben wird.
Eine CT-Spez-Datei 104 liefert realistische Informationen bezüglich der Form und der Struktur des Laufzeitenthaltenseinsbaums 228 eines Agenten. Zu diesem Zweck kann eine CT-Spez-Datei 104 Text in Gliederungsform mit folgendem Format aufweisen:
root
> mocA
> > mocA1
> > mocA2
> mocB
Bei dieser Minimalkonfiguration sind zwei MOCs der Wurzel untergeordnet (mocA und mocB), und zwei MOCs sind mocA untergeordnet (mocA1 und mocA2). Eine Unterordnung von MOCs (d. h. eine Verschachtelungsstufe bzw. -ebene) ist durch die Anzahl von nicht-alphanumerischen Schriftzeichen angezeigt, die einer Textzeile in der CT-Spez-Datei vorausgehen (z. B. > >). Obwohl die oben genannte CT-Spez-Datei 104 nur eine Gliederung von MOC-Namen aufweist (und diese Information ist obligatorisch), könnte eine Zeile der CT-Spez-Datei zusätzliche Informationen aufweisen, die in dem folgenden Format bereitgestellt sind:
[>] * MOC_name [(dir_name)] [attr_name] [= val]
wobei dir_name eine Verzeichnisabkürzung anzeigt, attr_name ein Kennzeichnungsattribut anzeigt, und val einen Anfangswert eines spezifizierten Kennzeichnungsattributs anzeigt. MOC_name und attr_name kann optional ein Dokumentname vorangehen, der von einem Schriftzeichen ,:’ gefolgt ist. Alle Felder außer MOC_name sind optional.
Falls bereitgestellt, wird die CT-Spez-Datei 104 Zeile für Zeile syntaktisch analysiert, und eine Routine wird aufgerufen, um die Namenverbindung zwischen untergeordneten und übergeordneten MOCs, die unmittelbar benachbarte Verschachtelungsebenen in der CT-Spez-Dateigliederung aufweisen, zu bestimmen. Falls eine richtige Namenverbindungsschablone identifiziert wird, werden Zeiger in die OVmd-Benennungsbaumstruktur nachgeschlagen und in einem entsprechenden Knoten des internen CT-Baums 700 aufgezeichnet. Die Zeiger umfassen: 1) einen Zeiger zu einem Kennzeichnungsattributbaumknoten, 2) einen Zeiger zu dem Anfangswert des Kennzeichnungsattributs und 3) einen Zeiger zu dem Namen eines Verzeichnisses, in dem Tests für eine bestimmte MOC-Instanz zu platzieren sind.
Die einzige Eingabe an build_ct_from_file ist ein Zeiger zu der CT-Spez-Datei 104, die durch die -c-Option von ovatgen spezifiziert ist, und die einzige Ausgabe von build_ct_from_file ist ein Zeiger zu dem internen CT-Baum 700, den dasselbe erzeugt.
Obwohl die Routine build_ct_from_file im Vorhergehenden allgemein beschrieben wurde, werden im Folgenden verschiedene Funktionen der Routine build_ct_from_file genauer beschrieben. Es sei darauf hingewiesen, dass die folgenden build_ct_from_file-Funktionen rekursiv ansprechend auf jede Zeile einer CT-Spez-Datei 104 aufgerufen werden.
Wenn begonnen wird, einen internen CT-Baum 700 zu erstellen, werden ein oder mehr Zeiger zu den kompilierten GDMO-Dokumenten, die in einen Speicher geladen sind, benötigt. Bevorzugt sind die GDMO-Dokumente in einer verbundenen Liste derart kompiliert, dass auf ein beliebiges Dokument zugegriffen werden kann, wenn ein erstes der Dokumente lokalisiert ist. Zu diesem Zweck ist eine Funktion (GetFirstDoc) zum Aufrufen durch OVmdTravTree bereitgestellt (OVmdTravTree ist eine HP-OpenView-Routine, die verbundene .md-Dateien durchläuft, die in einen Speicher geladen sind, Id. bei 1–223–1–225), und ein Zeiger zu dem ersten Dokument in der verbundenen Liste wird zurückgegeben. Bevorzugte Eingaben an die Funktion GetFirstDoc sind: handle – ein OVmdHandle-Kontext (ein HP-OpenView-Globalzeiger); node – ein Knoten, der durchlaufen wird; und docNode – Benutzerdaten.
Nach dem Erzeugen eines Zeigers zu den kompilierten GDMO-Dokumenten muss eine Funktion (join_lines) zum Lesen von Textzeilen, die eine CT-Spez-Datei 104 bilden (immer eine auf einmal) in einen Speicher (z. B. in einen Puffer) bereitgestellt werden. Bei der im Vorhergehenden offenbarten CT-Spez-Datei kann das Escape-Schriftzeichen ,\’ verwendet werden, um die Beschreibung einer MOC in einer nächsten Zeile der CT-Spez-Datei fortzusetzen. Falls ein derartiges Schriftzeichen am Ende einer CT-Spez-Datei-Zeile gefunden wird, wird das Schriftzeichen entfernt und eine zusätzliche Textzeile wird in den Puffer gelesen. Bei Erreichen des Endes einer Zeile, das kein Escape-Schriftzeichen ,\’ aufweist, wird die Programmsteuerung an die Routine build_ct_from_file zurückgegeben. Bevorzugte Eingaben an die Funktion join_lines sind: fd – der Name der zu lesenden CT-Spez-Datei 104; buf – ein Puffer, in den eine Zeile der CT-Spez-Datei 104 gelesen wird; line – eine zu lesende CT-Spez-Datei-Zeile; und size – die Anzahl von Bytes, die in buf verbleiben.
Nachdem eine erste Zeile der CT-Spez-Datei 104 eingelesen worden ist, teilt die Funktion build_node einen neuen Intern-CT-Baum-Knoten (z. B. 702) zu und bringt denselben an einer geeigneten Stelle an den internen CT-Baum 700 an. Die Funktion build_node erledigt dies durch ein Einlesen des Ebenen-Präfixes einer Zeile (d. h. die Anzahl von nicht-alphanumerischen Schriftzeichen, die einer Zeile vorausgehen, wie z. B. „> > >"). Das Ebenen-Präfix zeigt eine Ebenenzahl an, die zulässig 0..previous_level+1 sein kann. Falls die neue Ebene previous_level+1 ist, bringt build_node einen neuen Tochterknoten an den Knoten an, der die previous_level (vorhergehende Ebene) aufweist. Falls die neue Ebene <= der aktuellen Ebene ist, verkettet build_node so viele Ebenen in dem internen CT-Baum 700 und fügt einen neuen Schwesterknoten auf dieser Ebene hinzu. Eingaben an build_node umfassen: buf – eine Zeile der CT-Spez-Datei 104; line – eine Zeile, in die Fehlernachrichten geschrieben werden können; ct – ein Zeiger zu dem Intern-CT-Baum-Knoten (z. B. 706) der previous_level; level – eine Anzeige der aktuellen Intern-CT-Baum-Ebene; level_tail – ein Zeiger zu dem ersten nicht-alphanumerischen Schriftzeichen in buf; und skipping – ein Flag, das gesetzt wird, wenn eine nicht zulässige CT-Spez-Datei-Zeile aufgefunden wird (z. B. eine CT-Spez-Datei-Zeile, die in einer Ebene verschachtelt ist, die mehr als Eins größer ist als die vorhergehende Ebene). Das Auslass-Flag bleibt gesetzt, bis die Inhalte von buf eine zulässige Ebene anzeigen.
Dann analysiert die Funktion parse_doc die Inhalte des buf, die durch build_node assembliert sind, syntaktisch und sucht nach einem Dokumentnamen der Form {1 3 6} oder „Voreinstellungsdokument". Falls ein solcher gefunden wird, gibt die Funktion einen Zeiger zu dem Beginn der Dokumentnamenzeichenfolge zurück, und doc_tail wird gesetzt, um zu dem ersten Schriftzeichen zu zeigen, das der Dokumentnamenzeichenfolge folgt. Falls kein Dokumentname gefunden wird, wird eine NULL-Anzeige durch ein Setzen von doc_tail, um auf doc_start zu zeigen, zurückgegeben. Doc_start ist ein Zeiger, der bezeichnet, wo eine Dokumentnamenabtastung in buf begonnen werden soll. Fehlende Anführungszeichen, die einen Dokumentnamen umgeben, werden nicht geliefert, da dies zweideutig wäre. NLS-Mehrbyteschriftzeichen innerhalb der mit Anführungszeichen versehenen Form eines Dokumentnamens sind jedoch akzeptabel.
Die Funktion parse_moc tastet nun den buf, der durch build_node assembliert ist, beginnend an dem Punkt, der durch doc_tail bezeichnet ist, ab und gibt einen Zeiger zu dem Start eines MOC-Namens zurück. Leerraum bzw. Whitespace und/oder ein Schriftzeichen ,:’, die einem MOC-Namen vorausgehen, werden weg-abgetastet. Die zulässigen Schriftzeichen in einem MOC-Namen sind [A-Za-z0-9], ,-’ und ,/’, und das erste Schriftzeichen eines MOC-Namens muss ein alphabetisches Kleinschriftzeichen sein. Eingaben an diese Funktion sind: moc_start – ein Zeiger, der bezeichnet, wo eine MOC-Namenabtastung in buf beginnen soll (gleichwertig zu dem Zeiger doc_tail, der durch parse_doc zurückgegeben wird); und moc_tail – ein Argument, das gemacht wird, um zu dem ersten Schriftzeichen zu zeigen, das einem MOC-Namen folgt. Erneut wird eine NULL-Anzeige zurückgegeben, falls kein MOC-Name existiert.
An diesem Punkt kann die Funktion find_template aufgerufen werden. Find_template lokalisiert einen OVmd-Benennungsbaumknoten, der einer möglicherweise leeren Dokumentnamenzeichenfolge entspricht, und einen MOC-Namen (d. h. ein Schablonenetikett), und gibt dann einen Zeiger zu dem gefundenen Schablonenknoten zurück. Falls die Dokumentnamenzeichenfolge leer ist, werden alle verbundenen .md-Dokumente bevorzugt nach dem MOC-Namen durchsucht. Falls der gleiche MOC-Name in mehreren Dokumenten auftaucht, wird eine Warnung gedruckt, und das erste Dokument, das gefunden wird, wird zurückgegeben. Eingaben an find_template sind: doc_ptr – ein Zeiger zu dem ersten Dokumentbaumknoten (zurückgegeben durch GetFirstDoc); doc – eine Dokumentnamenzeichenfolge, entweder in OID-(Objekt- ID) oder Zeichenfolgenform; und templt – eine Schablonen-(MOC) Namenzeichenfolge. Falls keine Schablone gefunden wird, wird eine NULL-Anzeige zurückgegeben.
Nachdem eine Schablone für eine CT-Spez-Datei-Zeile lokalisiert worden ist, wird die Funktion pr_doc_name verwendet, um einen Dokumentnamen (entweder in Standard- oder in OID-Form) in einen Knoten des internen CT-Baums 700 zu drucken. Die Eingaben an pr_doc_name sind nur: fd – die Intern-CT-Baum-Datei, auf die zu drucken ist; und doc – der spezifische Knoten des internen CT-Baums, auf den zu drucken ist.
Die Funktion parse_abbrev wird nun aufgerufen, um nach einem optionalen CT-Spez-Datei-Feld zu suchen, das einen abgekürzten Verzeichnisnamen zur Speicherung von Tests eines Knotens spezifiziert. Die Abkürzung wird, falls vorhanden, durch die Klammern identifiziert, die dieselbe umgeben. Mehrbyte-NLS-Verzeichnisnamen sind zulässig. Eingaben an diese Funktion sind: buf – die CT-Spez-Datei-Zeile, die durch join_lines zurückgegeben wird; abbrev_start – ein Zeiger, der bezeichnet, wo eine Abkürzungsabtastung in buf begonnen werden soll (d. h. das erste Schriftzeichen, das einem MOC-Namen folgt); abbrev_tail – ein Zeiger zu dem ersten Schriftzeichen, das einer Abkürzung folgt (d. h. der erste Leerraum, der der rechten Klammer der Abkürzung folgt); und line – die Zeilenzahl einer aktuellen Fehlernachrichtzeile. Die Funktion gibt entweder einen Zeiger zu dem Beginn der Abkürzung zurück oder gibt eine NULL-Anzeige zurück, falls keine Abkürzung existiert.
Eine ähnliche Funktion, parse_attr, analysiert syntaktisch eine CT-Spez-Datei-Zeile nach einem Kennzeichnungsattributfeld. Falls ein Leerraum oder ein Schriftzeichen ,:’ das Kennzeichnungsattributfeld von einem vorhergehenden Dokumentnamen trennt, werden diese Schriftzeichen wegabgetastet. Falls ein Ende-der-Zeile- oder ,=’-Schriftzeichen aufgefunden wird, kann das optionale Kenn zeichnungsattributfeld als fehlend angenommen werden, und eine NULL-Anzeige kann zurückgegeben werden. Ansonsten wird ein Zeiger zu dem Beginn des Kennzeichnungsattributfelds zurückgegeben. Eingaben an parse_attr sind: attr_start – ein Zeiger, der bezeichnet, wo eine Attributabtastung in buf beginnen soll; und attr_tail – ein Zeiger zu dem ersten Schriftzeichen, das einem Attributfeld folgt.
Die Funktion parse_val durchsucht den Inhalt von buf nach einem Schriftzeichen ,=’. Falls dasselbe gefunden wird, wird alles, was folgt, als ein Kennzeichnungsattributwert identifiziert, und ein Zeiger zu dem Beginn desselben wird zurückgegeben. Der gefundene Wert wird in dem internen CT-Baum 700 gespeichert und in Testdateien geschrieben, immer wenn der Anfangswert eines Kennzeichnungsattributs beim Identifizieren eines MOI benötigt wird. Die einzige Eingabe an parse_val ist val_start, ein Zeiger, der bezeichnet, wo die Suche nach einem Schriftzeichen ,=’ in buf begonnen werden soll. Falls ein Wert nicht gefunden wird, wird eine NULL-Anzeige zurückgegeben.
Die nächste Funktion, die durch build_ct_from_file aufgerufen wird, ist locate_nb. Für jedes Paar von untergeordneten/übergeordneten MOC-Baumknoten (z. B. 702/706) in dem internen CT-Baum 700 wird eine Namenverbindungsschablone, die dieselben verbindet, lokalisiert. Falls UND-UNTERKLASSEN-Sätze in dem OVmd-Benennungsbaum existieren, kann die Schablone eine Namenverbindung sein, die eine Überklasse erwähnt (d. h. eine MOC, von der einer von dem Paar erbt). Um eine Namenverbindungsschablone zu lokalisieren, werden zwei Listen von Überklassen erstellt, eine für jede Eingangs-MOC. Nachdem die Listen von Überklassen erstellt worden sind, wird eine Namenverbindungsliste nach jedem Kreuzprodukt der Listen von Überklassen geprüft. Falls das Kennzeichnungsattribut der untergeordneten Klasse nicht NULL ist, dann wird eine Prüfung vorgenommen, um sicherzustellen, dass die ausgewählte Namenverbindung das Kennzeichnungsattribut der untergeordneten Klassen benennt.
Eine Alternative zu dem oben Genannten wäre, die Namenverbindungslisten auf jede der zwei MOCs hin zu prüfen und dann rekursiv locate_nb für die Kombinationen von jeder MOC und der ABGELEITET-VON-Liste der anderen aufzurufen. Dies führt jedoch zu einem redundanten Prüfen bei den Kreuzprodukten von Überklassen. Eingaben an diese Funktion sind: sup – die übergeordnete OVmdTreeNode-Klasse; sub – die untergeordnete OVmdTreeNode-Klasse; und attr – der OVmdTreeNode für das Kennzeichnungsattribut der untergeordneten Klassen (falls vorhanden). Die Funktion locate_nb gibt einen Zeiger zu dem OVmdTreeNode für die Namenverbindungsschablone zurück, die die aktuellen untergeordneten/übergeordneten MOC-Baumknoten verbindet.
Beim Lokalisieren einer Namenverbindung ruft locate_nb mehrere zusätzliche Funktionen auf. Die erste dieser zusätzlichen Funktionen ist nb_pair. Von einem Paar von MOC-Baumknoten (und einem möglichen Kennzeichnungsattribut) bestimmt locate_nb, ob es eine Namenverbindung gibt, die dieselben verbindet. Dies erfolgt durch ein Folgen der OVmdlist (eine HP-OpenView-Struktur) eines Benennens übergeordneter Klassen von der gegebenen untergeordneten MOC. Für jede dieser Klassen prüft dasselbe, 1) dass dieselbe mit der gewünschten übergeordneten Klasse übereinstimmt, 2) dass die Namenverbindung auf das gegebene Attribut verweist, falls vorhanden, und 3) dass, falls entweder das sup- oder das sub-Argument ein Vorgänger der ursprünglichen Klasse ist, die Namenverbindungsschablone dies mit der UND-UNTERKLASSEN-Klausel zulässt. Eingaben an diese Funktion sind: sup – ein Übergeordnete-Klasse-Baumknotenanwärter; require_sup – ein Flag, das gesetzt wird, falls die UND-UNTERKLASSEN-Klausel auf der übergeordneten Seite vorhanden sein muss; sub – ein Untergeordnete-Klasse-Baumknotenanwärter; require_sub – ein Flag, das gesetzt wird, falls die UND-UNTERKLASSEN-Klausel auf der untergeordneten Seite vorhanden sein muss; und attr – ein Kennzeichnungsattributbaumknoten. Falls das attr-Argument vorhanden ist, kann dasselbe verwendet werden, um zwischen mehreren Namenverbindungsschablonen, die die gleichen übergeordneten und untergeordneten Klassen verbinden, zu vereindeutigen.
Eine Subroutine von nb_pair ist cmp_label, die WAHR zurückgibt, falls Baum (ein OVmdTreeNode-Zeiger) und Etikett (ein OVmdTemplateLabel-Zeiger) sich auf die gleiche Schablone beziehen. Dies ist nur für GDMO-Schablonen beabsichtigt (die Baumknoten, deren Mutter ein Benennungsbaumknoten ist). Eine zusätzliche Eingabe an diese Funktion ist ctx, ein Behälterkontext, aus dem die Etikettreferenz vorgenommen wird. Falls der Baum- und der Etikettzeiger sich nicht auf die gleiche Schablone beziehen, gibt die Funktion FALSCH zurück.
Eine zweite Funktion, die durch locate_nb aufgerufen wird, ist mk_head. Diese Funktion teilt einen allgemeinen Listenkopf zu und gibt einen Zeiger zu demselben zurück.
Eine dritte Funktion, die durch locate_nb aufgerufen wird, ist add_super_list. Diese Funktion erstellt eine Liste von allen Überklassen (diejenigen, von denen die gegebene MOC ABGELEITET ist). Diese Liste kann verwendet werden, um mögliche Übereinstimmungen bei einer Namenverbindungsschablone zu lokalisieren, falls eine UND-UNTERKLASSEN-Klausel vorhanden ist. Funktionseingaben sind: list – die gen_list (allgemeine Liste), an die die Überklassen anzuhängen sind; und moc – der Baumknoten für die betreffende MOC.
Beim Erstellen einer Liste von Überklassen hängt eine Funktion append_list einen allgemeinen Knoten an die Liste an, wobei angenommen wird, dass jeder beliebige angehängte Knoten als sein erstes Element einen Zeiger zu dem nächsten Element in der Liste aufweist. Eingaben an append_list sind: gen_list – eine Liste, an die anzuhängen ist; und node – ein Knoten der Liste, an die anzuhängen ist. Eine Funktion label2tree verwendet ein Etikett OVmdTemplateLabel zusammen mit einem enthaltenden Dokumentkontext, um den referenzierten OVmdTreeNode zu lokalisieren. Eingaben an label2tree sind: doc – ein OVmdContainer-Kontext, in dem die Etikettreferenz auftaucht; label – ein OVmdTemplateLabel enthält einen Dokumentnamen und einen optionalen Dokumentnamen (in entweder OID- oder Zeichenfolgenform); und new_doc – der zurückgegebene OVmdContainer-Kontext des Dokuments, das die referenzierte Schablone enthält. Label2tree gibt einen Zeiger zu dem referenzierten OVmdTree-Node zurück.
Es sei darauf hingewiesen, dass add_super_list sich wiederholt selbst aufrufen kann, um zusätzliche Elemente zu der Liste von Überklassen hinzuzufügen.
Eine letzte Funktion, die durch locate_nb aufgerufen wird, ist free_gen_list. Diese Funktion macht lediglich die allgemeine Liste frei, die durch add_super_list erzeugt wurde. Der Listenkopf dient als eine Eingabe an diese Funktion, es sei jedoch darauf hingewiesen, dass der Listenkopf nicht frei gemacht wird.
Nachdem eine Namenverbindung lokalisiert worden ist, und falls eine optionale Verzeichnisnamenabkürzung für den aktuellen Intern-CT-Baum-Knoten (z. B. 702) bereitgestellt worden ist, wird ck_unique_abbrev aufgerufen, um zu bestimmen, ob sich der optionale Verzeichnisname von allen vorhergehenden Schwesterknoten unterscheidet. Eingaben an diese Funktion sind: new_name – die zu prüfende Verzeichnisnamenzeichenfolge; und node – ein aktueller Intern-CT-Baum-Knoten, dessen vorhergehende Schwestern auf new_name hin zu prüfen sind. Falls keine Übereinstimmung gefunden wird, wird WAHR zurückgegeben. Ansonsten wird FALSCH zurückgegeben.
Falls kein optionaler Verzeichnisname für einen Intern-CT-Baum-Knoten (z. B. 702) bereitgestellt ist, wird die Funktion moc_abbrev aufgerufen, um eine Heuristik anzuwenden, die einen MOC-Namen kürzt (falls dies durch ein o- mit_abbreviation-Flag zugelassen wird, das ansprechend darauf gesetzt wird, ob der ovatgen-Befehl mit der -a-Option ausgegeben wird). Die Abkürzungsheuristik beschränkt die Länge jedes MOC-Segments in einem Verzeichnisnamen, wo ein Segment von einem MOC-Namen abgeleitet ist und als eine Sequenz von alphanumerischen Kleinschriftzeichen definiert ist, die einem Großschriftzeichen oder „-" folgen. Falls sich der erzeugte Verzeichnisname nicht von allen anderen Verzeichnisnamen unterscheidet, werden fortlaufend größere Ganzzahlen an den Namen angehängt, bis bei einem bestimmten Punkt bestimmt wird, dass sich der Name von den Verzeichnisnamenabkürzungen aller Schwestern des Knotens unterscheidet. Die Funktion ck_unique_abbrev kann bei Bedarf wiederholt durch diese Funktion aufgerufen werden, um die Eindeutigkeit eines erzeugten Verzeichnisnamens zu bestimmen. Eingaben an diese Funktion sind: full_moc – eine Zeichenfolge, die einen vollen MOC-Namen darstellt; und node – der Intern-Enthaltenseinsbaumknoten für diese Instanz.
An diesem Punkt und falls die CT-Spez-Datei-Zeile keinen Wert für das Kennzeichnungsnamensattribut einer MOC geliefert hat, werden ein variabler Zeichenfolgenkopf (var_str) und ein Anfangspuffer durch die Funktion var_str_init zugeteilt, und ein Zeiger zu denselben wird zurückgegeben. Diese Struktur wird verwendet, um einen geeigneten Wert für ein Kennzeichnungsnamensattribut einer MOC zu erhalten.
Ein erster Schritt beim Bereitstellen eines Werts für ein Kennzeichnungsnamensattribut besteht darin, einen Zeiger zu dem OVmdTreeNode für die Typzuweisung zu erhalten, die einem Attribut zugeordnet ist. Dieser Schritt wird durch die Funktion get_attr_type erreicht, die als ihre Eingabe die Variable att aufweist, einen Zeiger zu einem Attribut-OVmdTreeNode.
Nachdem der Typ eines Kennzeichnungsattributnamens erhalten worden ist, kann der Wert des Kennzeichnungsattributnamens erzeugt werden. Die Erzeugung eines derartigen Werts wird durch die Funktion pr_tree_value gesteuert, die einen ASN.1-Voreinstellungswert erzeugt, der für das gegebene OVmdAsn1TypeAssign-Baumobjekt geeignet ist. Die Wertzeichenfolge wird an den Zeichenfolgenpuffer, der durch var_str_init zugeteilt ist, angehängt und wird durch ein Sammeln von Untertypspezifizierern in einer Liste erzeugt, die durch ein Aufrufen der Funktion pr_tree_val_list erzeugt wird. Nachdem die Wertzeichenfolge an den Zeichenfolgenpuffer angehängt worden ist, wird die Untertypliste frei gemacht. Eingaben an diese Funktion sind: p – ein Zeiger zu dem Zeichenfolgenpuffer, wo eine Wertzeichenfolge zu erzeugen ist; und asn – ein OVmdAsn1TypeAssign-Baumknoten, für den eine geeignete Wertzeichenfolge gewünscht ist.
Die Liste zum Sammeln von Untertypspezifizierern wird durch ein Zuteilen eines allgemeinen Listenkopfes über die Funktion mk_head und dann ein Zurückgeben eines Zeigers zu demselben erzeugt. Pr_tree_val_list, eine Routine, die pr_tree_value untergeordnet ist, erzeugt dann einen Zeichenfolgenwert, der für einen ASN.1-Typ geeignet ist. Pr_tree_val_list ist auch der rekursive Eingangspunkt für DefinedTypes, wo der Untertypenlistenerzeugungsprozess bereits läuft. Die Funktion prüft, ob es sich bei einem Baumknoten um eine geeignete Art handelt, extrahiert das Typ- und das Modulobjekt von dem Knoten und ruft dann pr_type_value auf. Eingaben an die Funktion sind: p – ein Zeiger zu dem var_str-Puffer, wo eine Wertzeichenfolge zu erzeugen ist; asn – ein OVmdAsn1TypeAssign-Baumknoten, für den eine geeignete Wertzeichenfolge gewünscht ist; subtypes – eine gen_list von Knoten, die zu dem UND von allen OVmdAsn1Subt-Spezifizierern zeigen, die bislang gesammelt sind.
Falls an einem beliebigen Punkt in dem rekursiven Erzeugungsprozess festgestellt wird, dass der allgemeine Zeichenfolgenpuffer zu klein ist, kann die Funktion var_str_append verwendet werden, um eine Zeichenfolge an den var_str-Puffer anzuhängen, was den Puffer erweitert, falls dies nötig ist. Eingaben an diese Funktion sind: str – ein var_str-Puffer; und suffix – der neue Zeichenfolgeninhalt, der an var_str anzuhängen ist.
Pr_type_value ist eine Funktion, die einen ASN.1-Voreinstellungswert erzeugt, der für ein gegebenes OVmdAsn1Type-Objekt und sein enthaltendes Modul geeignet ist. Die Funktion hängt dann die Wertzeichenfolge an einen gegebenen Zeichenfolgenpuffer an. Die Funktion untersucht auch Untertyplisten (falls vorhanden). Bei einfachen Typen druckt die Funktion einen Wert, der für diesen Typ geeignet ist. Zum Beispiel FALSCH für BOOLESCH, 0 für GANZZAHL, „" für Zeichenfolge. Bei erzeugten Typen ruft sich diese Funktion rekursiv für jedes Feld des erzeugten Typs selbst auf. Falls eine Untertypspezifikation vorhanden ist, versucht die Funktion, den Wert zulässig zu machen (dieselbe kann für GANZZAHL (–5..5) z. B. –5 schreiben, und für PrintableString (GRÖSSE(4)) kann dieselbe „xxxx" schreiben). Eingaben an diese Funktion sind: p – der var_str-Puffer, in den der Wert geschrieben werden soll; type – ein OVmdAsn1Type-Knoten, der den ASN.1-Typ beschreibt; und mod – der OVmdTreeNode für das Modul, das die Typdefinition enthält.
Ansprechend auf pr_type_value, druckt die Funktion pr_val_value den Wert einer OVmdAsn1Val-Struktur. Eingaben an diese Funktion sind: p – der var_str-Puffer, in den der Wert zu schreiben ist; val – ein Zeiger zu der OVmdAsn1Val-Struktur, die zu drucken ist; und mod – der OVmdTreeNode-Zeiger zu dem enthaltenden ASN.1-Modul. Die Funktion gibt WAHR zurück, falls ein Wert erfolgreich gedruckt ist. Falls nötig, ruft die Funktion var_str_n_append auf, um eine Zeichenfolge von höchstens n Schriftzeichen an den var_str-Puffer anzuhängen, in den dieselbe einen Wert schreibt. Der Zeichenfolgeninhalt, der angehängt werden soll, sollte mit Null enden, so dass die Funktion weiß, wann dieselbe aufhören soll, Schriftzeichen an den Puffer anzuhängen. Eingaben an die Funktion sind: str – der var_str-Puffer; suffix – neuer Zeichenfolgeninhalt, der an den var_str-Puffer anzuhängen ist; und n – die maximale Anzahl von Schriftzeichen, die bei dem Suffix zuzulassen sind.
Wenn dieselbe durch pr_type_value aufgerufen wird, gibt die Funktion query_asnl_int den Wert eines numerischen A5N.1-Werts zurück. Diese Routine wird verwendet, um die Werte in Untertypgebungskonstrukten zu interpretieren. Um z. B. einen ganzzahligen Wert in dem Bereich GANZZAHL (–5..5) zu bestimmen, ruft pr_type_value diese Routine auf, um die –5 zu extrahieren. Eingaben an diese Funktion sind: val – ein OVmdAsn1Val-Knoten des zu untersuchenden Werts; und mod – ein OVmdTreeNode des ASN.1-Moduls, das val enthält (diese Eingabe wird in dem Fall benötigt, dass val ein definierter Typ ist, wobei in diesem Fall ein Referenznachschlagen erfolgen muss).
Query_asn1_size ist eine Routine, die aufgerufen wird, um einen ganzzahligen Wert der Größe eines Untertyps zurückzugeben. Ein GRÖßE-Untertypspezifizierer zeigt zu einer OVmdAsn1Subt-Liste, die die möglichen ganzzahligen Werte definiert, die Elemente des GRÖßE-Satzes sind. Diese Funktion durchläuft die Liste und gibt den Wert des ersten Elements zurück, das für dieselbe sinnvoll ist. Eingaben an die Funktion sind: subt – ein Untertypspezifizierer, auf den durch ein Feld OVmd_SUBT_SIZE gezeigt wird; und mod – ein OVmdTreeNode für das Modul, das das Feld OVmd_SUBT_SIZE enthält.
Die Funktion include components kann nach Bedarf aufgerufen werden, um die InnerType-Untertypspezifizierer (d. h. MIT KOMPONENTEN ...) in einer Liste von Untertypen abzutasten, um zu bestimmen, ob ein bestimmtes Feld eines SATZES oder einer SEQUENZ aufgenommen werden sollte. Die Funktion erstellt eine parallele Liste von Wertspezifizierern von den InnerTypes und verwendet die Liste, um eine Werterzeugung zu führen, falls das Feld aufgenommen wird. Eingaben an diese Funktion sind: subtypes – eine gen_list von Untertypspezifizierern, die sich auf eine enthaltende Struktur beziehen; field – ein Zeichenfolgenetikett für ein betreffendes Feld; val – eine gen_list, an die diese Routine einen Wertspezifizierer anhängt, falls ein solcher in dem InnerType gefunden wird (z. B. {...Feld (4..10) VORHANDEN}). Falls ein SATZ- oder SEQUENZ-Feld in eine Werterzeugung aufzunehmen ist, gibt die Funktion WAHR zurück.
Die Funktion var_str_contents gibt den mit Null endenden Zeichenfolgeninhalt des var_str-Puffers zurück. Die einzige Eingabe an die Funktion ist str, ein Zeiger zu dem var_str-Puffer.
Nachdem var_str_contents den Inhalt von var_str zurückgegeben hat, macht die Funktion var_str_free den Raum frei, der var_str zugeteilt ist. Die einzige Eingabe an diese Funktion ist str, ein Zeiger zu dem zu frei zu machenden var_str-Puffer.
Falls ein Wert von einem zugelassenen „VON"-Alphabetuntertyp erzeugt werden muss, gibt die Funktion query_asn1_permit einen derartigen Wert zurück. Diese Funktion gibt jedoch nur SingleValue-Untertypspezifizierer zurück (ansonsten gibt dieselbe ,x’ zurück). Eingaben an query_asn1_permit sind: subt – ein Ovmd_SUBT_PERALPHA-Untertypspezifizierer; und mod – ein OVmdTreeNode des ASN.1-Moduls, das den Untertypspezifizierer umgibt.
Query_asn1_permit kann wiederum query_asn1_char aufrufen, um ein Schriftzeichen zurückzugeben, bei dem es sich um einen der OVmd_SUBT_SINGLE-Werte in einer zugelassenen Alphabetliste handelt (d. h. ein OVmd_VAL_CSTRING). Falls kein gültiges Schriftzeichen zurückgegeben werden kann, gibt die Funktion ,x’ zurück. Eingaben an die Funktion sind: val – eine OVmdAsn1Val-Wertliste; und mod – ein OVmdTreeNode des ASN.1-Moduls, das die Wertliste umgibt.
Die letzte Funktion, die durch build_ct_from_file aufgerufen wird, ist var_str_len, die die Länge eines var_str-Puffers zurückgibt, auf den durch das Eingangs-str gezeigt wird.
B. Erstellen eines internen CT-Baums von einer GDMO-Eingabe
Beim Erstellen eines internen CT-Baums 700 von einer GDMO-Eingabe 102 (d. h. GDMO-Dokumente) erstellt das atgen-Modul zuerst eine MOC-Auswahlliste 106 (d. h. diese Funktion wird durch die -m-, -M-, -p- und -P-Optionen zu dem ovatgen-Befehl ausgelöst). Die Funktion build_moc_sel_list öffnet deshalb eine Datei, die eine Liste von regelmäßigen Ausdrücken für MOCs enthält, die in diesen Erzeugungsprozess aufzunehmen sind. Jeder der regelmäßigen Ausdrücke wird gelesen, kompiliert und dann in einer globalen Liste mit dem Titel moc_selection_list gespeichert. Es sei darauf hingewiesen, dass, falls ein Dokumentname in den regelmäßigen Ausdruck aufgenommen wird und die OID-Form verwendet, es eine voll erweiterte numerische Form (z. B. {1 3 6 1 4 1 11}, nicht {oidPrefix 11}) sein sollte. Die einzige Eingabe an diese Funktion ist moc_file, der Name einer zu öffnenden Datei.
Die Funktion gen_re wird verwendet, um einen kompilierten regelmäßigen Ausdruck von einer Zeichenfolge zu erzeugen und einen kompilierten Knoten regex_t (siehe 8) zurückzugeben. Die einzige Eingabe, die von dieser Funktion benötigt wird, ist pat, ein zu kompilierender regelmäßiger Ausdruck.
Die Hauptschleife zum ganz neu Erstellen eines internen CT-Baums 700 (d. h. von OVmd-Benennungsbäumen und möglicherweise einer MOC-Auswahlliste) weist den Titel build_ct_from_md auf. Eine erste Routine, die in dieser Schleife aufgerufen wird, ist append_child_ct. Diese Routi ne hängt einen Tochterknoten (z. B. 706) an einen internen CT-Baum 700 an. Eingaben an diese Funktion sind: mom – ein Mutterknoten in einem internen CT-Baum 700 (möglicherweise ein Wurzelknoten, z. B. 710); und kid – ein neuer Tochterknoten (z. B. 706), der an mom anzuhängen ist.
Die Funktion append_md_subtree ist eine rekursive Routine, die OVmd-Benennungsbäume (d. h. diejenigen, die durch OVmdGenNameTree erzeugt werden) durchläuft und einen internen Enthaltenseinsbaum 700 erzeugt. Die Routine ist bei Tochterobjekten wirksam (weshalb es erforderlich ist, dass Verzeichnisse oberster Ebene (d. h. Benennungsbaumwurzeln 706, 708) unter einer Platzhalterwurzel 710 sind). Für jede MOC in einem Benennungsbaum gibt es einen OVmdNameNode, der zu allen möglichen übergeordneten und untergeordneten Klassen dieser MOC zeigt. Diese Routine folgt einer verbundenen Liste der untergeordneten Klassen und bringt für jede einen Unterbaum (d. h. einen Tochterknoten) an den internen CT-Baum 700 an. In jedem Unterbaum zeichnet die Routine einen MOC-Namen, eine Namenverbindung, ein Kennzeichnungsattribut, einen Voreinstellungsattributwert und eine Verzeichnisnamenabkürzung auf (siehe 8). Eingaben an diese Funktion sind: ct_parent – ein Mutterknoten in einem internen CT-Baum 700; md_parent – ein OVmdNameNode, der eine Liste aller Namenverbindungsbögen von der aktuellen MOC sowohl zu übergeordneten als auch zu untergeordneten Klassen enthält.
Include_moc ist eine Funktion, die für einen MOC-OVmdTreeNode bestimmt, ob die moc_selection_list 106 zulässt, dass derselbe in den Erzeugungsprozess aufgenommen wird. Die Funktion findet eine Dokument- und MOC-Etikettzeichenfolge für einen betreffenden Benennungsbaumknoten (z. B. 706) und durchsucht dann die globale moc_selection_list, wobei regexec (eine UNIX-Funktion) bei jedem kompilierten Ausdruck aufgerufen wird, um eine Übereinstimmung auszuwerten. Eine Eingabe an diese Funktion ist tree_moc, ein Zeiger zu einem OVmdTreeNode, der untersucht wird. Falls ein Intern-CT-Baum-Knoten für eine bestimmte MOC zu erzeugen ist, gibt die Funktion WAHR zurück. Ansonsten gibt dieselbe FALSCH zurück.
Include_moc kann wiederum empty_list aufrufen, eine Funktion, die lediglich prüft, ob die moc_selection_list 106 leer ist. Falls die Liste 106 leer ist, wird WAHR zurückgegeben, und alle MOCs in einem Benennungsbaum werden in einen erzeugten internen CT-Baum 700 aufgenommen.
Angenommen eine MOC ist in einen internen CT-Baum 700 aufzunehmen, dann wird die Funktion append_child_ct aufgerufen. Wie zuvor hängt diese Funktion einen neuen Tochterknoten (z. B. 702) an einen internen CT-Baum 700 an. Dieselbe bewegt sich auch kettenmäßig durch einen internen CT-Baum 700, um die letzte erzeugte Schwester eines neuen Tochterknotens zu finden, und erzeugt einen geeigneten Schwesternzeiger für einen Knoten. Außerdem wird ein Mutterzeiger erzeugt, der zurück zu dem Mutterknoten der neuen Tochter zeigt.
An diesem Punkt wird eine MOC-Abkürzung durch ein Anwenden einer Verkettungsheuristik erzeugt. Diese Funktion wird mit der Routine build_ct_from_file gemeinschaftlich verwendet.
Die Funktion gen_naming_string versucht nun, jegliche ANFANGSWERTE für ein Kennzeichnungsattribut einer MOC zu lokalisieren. Dies erfolgt durch ein kettenmäßiges Bewegen durch alle Pakete einer MOC und alle Attribute in jedem Paket, wobei nach dem einen gesucht wird, das damit übereinstimmt, was bereits als das Kennzeichnungsattribut einer MOC identifiziert worden ist (von einer Namenverbindungsschablone). Wenn das Attribut gefunden worden ist, wird seine Eigenschaftsliste untersucht, und falls eine geeignete ANFANGSWERT-Spezifikation vorliegt, wird der ANFANGSWERT anstelle eines Voreinstellungstypwerts verwendet. In den meisten Fällen gibt diese Funktion jedoch vor, gen_type_string für einen Attributbaumknoten aufzurufen.
Eingaben an diese Funktion sind: moc – ein Baumknoten für eine MOC; und att_node – ein Baumknoten eines Kennzeichnungsattributs für die MOC. Die Funktion gibt eine Zeichenfolge mit einem Wert zurück, der dem Kennzeichnungsattribut einer MOC zugewiesen wird.
Label2tree wird wie zuvor aufgerufen, um einen spezifischen Benennungsbaumknoten zu lokalisieren.
Die Funktion pr_valspec druckt eine ASN.1-Wertspezifikation in einen Zeichenfolgenpuffer. Die Funktion handhabt nur OVmdVALUE_REF-Varianten (d. h. OVmd_DERIVATION_RULE zeigt nur zu einer Verhaltensschablone). Eingaben an die Funktion sind: buf – ein Zeichenfolgenpuffer, in den zu schreiben ist; und doc – ein GDMO-Dokument, das eine geeignete Wertzuweisung enthält.
Die Funktion get_attr_type kann wie zuvor aufgerufen werden, um den Typ eines Kennzeichnungsattributs zu gewinnen.
Die Funktion gen_type_string teilt eine Zeichenfolge zu, die einen ASN.1-Wert enthält, der für eine ASN.1-Typzuweisung geeignet ist, die in dem gegebenen OVmdTreeNode vorgenommen wird, und gibt dieselbe zurück. Die einzige Funktionseingabe ist asn, ein OVmdAsn1TypeAssign-Baumknoten (eine HP-OpenView-Struktur), für den eine geeignete Wertzeichenfolge gewünscht wird.
Schließlich kann, falls ein Tochterunterbaum (z. B. 702) an einen internen CT-Baum 700 angehängt ist und durch eine Untersuchung der moc_selection_list 106 bestimmt wird, dass die MOC, die durch den Tochterunterbaum identifiziert ist, nicht in einen internen CT-Baum 700 aufgenommen werden soll, die Funktion delete_child_ct aufgerufen werden, um den Tochterunterbaum von dem internen CT-Baum 700 zu entfernen. Die einzige Eingabe an diese Funktion ist ein Zeiger zu dem zu entfernenden Knoten.
C. Erzeugen von Tests für Knoten eines internen CT-Baums
Nach dem Erstellen eines internen CT-Baums 700 (7) müssen Tests 110 (1) für jeden Knoten 702, 704 des Baums 700, der eine Tochter eines Benennungsbaumwurzelknotens 706, 708 ist, (d. h. für jedes verwaltete Objekt) erzeugt werden. Tests werden nicht für die Wurzel 710 des internen CT-Baums 700 (d. h. ct_root) oder Knoten 706, 708, die die Wurzeln verschiedener Benennungsbäume bilden, erzeugt. Die Knoten 702, 704, die Töchter eines Benennungsbaumwurzelknotens 706, 708 sind, sind Knoten, die eine untergeordnete Klasse bei einer Namenverbindung darstellen und ein Kennzeichnungsattribut aufweisen.
Wie im Folgenden beschrieben, werden die Tests 110 in einer Verzeichnisstruktur (bevorzugt UNIX-basiert) gespeichert, die sowohl den internen CT-Baum 700 als auch den Laufzeitenthaltenseinsbaum 228 eines Agenten (2) nachahmt. Es wird jedoch bevorzugt, dass Löschtests nicht in den Verzeichnissen gespeichert werden, die den internen CT-Baum 700 nachahmen, sondern stattdessen in einem gesonderten Verzeichnis gespeichert werden. Löschtests können deshalb an das Ende einer Teststapelliste 112 angehängt werden, die durch ein Durchlaufen der Knoten 710, 706, 702, 708, 704 eines internen CT-Baums 700 erzeugt wird. Auf diese Weise kann ein voll bestückter Enthaltenseinsbaum 228 vor dem Löschen von Elementen 220–224 des Enthaltenseinsbaums 228 erzeugt werden. Durch ein Speichern aller anderen Tests (d. h. alles außer den Löschtests) in einer Verzeichnisstruktur, die den Laufzeitenthaltenseinsbaum 228 eines Agenten spiegelt, können die Tests 110 (und nachfolgend ein Agent 212) logisch editiert und/oder bereinigt werden.
Während jeder Test erzeugt wird, wird sein Name in eine Testdateistapelliste 112 geschrieben. Auf diese Weise können die Tests 110 in einer richtigen Sequenz durch ein Aufrufen der Stapelliste 112 ausgeführt werden, ohne jedes Mal eine Stapelliste 112 kompilieren zu müssen, wenn die Tests 110 ausgeführt werden. Wie es im Folgenden genauer erläutert ist, können die Tests 110 auch in einem interaktiven Modus einer nach dem anderen ausgeführt werden.
In dem Flussdiagramm von 6 ist eine Funktion zum Erzeugen von Netzwerkagententests 110 mit gen_tests bezeichnet. Wenn dieselbe aufgerufen wird, durchläuft die Funktion zuerst einen internen CT-Baum 700 in Vorreihenfolge, wobei rekursiv die Funktion gen_subtree aufgerufen wird, um UNIX-Unterbäume zu erzeugen, die mit allen Tests außer Löschtests bestückt sind. Die Funktion durchläuft dann einen internen CT-Baum 700 in Nachreihenfolge, wobei Löschtests in einem separaten Löschverzeichnis ansprechend auf die Funktion gen_del_subtree erzeugt und gespeichert werden. Schließlich ruft die Funktion eine Funktion mit dem Titel gen_efd auf, um einen Ereignisweiterleitungsdiskriminator (EFD) zu erzeugen.
Ein globaler Name „Wegname" und ein globaler Zeiger „Testname" ermöglichen es, dass Verzeichnisse von „Wegname" und Dateien von „Testname" tief in einem rekursiven Erzeugungsprozess geöffnet und gedruckt werden. Anstatt wiederholt den „Wegname"- und den „Testname"-Zeiger zu leiten, ermöglicht das Leiten eines Endzeigers, dass jede Iteration durch einen Schwesterbaumdurchlauf einen neuen Verzeichnisnamen anhängt, ohne bei einem möglicherweise NLS-Wegnamen rückwärts nach einem vorangehenden „/"-Separator suchen zu müssen. Außerdem kann eine neue Komponente an das Ende eines Wegnamens angehängt werden, ohne den gesamten Namen nach einem Null-Abschlusselement abtasten zu müssen. Falls z. B. der Befehl:
ovatgen -t /users/pas/test_dir
ausgegeben würde, könnten sich der folgende Wegname und die folgenden Zeiger ergeben:
Per Konvention werden Verzeichnisnamen immer mit einer „/"-Endung geleitet, so dass Testerzeugungsfunktionen einen Testdateinamen an das Ende der „Wegname"-Zeichenfolge anhängen können. Eingaben an eine Testerzeugungsfunktion (gen_tests) können sein: test_dir – der oberste Name eines zu erzeugenden Testverzeichnisses;
batch_list_file – der Name einer Stapellistendatei 112, die die Namen von allen (oder ausgewählten) erzeugten Tests 110 aufweist; efd_name – der Name einer EFD-Erzeugungsanforderungsdatei; und ct – der Name der Wurzel 710 eines internen CT-Baums 700.
Bei dem Codefluss von 6 ist eine erste Funktion, die durch gen_tests aufgerufen wird, ckdir. Diese Funktion bestimmt, ob die globale Zeichenfolge „Wegname" den Namen eines gültigen Verzeichnisses aufweist, das einem gegebenen Intern-CT-Baum-Knoten (z. B. 702) entspricht. Falls ein gültiges Verzeichnis existiert und beschreibbar ist, gibt ckdir DIR_OK zurück. Falls kein gültiges Verzeichnis existiert, versucht chkdir, eines zu erzeugen und DIR_OK zurückzugeben. Falls kein gültiges Verzeichnis existiert und auch nicht erzeugt werden kann, gibt ckdir DIR_NOTMADE zurück. Falls ein Verzeichnis existiert, aber nicht beschreibbar ist, gibt ckdir DIR_READONLY zurück. Ckdir wird jedes Mal aufgerufen, wenn Tests für einen nächsten Knoten des internen CT-Baums 700 zu erzeugen sind.
Nachdem ckdir aufgerufen worden ist, wird die Funktion ckfile aufgerufen. Diese Funktion hängt eine „suffix"-Eingabe an die globale Zeichenfolge „Wegname" an dem Ort an, der durch eine „Ende"-Eingabe bezeichnet ist. Dann öffnet dieselbe die Datei und gibt ein Dateibeschreibungselement zurück. Die „End"-Eingabe zeigt zu dem aktuellen Ende von „Wegname". Die „suffix"-Eingabe weist allgemein die folgende Form auf:
file.req
Ckfile wird jedes Mal aufgerufen, wenn ein neuer Test zu erzeugen ist.
Gen_subtree ist die Haupttestgeneratorkoordinatorfunktion. Für jeden Knoten 702, 704 des durchlaufenen internen CT-Baums richtet dieser rekursive Aufruf die Datenstrukturen ein, die von jeder der Testerzeugungsfunktionen benötigt werden, und ruft dieselben dann auf. Die Datenstrukturen umfassen Listen von allen obligatorischen und bedingten Paketen, die in der Vererbungshierarchie der aktuellen MOC enthalten sind. Bedingte Pakete, die mit geeigneten #pragma OVMOT_COND_PKG"-Anweisungen (eine HP-Erweiterung der GDMO-Sprache, die einem Kompilierer oder einem anderen Werkzeug zusätzliche Anweisungen gibt) markiert sind, sind in der obligatorischen Paketliste enthalten. Von der obligatorischen Paketliste wird eine Liste von enthaltenen Attributen erzeugt. Diese Attributliste wird von Erzeugungsfunktionen verwendet, um die Ausgangsfelder attributeList und modificationList zu erzeugen. Eingaben an die Funktion gen_subtree umfassen: dir_tail – ein Zeiger zu dem Ende von „Wegname", wo individuelle Testnamen durch chkfile angehängt werden können, um einen voll gekennzeichneten Testnamen zu erzeugen; tree – ein Zeiger zu einem internen CT-Baum 700; und fdn – eine Liste von rdn_nodes, die einen voll gekennzeichneten Namen einer MOC aufweisen (d. h. eine Auszeichnung, wie ein bestimmter Punkt in einem internen CT-Baum 700 erreicht wurde).
Eine erste Funktion, die durch gen_subtree aufgerufen wird, ist build_pkg_lists. Diese Funktion erstellt Listen von allen obligatorischen und bedingten Paketen für eine MOC und ihre Überklassen. Eingaben an die Funktion build_pkg_lists umfassen: moc_tree – ein Zeiger zu einem OVmdTreeNode für eine betreffende MOC; pkgs – ein Kopf für eine Liste von zu erstellenden obligatorischen Paketen; und cond – ein Kopf für eine Liste von zu erstellenden bedingten Paketen.
Die Funktion cond_pkg_included wird durch build_pkg_lists aufgerufen und gibt WAHR zurück, falls das bedingte Paket, das durch „Etikett" (label) benannt ist, für eine aktuelle MOC aufgenommen werden soll. Das allgemeine Konzept, dem cond_pkg_included folgt, besteht darin, kein bedingtes Paket aufzunehmen, wenn keine unzweideutigen Anweisungen dasselbe aufnehmen (ein Nicht-Aufnehmen desselben bedeutet, dass sein Attribut und seine Modifizierungslisten in eine separate Datei geschrieben werden, anstatt in Standardtestdateien aufgenommen zu werden). Für das pragma-Argument pkg_label sind optionale Dokumentnamen zugelassen. Eingaben an diese Funktion umfassen: moc – ein OVmdTreeNode für die MOC, deren bedingte Pakete untersucht werden (die #pragmas sollten an diesen Knoten angebracht sein); und label – ein OVmdTemplateLabel für ein bedingtes Paket.
Cond_pkg_included ruft wiederum cmp_pkg_label auf. Diese Funktion vergleicht eine Zeichenfolge, die von einem #pragma-Text gekommen ist, mit dem OVmdTemplateLabel eines Pakets und gibt WAHR zurück, falls dieselben übereinstimmen. Falls in der #pragma-Zeichenfolge kein Dokumentname vorhanden ist, vergleicht dieselbe nur die Schablonenetiketten. Eingaben an die Funktion umfassen: name – ein Zeiger zu einer Zeichenfolge, die Folgendes enthält:
[„doc name"] | {OID}] : label
pkg – eine OVmdTemplateLabel-Form eines Paketnamens; und moc – ein MOC-Baumknoten, der eine Paketreferenz enthält (um beim Setzen des Kontexts zu helfen).
Die Funktion freeAsn1Val, die durch die Funktion cmp_pkg_label aufgerufen werden kann, macht eine ASN.1-Wertstruktur frei, die zugeteilt worden sein kann, um einen anfänglichen, zugelassenen oder benötigten Wert zu halten. Die Wertstruktur könnte etwas in der Art von „xxxx" halten, um eine Zeichenfolge von GRÖßE (4) anzuzeigen (d. h. eine Zeichenfolge, die genau 4 Schriftzeichen enthalten muss). Die einzige Eingabe an die Funktion ist list, ein OVmdAsn1Val-Zeiger (d. h. ein HP-OpenView-Zeiger zu einem ASN.1-Wert).
Eine zweite Funktion, die durch gen_subtree aufgerufen wird, ist build_attr_list. Diese Funktion nimmt eine Liste von Paketen und assembliert eine Liste von allen ihren enthaltenen Attributen. Die Eingaben der Funktion umfassen: attr_list – ein zu füllender Attributlistenkopf; und pkg_list – eine Liste von Paketen.
Ansprechend auf build_attr_list und einen Attributbaumknoten mit einer zugeordneten Eigenschaftsliste 1) erzeugt append_attr einen attr_list_node, 2) berechnet dieselbe die OID, den Hash-Wert und den Typ des attr_list_node, 3) prüft dieselbe, dass derselbe noch nicht an die Liste angehängt ist, und 4) hängt dieselbe, falls derselbe noch nicht angehängt ist, denselben an die Liste an. Eingaben an die Funktion append_attr sind: list – eine Liste von Attributen; attr_tree – ein OVmdTreeNode für ein Attribut; und property – eine Eigenschaftsliste, die einem Attribut zugeordnet ist.
Beim Anhängen eines Attributs an eine Attributliste wird find_attr_type aufgerufen, um die Typdefinition eines Attributs zurückzugeben (OVmdDefinedType von HP-OpenView). Die Funktion lokalisiert entweder die MIT-ATTRIBUT-SYNTAX-Referenz und gibt dieselbe zurück oder lokalisiert die Attributreferenz durch ABGELEITET-VON und gibt rekursiv ihren Typ zurück. Die Funktion platziert ein Flag in der Objektstruktur, um unendliche Schleifen zu vermeiden.
Eingaben an find_attr_type sind: doc – der GDMO-Dokumentkontext für einen Attributbaumknoten; und attr_tree – ein Attributbaumknoten.
Bevor Tests für einen Intern-CT-Baum-Knoten (z. B. 702) erzeugt werden, erzeugt die Funktion gen_info eine INFO-Datei für einen Knoten. Diese Datei enthält hilfreiche Informationen, wie z. B. wer einen Test wann erzeugt hat (oder eine alternative Nachricht, die durch die -s-Option des ovatgen-Befehls geliefert wird), den Namen einer MOC, das Kennzeichnungsattribut einer MOC und ihre Namenverbindung. Die Datei listet auch die Inhalte der obligatorischen und der bedingten Paketliste (OID und Etiketten) eines Knotens auf. Eine exemplarische INFO-Datei ist in 12 gezeigt. Eingaben an die Funktion gen_info sind: tail – ein Zeiger zu dem aktuellen Ende einer Wegnamenzeichenfolge; ct – ein Zeiger zu einem Intern-CT-Baum-Knoten; pkg_list – eine Liste aller obligatorischen Pakete für einen Knoten (einschließlich der geerbten); und cond_list – eine Liste aller bedingter Pakete für einen Knoten.
Eine Subroutine der Funktion gen_info ist pr_pkg_contents. Diese Routine druckt in eine Datei die Attribute, Attributgruppen, Aktionen und Mitteilungen jedes Pakets in einer Liste durch ein rekursives Aufrufen der Funktionen pr_attr_list, pr_atg_list, pr_act_list und pr_ntf_list. Eingaben an pr_pkg_contents sind: fd – eine Datei, die durch ckfile geöffnet wird, in die Informationen geschrieben werden; und list – eine Liste von Paketen.
Für jedes Attribut in einer OVmdAttributes-Liste druckt pr_attr_list die OID und das Etikett des Attributs (z. B. „{1 3 6 1 4 1 11 1001 2 9} – passwordRootName"). Eingaben an diese Funktion sind: fd – eine zu schreibende Datei; und pkg_doc – ein OVmd-GDMO-Dokument, das ein Paket enthält, das eine Attributliste enthält.
Auf ähnliche Weise druckt die Funktion pr_atg_list OIDs und Etiketten für Attributgruppen, die in einem Paket enthalten sind. Eingaben an diese Funktion sind: fd – eine zu schreibende Datei; pkg_doc – ein OVmd-GDMO-Dokument, das ein Paket enthält; und list – eine OVmdAttributeGroups-Liste von Attributgruppen.
Die Funktion pr_act_list druckt OIDs und Etiketten für Aktionen, die in einem Paket enthalten sind. Die Eingaben dieser Funktion sind deshalb: fd – eine zu schreibende Datei; pkg_doc – ein OVmd-GDMO-Dokument, das ein Paket enthält; und list – eine OVmdActions-Liste von Aktionen.
Schließlich druckt die Funktion pr_ntf_list OIDs und Etiketten für Mitteilungen, die in einem Paket enthalten sind. Eingaben an diese Funktion sind: fd – eine zu schreibende Datei; pkg_doc – ein OVmd-GDMO-Dokument, das das Paket enthält; und list – eine OVmdNotifications-Liste von Mitteilungen.
Nach dem Erzeugen einer INFO-Datei erzeugt die Funktion gen_create_test eine create.req-Datei, die einen CreateArgument-Test aufweist. Typische CreateArgument-Dateiinhalte sind in 13 gezeigt. Eingaben an diese Funktion sind: tail – ein Zeiger zu dem Ende von „Wegname" (wo ein create.req-Testname angehängt wird); moc – ein OVmdTreeNode, der einer MOC eines aktuellen Intern-CT-Baum-Knotens entspricht; nb – eine Namenverbindung für einen aktuellen Intern-CT-Baum-Knoten (die verwendet wird, um den Wert des nameBinding-Attributs einzufüllen); fdn – der FDN einer Objektinstanz; und attr_list – eine Liste von Attributen, die mit build_attr_list erstellt ist.
Die Funktion gen_create_test weist die Funktionen pr_moc_oid, pr_moi und pr_create_attr_list auf. Die erste dieser Funktionen, pr_moc_oid, druckt die OID-Zeichenfolge einer REGISTRIERT-ALS-Klausel einer MOC in die create.req-Datei. Eingaben an die Funktion sind: fd – eine create.req- Datei, in die geschrieben werden soll; und moc_node – ein OVmdTreeNode, der einer aktuellen Objektinstanz entspricht.
Die Funktion pr_moi druckt eine Verwaltetes-Objekt-Instanz-Klausel in eine create.req-Datei. Eingaben an pr_moi sind: fd – eine Datei, in die geschrieben werden soll; und fdn – ein zu schreibender voll gekennzeichneter Name (FDN) (eine Liste von RDNs).
Die Funktion pr_create_attr_list druckt eine CreateArgument attributeList in eine Datei, wobei das Kennzeichnungsattribut von der Liste weggelassen wird. Bekannte Werte werden dann für die Attribute ObjectClass und NameBinding, die von „oben" geerbt sind, eingefüllt. Eingaben an diese Funktion sind: fd – eine Datei, in die geschrieben werden soll; attr_head – eine Liste von Attributen in einer aktuellen Objektinstanz; moc – ein aktueller MOC-Baumknoten; nb – ein Namenverbindungsbaumknoten; und fdn – eine Liste von RDNs, die einen FDN bilden.
Die Funktion pr_create_attr_list ruft die Funktion pr_create_attr auf, um einen einzelnen Attributwert in eine Erzeugtest-attributeList zu drucken. Falls ein ANFANGSWERT in der Eigenschaftsliste vorliegt, wird dieser Wert gedruckt. Falls kein ANFANGSWERT existiert, wird ein VOREINSTELLUNGSWERT gedruckt (falls existent). Falls kein VOREINSTELLUNGSWERT existiert, wird ein BENÖTIGTER WERT gedruckt. Falls kein BENÖTIGTER WERT existiert, wird ein ZUGELASSENER WERT gedruckt. Ansonsten wird ein Voreinstellungswert eines geeigneten Typs gedruckt. Eingaben an die Funktion umfassen: fd – eine Datei, in die geschrieben werden soll; und attr_ptr – ein Zeiger zu einem einzelnen attr_list_node.
Die Funktion pr_deftype kann durch pr_create_attr aufgerufen werden, um einen Voreinstellungs-ASN.1-Typwert in einen Zeichenfolgenpuffer für eine Mod.Type-Stilreferenz zu schreiben. Dies erfolgt durch ein Finden einer geeigneten ASN.1-Typzuweisung in einem GDMO-Dokument und dann ein Schreiben eines geeigneten Werts für dieselbe. Eingaben an diese Funktion sind: buf – ein Zeichenfolgenpuffer, in den geschrieben werden soll; doc – ein GDMO-Dokument, das die ASN.1-Typzuweisung enthält, für die ein Voreinstellungswert benötigt wird; und deftype – eine Mod.Type-Referenz.
Falls ein Voreinstellungsattributwert durch pr_create_attr erzeugt werden muss, kann der Wert durch ein Aufrufen der Funktion pr_tree_value erzeugt werden. Diese Funktion wird gemeinschaftlich mit der Routine build_ct_from_file verwendet.
Eine letzte Funktion, die durch gen_create_test aufgerufen wird, ist smf_ntf. Diese Funktion prüft, um zu bestimmen, ob beliebige der Mitteilungen, die für eine MOC definiert sind, standardmäßige Systemverwaltungsfunktionsmitteilungen sind. Ist dies der Fall, wird WAHR zurückgegeben, so dass eine aufrufende Funktion einen „Paar"-Befehl zu der batch_list, die erzeugt wird, hinzufügen kann. Eingaben an diese Funktion sind: moc – ein Baumknoten einer MOC; und oid – eine OID-Zeichenfolge, mit der jede Mitteilung zu vergleichen ist.
Nachdem ein Erzeugtest erzeugt worden ist, wird ein Erhalttest über eine Funktion gen_get_test erzeugt. Falls ein list_flag gesetzt ist, wird eine attributeList, die die Attribute enthält, die ERHALTbar sind, aufgenommen. Falls das list_flag nicht gesetzt ist, wird die attributeList leer gelassen (was bedeutet, dass alle Attribute erhalten werden). Eine typische get.req-Testdatei ist in 14 gezeigt. Eingaben an diese Funktion können umfassen: tail – ein Zeiger zu dem Ende von „Wegname", bei dem ein get.req-Dateiname angehängt werden kann; moc – ein MOC-Baumknoten für eine aktuelle Objektinstanz; fdn – der FDN einer aktuellen Objektinstanz; attr_list – eine Liste aller Attribute, die in einer aktuellen Objektinstanz enthalten sind (falls list_flag gesetzt ist, wird diese Liste nach denjenigen Attributen abgetastet, bei denen es zugelassen ist, dass dieselben modifiziert werden); und list_flag – ein Flag, das es ermöglicht, dass eine attributeList nur geschrieben wird, wenn das Flag gesetzt ist.
Wie bei der Funktion gen_create_test ruft gen_get_test die Funktionen pr_moc_oid und pr_moi auf, um die OID und die Verwaltetes-Objekt-Instanz-Klausel eines verwalteten Objekts in eine Testdatei zu drucken.
Die Funktion gen_get_test ruft dann pr_get_attr_list auf, um eine Erhalttest-attributeList zu drucken (siehe z. B. 22), die jegliche modifizierbare Attribute umfasst, die vor kurzem in einem Setztest verändert worden wären. Eingaben an die Funktion sind: fd – eine Datei, in die geschrieben werden soll; attr_head – eine Liste von zu untersuchenden Attributen; inner_only – ein Flag, das, wenn dasselbe gesetzt ist (wie durch die Bedingtes-Paket-Funktionen), bewirkt, dass nur die Attributelemente und nicht die umgebende attributeIdList{}) gedruckt werden. Falls ERHALTbare Attribute gefunden werden, wird WAHR zurückgegeben. Ansonsten gibt die Funktion FALSCH zurück und ermöglicht, dass eine get.req-Testdatei für den aktuellen Intern-CT-Baum-Knoten entfernt wird.
Falls eine get.req-Testdatei entfernt werden soll, hängt die Funktion remove_test_file die Zeichenfolge „suffix" an einem Ort ,Ende’ in „Wegname" an und entfernt die identifizierte Datei, falls möglich. Eingaben an diese Funktion sind: tail – ein aktuelles Ende der globalen Zeichenfolge „Wegname"; und suffix – der Name einer Testdatei, die an „Wegname" anzuhängen ist.
Die Funktion gen_set_test erzeugt nun einen Setztest (SetArgument) für einen Intern-CT-Baum-Knoten. Eine typische set.req-Datei erscheint in 15. Falls keine modifizierbaren Attribute für eine MOC gefunden werden, wird die set.req-Testdatei entfernt. Funktionseingaben umfassen: tail – ein Zeiger zu dem Ende von „Wegname"; moc – ein MOC- Baumknoten für eine bestimmte Verwaltetes-Objekt-Instanz; fdn – der FDN einer Objektinstanz; und attr_list – eine Liste aller Attribute, die in einer Objektinstanz enthalten sind. Diese Attributliste wird nach denjenigen Attributen abgetastet, bei denen es zugelassen ist, dass dieselben modifiziert werden.
Erneut werden die Funktionen pr_moc_oid und pr_moi aufgerufen, um die OID und die Verwaltetes-Objekt-Instanz-Klausel eines verwalteten Objekts in eine Setztestdatei zu drucken. Danach wird pr_set_attr_list aufgerufen, um eine modificationList (siehe z. B. 20) in die Setztestdatei (15) zu drucken. Die zu modifizierenden Attribute werden von den Attributen der im Vorhergehenden erstellten Attributliste abgeleitet. Ein Attribut wird als modifizierbar betrachtet, wenn beliebige der Schlüsselwörter ERSETZEN, ERHALTEN-ERSETZEN, HINZUFÜGEN, ENTFERNEN oder HINZUFÜGEN-ENTFERNEN in seiner Paketeigenschaftsliste auftauchen, oder wenn ein MIT-VOREINSTELLUNG-ERSETZEN gegeben ist. Falls der Modifizierungstyp nicht ERSETZEN ist (wobei es sich um die Voreinstellung handelt), wird ein Modifizieroperator zu dem Attributausdruck einer modificationList hinzugefügt, wie es in 21 gezeigt ist. Eingaben an die Funktion pr_set_attr_list sind: fd – eine Datei, in die geschrieben werden soll; attr_head – eine Liste von zu untersuchenden Attributen; und inner_only – ein Flag, das, falls dasselbe gesetzt ist (d. h. durch einen Aufruf von der Paketerzeugungsroutine), bewirkt, dass die Zeichenfolge „modificationList" und ihre Schließklammer nicht in eine Setztestdatei aufgenommen werden. Falls das inner_only-Flag gesetzt ist, kann das „Listenfragment", das durch diese Funktion erzeugt wird, in eine bereits existierende Liste kopiert werden. Falls eine Gesetztes-Attribut-Liste erzeugt wird, wird WAHR zurückgegeben. Ansonsten wird FALSCH zurückgegeben, und ein Setztest für den aktuellen Knoten eines internen CT-Baums wird entfernt.
Nach dem Erzeugen eines Setztests wird erneut die Funktion smf_ntf aufgerufen, um zu bestimmen, ob jegliche der Mitteilungen, die für eine MOC definiert sind, standardmäßige Systemverwaltungsfunktionsmitteilungen sind. Ist dies der Fall, wird ein „Paar"-Befehl zu der Teststapelliste 112, die erzeugt wird, hinzugefügt.
Nachdem Erzeug-, Erhalt- und Setztests erzeugt worden sind, tastet gen_pkg_groups eine Liste von Paketen ab und ruft für jede gefundene Attributgruppe gen_grp_tests auf (d. h. alle Attribute, die durch set.req gesetzt wurden, werden nun erhalten). Ein Flag wird weitergeleitet, das anzeigt, ob ein Gruppenerhalttest zu der Teststapeldatei hinzugefügt werden soll. Eingaben an diese Funktion sind: tail – ein Zeiger zu dem Ende von „Wegname"; moc – ein MOC-Baumknoten für einen aktuellen Intern-CT-Baum-Knoten; fdn – der FDN einer aktuellen MOC-Instanz; pkgs – eine Liste von Paketen, die auf Attributgruppenzeiger hin abzutasten sind; und flag – ein Flag, das, falls dasselbe gesetzt ist, bewirkt, dass ein Gruppenerhalttest in eine Test-batch_list aufgenommen wird.
Gen_pkg_groups ruft gen_grp_tests auf, um die Tests grouplabel_get.req und grouplabel_set.req zu erzeugen. Falls ein geeignetes Flag gesetzt ist, wird der Attributgruppenerhalttest zu einer Teststapeldatei hinzugefügt. Es sei darauf hingewiesen, dass Attributgruppensetztests und Bedingtes-Paket-Tests bevorzugt nicht automatisch aufgerufen werden, da einige Agenten nicht in der Lage sind, eine Attributgruppe auf eine Voreinstellung zu setzen. Typische Attributgruppenerhalt- und -gruppensetztests erscheinen in den 16 und 17. Eingaben an diese Funktion sind die gleichen wie die Eingaben zu gen_pkg_groups.
Die Funktion gen_pkg_actions erzeugt nun einen Aktionstest. Der Test wird durch ein Abtasten einer Liste von Paketen und ein Aufrufen von gen_act_tests für jede gefundene Aktion erzeugt. Eingaben an diese Funktion sind: tail – ein Zeiger zu dem Ende von „Wegname"; moc – ein MOC-Baumknoten für einen aktuellen Intern-CT-Baum-Knoten; fdn – der FDN einer aktuellen MOC-Instanz; pkgs – eine Liste von Paketen, die nach Aktionszeigern abzutasten sind.
Gen_act_tests ist die Funktion, die tatsächlich eine Aktionstestdatei erzeugt. Eine typische Aktionstestdatei ist in 18 gezeigt. Eingaben an diese Funktion sind: tail – ein Zeiger zu dem Ende von „Wegname"; moc – ein MOC-Baumknoten für einen aktuellen Intern-CT-Baum-Knoten; und fdn – der FDN einer aktuellen MOC-Instanz.
Nach dem Erzeugen von Aktionstests werden Paketdateien über die Funktion gen_pkg_info erzeugt. Für jedes bedingte Paket in einer Paketliste wird eine modificationList und eine attributeList erzeugt, die in eine Setz- oder Erhalttestdatei kopiert werden kann. Eine typische Ausgabe ist in 19 gezeigt. Ein Komma, das einem Paketnamen in der Form eines ASN.1-Kommentars vorausgeht, ist geeignet, da die Listen konzipiert sind, um an eine existierende Liste angehängt zu werden (falls gewünscht). Eingaben an diese Funktion sind: tail – ein Zeiger zu dem Ende von „Wegname"; und pkgs – eine Liste von abzutastenden bedingten Paketen.
Die bereits beschriebenen Funktionen pr_set_attr_list und pr_get_attr_list werden verwendet, um eine modificationList (20) bzw. eine attributeList (22) für jedes bedingte Paket zu drucken, das durch gen_pkg_info gefunden wird.
Nachdem die oben genannten Tests und Dateien erzeugt worden sind, werden die Knoten der Attributliste zusammen mit der OID-Zeichenfolge, zu der jeder zeigt, über eine Funktion mit dem Titel free_attr_list frei gemacht. Die Paketlisten werden über free_gen_list frei gemacht, eine Funktion, die mit der Routine locate_nb gemeinschaftlich verwendet wird.
Nachdem ein erstes Unterverzeichnis von Tests erzeugt worden ist, wird gen_subtree ansprechend auf den nächsten Knoten eines internen CT-Baums 700 aufgerufen, usw. Eine Funktion mit dem Titel pop_list wird bereitgestellt, um den letzten Knoten (z. B. 704) eines internen CT-Baums 700, für den Tests erzeugt werden, zu entfernen und zurückzugeben. Da eine einfach verbundene allgemeine Liste von Intern-CT-Baum-Knoten 700–710 einen vorletzten „nächster"-Zeiger aktualisieren muss, bevor ein letzter Knoten in der Liste entfernt wird, muss entweder die gesamte Liste nach dem vorletzten Zeiger abgetastet werden oder der vorletzte Zeiger muss weitergeleitet werden. Da die meisten der Aufrufroutinen von gen_subtree einen Knoten anhängen, etwas Rekursives vornehmen und dann den Knoten, der angehängt wurde, entnehmen, ist es am einfachsten, einen Zeiger in dem früheren letzten Element zu speichern, bevor ein Knoten angehängt wird. Pop_list verwendet dann diesen gespeicherten Zeiger, um eine Listensuche zu vermeiden. Eingaben an diese Funktion sind: list – eine Liste von Intern-CT-Baum-Knoten 702–710, von der ein letzter Knoten entnommen wird; old_tail – ein Zeiger, der entweder zu dem neuen Ende einer Liste zeigt, falls das Element, zu dem derselbe zeigt, nicht NULL ist, oder der bewirkt, dass ein letztes Element einer Liste entnommen wird, falls derselbe zu einem NULL-Element zeigt.
Nachdem alle Tests und Dateien außer Löschtests erzeugt worden sind, wird eine MOC-Liste über die Funktion build_moc_list erstellt. Diese Funktion tastet einen internen CT-Baum 700 rekursiv ab und fügt einen moc_list_node zu einer moc_list hinzu, falls dieselbe noch keinen bestimmten Knoten des internen CT-Baums 700 durchlaufen hat. Ein Datenzeiger in einem moc_list_node zeigt direkt zu einem OVmdTreeNode, so dass Vergleiche bei Zeigerwerten vorgenommen werden können. Eingaben an diese Funktion sind: moc_list – ein allgemeiner Listenkopf einer zu erstellenden Liste; und node – ein Zeiger zu einem zu durchsuchenden internen CT-Baum 700.
Nach dem Erstellen einer MOC-Liste erzeugt eine Funktion mit dem Titel gen_del_subtree einen delete.req-Test für jeden Knoten 702, 704 eines internen CT-Baums 700. Die Tests werden durch ein Durchlaufen der Knoten eines internen CT-Baums 700 in Nachreihenfolge (d. h. von unten in einem internen CT-Baum nach oben) erzeugt. Eingaben an diese Funktion sind: dir_tail – ein Zeiger zu dem Ende von „Wegname"; tree – ein Zeiger zu dem Knoten eines internen CT-Baums, bei dem ein rekursiver Aufruf beginnen soll; und fdn – eine Liste von rdn_nodes, die den FDN aufweist, der einem aktuellen Knoten in einem internen CT-Baum vorausgeht.
Gen_del_subtree ruft gen_delete_test auf, um einen Löschtest für einen gegebenen Intern-CT-Baum-Knoten zu erzeugen (d. h. einen DeleteArgument-Test). Eine typische Löschtestdatei ist in 23 veranschaulicht. Eingaben an diese Funktion sind: tail – ein Zeiger zu dem Ende von „Wegname"; moc – ein MOC-Baumknoten für einen aktuellen Intern-CT-Baum-Knoten; und fdn – der FDN einer aktuellen MOC-Instanz.
Wie bereits im Vorhergehenden erfolgt, werden die Funktionen pr_moc_oid und pr_moi aufgerufen, um die OID und die Verwaltetes-Objekt-Instanz-Klausel eines verwalteten Objekts in eine Löschtestdatei zu drucken.
Schließlich wird ein Ereignisweiterleitungsdiskriminator (EFD) erzeugt. Die Funktion gen_efd erzeugt ein CreateRequest-Argument, das, wenn dasselbe zu ovead (einem HP-OpenView-Programm) gesendet wird, einen EFD erzeugt. Der EFD enthält ein Diskriminatorkonstrukt für Übereinstimmungen von „ObjectClass" mit beliebigen der OIDs von MOCs, die in dieser Testfolge erzeugt werden. Eine exemplarische EFD.req-Datei erscheint in 24. Eingaben an diese Funktion sind: fd – ein Dateibeschreibungselement, in das die EFD.req geschrieben werden soll; und moc_list – eine Liste von moc_list_node's für alle MOCs, die in der erzeugten Testfolge enthalten sind.
II. CT-Spez-Datei-Generator
A. Operation
Dieses Werkzeug 2500 (25) liest Eingangs-GDMO-Dateien 2502–2506 und schreibt in stdout eine Schablone einer CT-Spez-Datei 2510. Diese Datei 2510 kann dann über einen herkömmlichen Zeileneditor kundenspezifisch gemacht werden und als eine Eingabe an die bereits erwähnte Testerzeugungsmaschine 2512 verwendet werden. Siehe 25. Auf diese Weise verfügt ein Entwickler über eine genaue Steuerung des Testens seines oder ihres TMN-Agenten.
B. Struktur
Allgemein weist der CT-Spez-Datei-Generator 2500 zwei Module, ovatct 100 und atct 2508 auf. Ovatct 100 ist der Shell-Script-Treiber für das Ausführelement atct 2508.
Der CT-Spez-Datei-Generator kann durch ein Ausgeben eines Befehls der folgenden Syntax gestartet werden:
ovatct [-f file] [-m file] [-p file] [-M moc] [-P moc] [-x721] [-nox721] [-a] [-d] [-i] [-h] [-w] [-y] [gdmo.mib | gdmo.md...]
Die Befehlszeilenoptionen sind denjenigen von ovatgen ähnlich, mit Ausnahme von -a, -d und -i. Diese Optionen sind wie folgt definiert
-a Falls diese Option gegeben ist, sind Testverzeichnisnamenabkürzungsfelder nicht in der Ausgabe enthalten.
-d Falls diese Option gegeben ist, sind Kennzeichnungsattributfelder nicht in der Ausgabe enthalten.
-i Falls diese Option gegeben ist, sind Kennzeichnungsnamenattributanfangswerte nicht in der Ausgabe enthalten.
Nachdem der ovatct-Befehl ausgegeben worden ist, analysiert das ovatct-Modul 1) syntaktisch Befehlszeilenoptionen und 2) erzeugt eine Datei, die eine Liste von erweiterten regelmäßigen Ausdrücken aufweist, die auf alle MOCs verweisen, die durch die -M-, -m-, -P- und -p-Optionen 2514 spezifiziert sind.
Das ovatgen-Modul analysiert dann syntaktisch die Dokumentnamendatei (file), die der -f-Option folgt, und ruft ansprechend auf jede .mib-Datei, die in file aufgelistet ist, ovgdmoparse und ovmdt auf.
Nachdem das ovatct-Modul die oben genannten Operationen abgeschlossen hat, ruft dasselbe das ausführbare atct-Modul auf. Ein bevorzugter Codefluss für das atct-Ausführelement ist in 26 gegeben und beginnt mit der Überschrift main.
Nach dem Starten des atct-Ausführelements werden ovatct-Befehlszeilenoptionen erneut syntaktisch analysiert, und OVmdLoadMDFile wird aufgerufen, um .md-Dateien in einen Speicher zu laden. Danach wird OVmdGenNameTree aufgerufen, um einen Benennungsbaum basierend auf den geladenen .md-Dateien zu erzeugen. Es sei darauf hingewiesen, dass der Benennungsbaum die möglichen Namen von MOCs darstellt und nicht die Namen von spezifischen Verwaltetes-Objekt-Instanzen (und keine MOCs umfasst, die durch die UND-UNTERKLASSEN-Klausel bezeichnet sind).
Das atct-Modul führt drei zusätzliche Aufgaben aus, die das Herzstück des CT-Spez-Datei-Generators aufweisen. Zuerst erstellt dasselbe eine MOC-Auswahlliste (wie es durch die Testerzeugungsmaschine erfolgt). Zweitens erzeugt dasselbe einen internen CT-Baum 700 von dem erzeugten OVmd-Benennungsbaum und ansprechend auf die MOC-Auswahlliste (ähnlich dem, was durch die Testerzeugungsmaschine erfolgt, und unter Verwendung von gemeinschaftlich verwendeten C++-Codefunktionen). Drittens schreibt dasselbe eine CT-Spez-Datei 104 in eine Datei, die vor ihrer Eingabe in die Testerzeugungsmaschine 108 editiert werden kann. Die CT-Spez-Datei 104 weist eine Textgliederung auf, die die Struktur des Enthaltenseinsbaums 228 eines Agenten (2) spiegelt, wodurch dieselbe leicht zu verstehen und zu editieren wird.
Die verschiedenen C++-Funktionen, die die ersten beiden Aufgaben erledigen, werden gemeinschaftlich mit dem atgen-Modul verwendet, und ihre Beschreibung wird deshalb nicht wiederholt. Es sei jedoch darauf hingewiesen, dass die Aufrufreihenfolge für verschiedene Funktionen, die bei dem atgen-Modul verwendet wird, sich von der Aufrufreihenfolge von Funktionen bei dem atct-Modul unterscheidet, wie es in 26 veranschaulicht ist. Die Funktion OVmdGetNTRoot, die noch nicht erörtert worden ist, ist lediglich eine HP-OpenView-Routine, die die Wurzel eines Ovmd-Benennungsbaums findet (siehe „HP OpenView Integration Series Distributed Management Developer's Reference for HP 9000 Series and Sun Systems" bei 1–202–1–203).
Das Drucken eines internen CT-Baums 700 wandelt den Baum in eine CT-Spez-Datei 104 um. Das Drucken eines internen CT-Baums 700 wird durch die Routinen print_ct, print_ct_subtree und pr_tlabel erreicht. Print_ct handhabt das Drucken oberster Ebene eines internen CT-Baums 700 (d. h. das Drucken der Intern-CT-Baum-Knoten 706, 708 auf der „Benennungsbaum"-Ebene – der ct_root-Knoten wird nicht gedruckt). Ein Drucken oberster Ebene unterscheidet sich von dem Drucken, das durch print_ct_subtree durchgeführt wird, das das Drucken aller Unterbäume rekursiv handhabt (d. h. das Drucken der Intern-CT-Baum-Knoten 702, 704, für die später Tests erzeugt werden). Das Drucken von Knoten 706, 708 oberster Ebene muss anders gehandhabt werden, da die Benennungsbaumknoten 706, 708 als NULL-Zeiger zu einer MOC erscheinen und keine Kennzeichnungsattribute (oder Anfangswerte) aufweisen, da dieselben niemals als untergeordnete Klassen in einer Namenverbindungsschablone auftauchen.
Print_ct_subtree führt einen Präfix-Durchlauf des internen CT-Baums 700 durch, wobei die Inhalte jedes Knotens 702, 704 unterhalb der obersten Ebene ausgedruckt werden. Die Routine ruft sich selbst rekursiv für jede Tochter eines Knotens auf und führt dasselbe dann für alle Schwestern eines Knotens aus. Flags (die -a-, -d- und -i-Optionen zu ovatct) können verwendet werden, um zu steuern, ob jedes der optionalen Felder eines internen CT-Baums (Abkürzung, Kennzeichnungsattribut und Anfangswert) gedruckt wird.
Eingaben zu sowohl print_ct als auch print_ct_subtree sind: out – die Datei 104, in die ein interner CT-Baum 700 geschrieben wird (d. h. die CT-Spez-Datei 104); node – ein aktueller Knoten eines internen CT-Baums 700; und level – die Ebene eines internen CT-Baums 700, die durchlaufen wird.
Eine letzte Routine, die am Drucken eines internen CT-Baums 700 beteiligt ist, ist pr_tlabel. Diese Routine druckt einen vollen Schablonennamen in die CT-Spez-Datei 104 (d. h. den Dokumentnamen, falls vorhanden, und ein Schablonenetikett). Der Dokumentnamen kann entweder eine Standardzeichenfolge oder in OID-Form sein. Eingaben an diese Routine umfassen: fd – die Datei, in die der volle Schablonenname geschrieben wird; und tl – das zu druckende OVmd-TemplateLabel.
III. Testausführungsmaschine
A. Operation
Die Testausführungsmaschine 116 stützt sich auf die Vernetzungsmerkmale der im Handel erhältlichen OpenView Distributed Management Platform (Verteilte-Verwaltung-Plattform) von Hewlett-Packard (die auf der Maschine, von der TMN-Agententests 110 gesendet werden, installiert sein muss).
Tests 110 können entweder in einem interaktiven oder in einem Stapelmodus ausgeführt werden. Im Stapelmodus (nicht interaktiver Modus) wird die Reihenfolge und die Beschaffenheit von auszuführenden Tests durch eine Liste von Befehlen bestimmt, die in einer Teststapeldatei 112 (per Voreinstellung test_dir/batch_list) gegeben ist. Die Formate dieser Befehle sind in der folgenden Befehlsliste veranschaulicht.
test [post]
Hierbei handelt es sich um das reguläre Testformat, in dem eine einzelne Anforderung gesendet wird und eine einzelne Antwort erwartet wird. Der Dateiname, der die Anforderung enthält, wird durch ein Verbinden des test_dir-Präfixes, des Testwegs und eines „.Req"-Suffixes erstellt. Falls diese Datei nicht vorhanden ist, wird stattdessen der gleiche Dateiname mit einem Suffix „.req" gesendet. Die „.Req"-Dateien sollen manuell modifizierte Versionen der automatisch erzeugten „.req" sein, die nicht durch nachfolgende Aufrufe von ovatgen überschrieben werden. Die Bestätigung wird in der Datei result_dir/test.cnf gespeichert. Eine Erwartetes-Ergebnis-Datei für eine Bestätigung kann test_dir/test.exp genannt werden. Jegliche Mitteilungen, die vor der Bestätigung ankommen, werden in sequentiell nummerierten Dateien gespeichert (z. B. result_dir/events/0.ntf, result_dir/events/1.ntf, usw.).
# commen_t
Leerzeilen und diejenigen, die „#" als das erste Nicht-Leerstelle-Schriftzeichen aufweisen, können in Dokumenttestfälle aufgenommen werden. Sie werden durch die Testausführungsmaschine ignoriert.
! command
Dieser Befehl bewirkt, dass ein Teilprozess während einer Testfolgenausführung aufgerufen wird. Der ! – Befehl ist nützlich, um externe Ereignisse mit einem Agenten, der getestet wird, zu koordinieren. Zum Beispiel könnte ein Signal zu dem Agenten gesendet werden, das denselben veranlassen würde, eine Mitteilung zu senden.
event test [post]
Dieser Befehl bewirkt, dass die Testausführungsmaschine auf den Empfang einer Mitteilung wartet. Die empfangene Mitteilung wird in der Datei result_dir/test.ntf gespeichert. Eine Erwartetes-Ergebnis-Datei für eine Mitteilung kann test_dir/test.ntf_exp genannt werden. Jegliche ausstehenden Nachrichten, die nicht von dem Typ „EventReportArgument" sind, werden in einer Datei in result_dir/test.unk gespeichert, und eine Fehlernachricht wird in die Protokolldatei geschrieben. Falls das Ereignis in einem „bestätigten" Modus weitergeleitet wird, wird eine Bestätigungsdatei, die als test_dir/test.ack gespeichert ist, zurückgegeben.
invokeid n
Dieser Befehl bewirkt, dass eine nächste Anforderung mit einem Aufrufidentifizierer von n gesendet wird.
mode c[onfirmed]
Dieser Befehl bewirkt, dass nachfolgende Setzen-, Aktions- oder EventReport-Anforderungen in einem bestä tigten Modus gesendet werden. Der bestätigte Modus ist der Voreinstellungsmodus.
mode u[nconfirmed]
Dieser Befehl bewirkt, dass nachfolgende Setzen-, Aktions- oder EventReport-Anforderungen in einem nicht bestätigten Modus gesendet werden.
pair test[post]
Dieser Befehl sendet eine Testanforderung und wartet dann sowohl auf eine Bestätigungsantwort (die in result_dir/test.cnf gespeichert wird) als auch auf eine Mitteilung (die in result_dir/test.ntf gespeichert wird). Diese gepaarte Antwort ist typisch für ein Systemverwaltungsfunktion-1-Verhalten, bei dem M-ERZEUGEN-, M-SETZEN- und M-LÖSCHEN-Operationen sowohl zu einer Bestätigungsantwort als auch zu entweder einer Objekterzeugungs-, Attributwert-Geändert- oder Objektlöschungsmitteilung führen. Die Bestätigungs- und Mitteilungsdateien können mit Erwartetes-Ergebnis-Dateien verglichen werden, die als test_dir/test.exp bzw. test_dir/test.ntf_exp gespeichert sind.
receive test[post]
Dieser Befehl empfängt eine Bestätigung und speichert dieselbe in der Datei result_dir/test.cnf. Die entsprechende Erwartetes-Ergebnis-Datei ist test_dir/test.exp. Jegliche asynchronen Mitteilungen, die ankommen, während ovatrun auf eine Bestätigung wartet, werden wie regelmäßige Tests gespeichert.
sent_test
Dieser Befehl gibt eine Anforderung wie ein regelmäßiger Test aus, wartet jedoch nicht auf eine Antwort.
timeout n
Dieser Befehl setzt die Anzahl von Sekunden, die auf eine Antwort zu warten ist, bevor ein Test abgebrochen wird und eine Fehlernachricht in die Protokolldatei geschrieben wird.
Alle Befehle können unter Verwendung einer Testbefehlssprache (TCL) implementiert werden.
Nachdem alle Testbefehle ausgegeben worden sind und Antworten gespeichert worden sind, wird jede Zeile in einer Antwortdatei, die mit „currentTime" beginnt, entfernt. Aktuelle Ergebnisse 120 werden dann mit erwarteten Ergebnissen 124 (falls verfügbar) verglichen, und ein Zusammenfassungsbericht wird in einer Protokolldatei 126 hergestellt. Falls ein spezielles Nachverarbeiten erforderlich ist, wird das optionale Feld „post", das auf einen Testnamen folgend erscheint, anstelle der Voreinstellungsregeln eines „einfachen Vergleichs" aufgerufen.
B. Struktur
Allgemein weist die Testausführungsmaschine zwei Module, ovatrun und atrun, auf. Ovatrun ist der Shell-Script-Treiber für das Atrun-Ausführelement.
Die Testausführungsmaschine kann durch ein Ausgeben eines Befehls der vorliegenden Syntax gestartet werden:
ovatrun [-i] [-t test_dir] [-r result_dir] [-b batch_list] [-1 log] [-E efd] [-e env] [-s session] [-p per_dir] [-v] [-h] [-a]
Die Befehlszeilenoptionen sind ferner wie folgt definiert:
-a Per Voreinstellung wird eine Testausgabe entfernt, nachdem dieselbe mit erwarteten Werten verglichen wor den ist. Wenn die -a-Option gegeben ist, werden die Rohantwortdateien in einem Archiv zurückgehalten.
-b batch_list
Die -b-Option kann verwendet werden, um eine alternative Stapellistendatei zu benennen, von der zu lesen ist, wenn Netzwerkagententests ausgeführt werden. Die Voreinstellungsstapellistendatei ist test_dir/batch_list. Diese -b-Option wird im interaktiven (-i-) Modus ignoriert.
-c
Diese Option ermöglicht eine manuelle Verbindungsverwaltung. Der Benutzer ist nun für das Senden der ACSE AARQ-Anforderung, der AARE-Freigeben- und der ABRT-Abbrechen-Verbindungsverwaltungsanforderungen zuständig.
-E efd
Die -e-Option benennt eine Datei (die Ereignisweiterleitungsdiskriminator- (EFD-) Datei), die zu dem Ereignisverwaltungssystem gesendet wird, bevor eine Testausführung beginnt. Die Datei ist eine Anforderung des Typs CreateRequest, die einen EFD einrichtet, um zu bewirken, dass geeignete Mitteilungen an das ausführbare atrun-Modul weitergeleitet werden.
-e env
Bevor eine Testausführung beginnt, wird die Umgebungsstartdatei, die durch diese Option benannt ist, durch die aktuelle Shell „angezapft". Dies liefert eine Möglichkeit, kundenspezifische Shell-Variablen zur Verwendung mit „!"-Shell-Escape-Befehlen zu setzen.
-h
Die -h-Option ist trivial und druckt lediglich eine Hilfe- (oder Verwendungs-) Nachricht.
-i
Die -i-Option bedeutet einen interaktiven Modus. Bei diesem Modus werden Testbefehle von stdin anstelle von der Stapellistendatei gelesen, und eine Ausgabe wird in stdout geschrieben. Kein Vergleich wird mit erwarteten Ergebnissen vorgenommen, noch werden Protokolldateien geschrieben. Ein Eingeben von ,q’, ,Q’, ,quit’ oder ,Quit’ beendet den interaktiven Modus.
-l log
Die Ergebnisse eines nicht interaktiven Testens werden in eine Protokolldatei geschrieben, die optional unter Verwendung der -l-Option spezifiziert sein kann. Falls diese Option nicht gegeben ist, wird die Protokolldatei in dem Verzeichnisprotokoll in dem Verzeichnis result_dir, das durch die -r-Option gegeben ist, geschrieben. Der Name der Protokolldatei wird aus dem Datum und der Zeit erzeugt, zu der ein ovatrun-Befehl ausgegeben wird. Falls die weitschweifige Option gegeben ist (-v, siehe unten), wird ein Zeitstempel in das Protokoll geschrieben, wenn jede Testanforderung gesendet wird, und eine verstrichene Zeit, die die Zeitverzögerung zwischen dem Senden einer Anforderung und dem Empfang einer Antwort anzeigt, wird aufgezeichnet. Nachdem alle Tests ausgegeben worden sind, werden die Antworten mit erwarteten Werten verglichen, und eine gedruckte BESTANDEN/FEHLGESCHLAGEN-Nachricht wird in das Protokoll gedruckt. Eine Zusammenfassung der Anzahl von ausgeführten, bestandenen und fehlgeschlagenen Tests kann von dem Protokoll gedruckt werden.
-p per_dir
Die -p-Option zeigt ein Dauerhaftigkeitsdateiverzeichnis an (d. h. ein Verzeichnis, das die kompilierten Definitionen der ASN.1-Typen enthält, die durch erzeugte Tests verwendet werden). Per Voreinstellung ist das Dauerhaftigkeitsdateiverzeichnis test_dir/per.
.Per-Dateien werden automatisch durch das Ovatgen-Werkzeug erzeugt.
-r result_dir
Die -r-Option zeigt ein Ergebnisverzeichnis an. Die Hierarchien dieses Verzeichnisses spiegeln die Hierarchien von test_dir und enthalten entsprechende Ausgangsdateien.
-s session
Die -s-Option benennt eine Datei, die die ASN.1-Definition der Sitzungspräsentationsadresse und des -titels enthält. Per Voreinstellung wird eine Kommunikationssitzung mit dem HP-OpenView-Postmaster eingerichtet, und das gesamte Nachrichtenleiten wird durch die Objektregistrierungsdienste in dem Postmaster-Daemon gehandhabt. Falls stattdessen eine direkte Verbindung zu einem spe4zifischen Agenten erforderlich ist, ermöglicht diese Option, diese Verbindung zu spezifizieren.
-t test_dir
Die -t-Option zeigt das Verzeichnis an, in dem erzeugte Testdateien gespeichert sind. Alle Testnamen in der batch_list sind durch diesen Verzeichnisnamen präfixiert. Dieses Verzeichnis ist auch der Voreinstellungsort der batch_list, der Efd.req-Dateien und des per-Datei-Verzeichnisses. Der Voreinstellungswert für test_dir ist das aktuelle Verzeichnis.
-v Die -v-Option ermöglicht, dass zusätzliche Informationen in die Protokolldatei geschrieben werden, wenn Tests ausgeführt werden. Zum Beispiel wird ein Zeitstempel in das Protokoll geschrieben, wenn jede Testanforderung gesendet wird, und eine verstrichene Zeit wird aufgezeichnet, die die Zeitverzögerung zwischen dem Senden einer Anforderung und dem Empfang einer Antwort anzeigt.
Nachdem der ovatrun-Befehl ausgegeben worden ist, analysiert das ovatrun-Modul Befehlszeilenoptionen syntaktisch. Falls die -i-Option nicht gefunden wird, wird der Inhalt der Datei test_dir/batch_list syntaktisch analysiert, und eine Verzeichnisstruktur zum Empfangen von Antwortdateien wird in result_dir erzeugt. Das ovatrun-Modul ruft dann das ausführbare atrun-Modul auf.
Ein bevorzugter Codefluss für das atrun-Ausführelement ist in 27 gegeben und beginnt mit der Überschrift main.
Nach einem Starten des atrun-Ausführelements werden Befehlszeilenoptionen erneut syntaktisch analysiert, und eine Anzahl von Startroutinen wird aufgerufen, bevor in die main_loop des atrun-Ausführelements eingetreten wird.
Eine erste der aufgerufenen Startroutinen ist find_root. Diese Routine wendet Heuristik an, um die Wurzel eines Testverzeichnisses (das per Voreinstellung test_dir ist) zu finden und zurückzugeben. In diesem Verzeichnis ist es wahrscheinlich, dass Startdateien gefunden werden. Falls ein Testverzeichnis mit der -t-Option spezifiziert ist, hat das Verzeichnis, das der -t-Option folgt, Vorrang, und die Anwendung von Heuristik wird vermieden. Ansonsten wird Heuristik angewendet, die von dem aktuellen Arbeitsverzeichnis nach oben sucht, bis ein Verzeichnis, das ein Unterverzeichnis enthält, das per heißt, gefunden wird. Die einzige Eingabe an diese Routine ist tst_dir, der Name des Testverzeichnisses (falls vorhanden), das der ovatrun-t-Option folgt.
Eine zweite Startroutine, die aufgerufen wird, ist load_per. Diese Routine lädt die Dauerhaftigkeitsdateien (.per-Dateien), die durch ovatgen erzeugt werden. Falls die -p-Option bei ovatrun gegeben ist, werden die Dateien in per_dir_name (das Verzeichnis, das durch das per_dir-Argument bezeichnet wird, das der -p-Option von ovatrun folgt) geöffnet. Falls die -p-Option nicht gegeben ist, wird ein Versuch unternommen, root_dir/per/gdmo.per zu öffnen (wobei root_dir die Wurzel des Testbaums ist, der durch find_root identifiziert ist). Als letztes Mittel werden Grundelemente von /usr/OV/gdmo.mibs/ovat.per (der HP-OpenView-Dauerhaftigkeitsdateigrundelementbibliothek) geladen.
Dauerhaftigkeitsdateien weisen kompilierte Definitionen von ASN.1-Typen auf und werden verwendet, um Anforderungen zu codieren (und Antworten zu decodieren), die über ein Telekommunikationsverwaltungsnetzwerk gesendet werden. Dauerhaftigkeitsdateien können von einer ASN.1-Definitionsbibliothek abgeleitet werden, wie z. B. der DTD-(Datentypverzeichnis-) Bibliothek, die einen Teil der im Handel erhältlichen HP OpenView Distributed Management Platform bildet, der ISODE- (International Standards Organization Developer's Environment – Entwicklerumgebung der internationalen Standardorganisation) Bibliothek oder einer ähnlichen Bibliothek. In 27 sind Funktionsaufrufe, die beim Zugreifen auf die Hewlett-Packard-DTD-Bibliothek verwendet werden, notiert.
Eine dritte Startroutine, die durch das atrun-Ausführelement aufgerufen wird, ist initialize_com. Diese Routine leitet eine BMP- (BER- (Grundcodierregeln) Verwaltungsprotokoll-) Bibliotheksverbindung ein durch ein optionales Codieren eines Sitzungsobjekts und ein Aufrufen von bmp_bind (eine BMP-Funktion, die eine Zuordnung zu einem zu testenden Agenten einrichtet). BMP-Funktionen sind in der „HP OpenView Integration Series Distributed Management Developer's Reference for HP 9000 Series and Sun Systems" bei S. 1–29–1–57 zusammengefasst. Die Routine initialize_com leitet auch das Array primitive US ein (für eine größere Effizienz beim Lokalisieren, welche Art von Grundelementen an bmp_send (eine weitere BMP-Funktion) weitergeleitet werden muss). Eingaben an die Funktion sind: root – die Testverzeichniswurzel, die durch find_root lokalisiert wird, bei der es sich um einen wahrscheinlichen Ort für das Voreinstellungssitzungsobjekt handelt; und session_option – das Argument, das der -s-Option von ovatrun folgt, das ein explizites zu codierendes Sitzungsobjekt benennt.
Eine letzte Startroutine, die durch das atrun-Modul aufgerufen wird, ist efd_startup. Diese Routine sendet eine Anforderung an den ovead-Agenten (ein HP-OpenView-Agent), um einen Ereignisweiterleitungsdiskriminator (EFD) zu erzeugen, so dass gewünschte Netzwerkereignisse an das atrun-Modul weitergeleitet werden. Falls gewünscht, kann der Ort einer EFD-Anforderungsdatei explizit mit der o-vatrun-E-Option gegeben werden. Falls jedoch der Ort einer spezifischen EFD-Anforderungsdatei nicht geliefert wird, wird ein Versuch unternommen, die Voreinstellungsdatei EFD.req (die in der Wurzel des Testverzeichnisses angeordnet ist) zu senden. Falls eine Anforderungsdatei gefunden wird, wird eine CreateResult-Bestätigung in result_dir/EFD.cnf gespeichert. Eingaben an diese Funktion sind: test_root – die Testverzeichniswurzel, die durch find_root lokalisiert wird, bei der es sich um einen wahrscheinlichen Ort für eine EFD-Datei handelt; und Efd_name – das Argument, das der -E-Option von ovatrun folgt, das eine explizite EFD-Datei benennt.
Nach dem Aufrufen der oben genannten Startroutinen tritt das atrun-Modul in seine main_loop ein. In der main_loop werden Befehle von der batch_list-Datei nacheinander gelesen, decodiert und an einen zu testenden Agenten abgegeben. Die einzige Eingabe an die main_loop ist test_file, der Name der batch_list-Datei 112, von der Befehle abgegeben werden.
Eine erste Funktion der main_loop ist get_line. Im Stapelmodus gibt diese Funktion einfach die nächste Befehlszeile von stdin zurück. Beim interaktiven Modus liest die Funktion eine Befehlszeile unter Verwendung eines ksh-artigen Historienpuffers und prüft auf einen Benutzereingabe- Beendenbefehl. Die Eingaben an diese Funktion sind: fd – ein Dateibeschreibungselement, das eine Datei anzeigt, von der zu lesen ist (im Stapelmodus); buf – ein Zeiger zu dem Puffer, in den eine neue Befehlszeile geschrieben wird; und maxlen – die Größe des Puffers, in den eine neue Befehlszeile geschrieben wird. Falls keine weiteren Befehle existieren, gibt die Funktion lediglich einen leeren Puffer (buf) zurück.
Die Funktion parse_test wird verwendet, um eine neue Befehlszeile syntaktisch zu analysieren und ihren entsprechenden Befehlscode zurückzugeben. Die Funktion setzt auch einen Zeiger (arg), um auf das erste Schriftzeichen einer Befehlszeile, das dem zurückgegebenen Befehl folgt, zu zeigen. Eingaben an diese Funktion sind: line – ein Zeiger zu der Befehlszeile, die syntaktisch zu analysieren ist; und arg – ein Zeiger zu dem Schriftzeichen in einer Zeile, das dem Befehl der Zeile folgt.
Die Funktion parse_args wird verwendet, um die Argumente eines Shell-Escape-Befehls (d. h. !) syntaktisch zu analysieren und ein Array von Argumentzeigern zur Verwendung durch den allgemein verfügbaren UNIX-Befehl exec() zu füllen. Die Funktion gehorcht Anführungszeichen zum Gruppieren von Mehrwortargumenten. Die einzige Eingabe an die Funktion ist args, eine Zeichenfolge, die mit Argumentzeigern zu füllen ist. Die Funktion gibt einen Zeiger zu dem gefüllten args-Array zurück.
Vor dem Senden eines Befehls oder dem Empfangen einer Antwort assembliert die Funktion build_name die Komponenten eines Eingangs- oder Ausgangsdateinamens aus den Eingaben „prefix", (eine Zeichenfolge, die vorne an einem Testnamen anzuhängen ist), „test" (ein Zeiger zu dem Beginn des Testnamens) und „suffix", eine Zeichenfolge, die an den Testnamen anzuhängen ist). Zum Beispiel wird diese Funktion vor dem Senden einer Testanforderung mit dem test_dir-Namen, einem Zeiger zu einem individuellen Testnamen und dem Suffix „.req" aufgerufen. Vor dem Empfangen einer Antwort wird diese Funktion mit dem result_dir-Namen, einem Zeiger zu einem individuellen Testnamen und dem Suffix „.cnf" aufgerufen. Der Testname wird durch die Funktion parse_test aus der batch_list-Datei extrahiert (d. h. auf denselben wird durch den arg-Zeiger gezeigt, der durch parse_test zurückgegeben wird). Falls jedoch ein extrahierter Testname mit einem „/" beginnt, wird derselbe als ein Absolutwegname behandelt und es wird kein Präfix hinzugefügt. Nach dem Assemblieren eines Dateinamens gibt die Funktion einen Zeiger zu dem erzeugten Namen zurück.
Tests werden über die Funktion send_file an einen Agenten gesendet. Diese Funktion sendet die nächste Testanforderung in einer req_fd-Datei, wobei req_fd ein Dateibeschreibungselement der zu sendenden Testanforderung ist (d. h. der Dateiname, der durch build_name erzeugt wird). Nach einem syntaktischen Analysieren eines Objekts in der req_fd-Datei, wird dasselbe zu einer BER-Zeichenfolge codiert und mit bmp_send() gesendet. Der Zeiger prim_ret wird gesetzt, um zu dem gesendeten Grundelement zu zeigen. Falls eine Anforderung erfolgreich gesendet wird, gibt die Funktion WAHR zurück.
Die Funktion peek_eof ist eine Subroutine von send_file, die in einer Anforderungsdatei vorausschaut, um zu sehen, ob etwas anderes als Leerraum oder ASN.1-Kommentare in der Anforderungsdatei verbleiben. Falls nichts außer Leerraum und/oder ASN.1-Kommentaren verbleibt, gibt die Funktion WAHR zurück (was ein Dateiende (EOF) signalisiert). Ansonsten gibt die Funktion FALSCH zurück. Die einzige Eingabe an die Funktion ist fd, das Dateibeschreibungselement der Datei, von der ASN.1-Anforderungen gelesen werden.
Eine Subroutine von peek_eof, isasnlcomment, schaut in einer Anforderungsdatei voraus, um zu sehen, ob einem ASN.1-Kommentar ein gültiges Token folgt, das eine neue Anforderung beginnt (wobei in diesem Fall DTD_parse, eine DTD-Bibliotheksfunktion, aufgerufen werden kann). Diese Vorausschau-Subroutine vermeidet das Setzen eines DTD_parse-Fehlerflags, wenn ein Kommentar an dem Ende einer Anforderungsdatei das Programm zu der Annahme führt, dass eine weitere Anforderung folgt, wenn dies tatsächlich nicht der Fall ist. Eingaben an diese Funktion sind: c – das aktuelle Vorausschau-Schriftzeichen; und fd – das Dateibeschreibungselement der Datei, aus der ASN.1-Anforderungen gelesen werden. Die Funktion gibt WAHR zurück, falls ein ASN.1-Kommentar „--" von einer Anforderung gefolgt ist, und gibt ansonsten FALSCH zurück.
Get primitive ist eine Subroutine von send_file, die eine BMP-Grundelementzahl zurückgibt, die dem ASN.1-Typ bei dem DTD-Objekt entspricht. Dieselbe führt eine lineare Durchsuchung des Arrays von Grundelementtypnamen unter Verwendung der DTD-Eindeutige-Zeichenfolge-Zeiger durch (so dass jeder Zeichenfolgenvergleich eine einfache Zeigerprüfung ist). Die einzige Eingabe an die Funktion ist dtd_req, das zu sendende DTD-Objekt. Falls dieselbe gefunden wird, gibt die Funktion eine Grundelementzahl zurück. Ansonsten gibt die Funktion eine –1 zurück.
Eine letzte Funktion der main_loop des atrun-Moduls ist receive_file. Diese Funktion empfängt eine Bestätigung, eine Mitteilung oder beides. Nicht-NULL-Dateibeschreibungselemente zeigen an, welcher Typ erwartet wird. Die Befehle REGELMÄSSIG, EMPFANGEN und PAAR setzen cnf_fd, in die Bestätigungs- und Aufrufnachrichten gesendet werden. EREIGNIS und PAAR setzen ntf_fd, in die Mitteilungen geschrieben werden. Unerwartete Nachrichten (eine Mitteilung, wenn nur eine Bestätigung erwartet wird, oder eine Bestätigung, wenn nur ein Ereignis erwartet wird) werden in sequentiell nummerierten Dateien in result_dir/event als /#.ntf bzw. /#.cnf gespeichert. Eingaben an diese Funktion sind: cnf_fd – die Bestätigungsdatei; ntf_fd – die Mitteilungsdatei; und ack_fd – eine Bestätigter-Modus-Antwortdatei.
Nachdem alle Befehle in einem Test gesendet worden sind, gibt das atrun-Ausführelement die Steuerung an das ovatrun-Modul zurück. An diesem Punkt, und falls dasselbe im Stapelmodus läuft, vergleicht ovatrun Ergebnisse, die in result_dir gespeichert sind, mit erwarteten Ergebnissen, die in test_dir mit der Erweiterung .exp gespeichert sind.
IV. Erwartete-Ergebnisse-Installierer
Der Erwartete-Ergebnisse-Installierer speichert nur bekannt fehlerfreie Ergebnisdateien als Erwartetes-Ergebnis-Dateien. Auf diese Weise kann die Testausführungsmaschine die Ergebnisse von zusätzlichen Testläufen mit erwarteten Ergebnissen vergleichen.
Der Erwartete-Ergebnisse-Installierer kann durch ein Ausgeben eines Befehls der folgenden Syntax gestartet werden:
ovatexp [-f test_list] [-t test_dir] [-r results_dir]
Die Befehlszeilenoptionen sind ferner wie folgt definiert:
-f test_list
Die -b-Option spezifiziert eine Datei test_list, die die Namen aller auszuführenden Tests aufweist. Diese Liste steuert, welche Ergebnisdateien als Erwartetes-Ergebnis-Dateien gespeichert werden. Per Voreinstellung ist der Ort der test_list test_dir/batch_list.
-r results_dir
Die -r-Option spezifiziert ein Testergebnisverzeichnis, aus dem bekannt fehlerfreie Testergebnisse kopiert werden können.
-t test_dir
Die -t-Option spezifiziert ein Verzeichnis, in das bekannt fehlerfreie Testergebnisse kopiert werden können.
Bei der Verwendung werden Tests normalerweise in einem interaktiven Modus ausgeführt, so dass das Ergebnis jedes Tests, der an einen Agenten gesendet wird, individuell verifiziert werden kann. Nachdem alle Ergebnisse verifiziert worden sind, werden die Tests in einem Stapelmodus ausgeführt, und Ergebnisse werden in einem Ergebnisverzeichnis (result_dir) gespeichert. Diese Ergebnisse können dann unter Verwendung des ovatexp-Befehls in ein Verzeichnis von bekannt fehlerfreien Ergebnissen (test_dir) kopiert werden.
Die awk-Sprache wird verwendet, um test_list-Dateien syntaktisch zu analysieren und die Namen von Testdateien zu extrahieren (d. h. Leerzeilen und Kommentare werden ausgelassen, und entweder wird das erste Feld eines regelmäßigen Tests zurückgegeben oder das zweite Feld eines „Paar"-, „Empfangen"- oder „Ereignis"-Befehls wird zurückgegeben). Danach werden die Testnamen verwendet, um Quelldateien zu lokalisieren und Bestimmungsortdateinamen zu erzeugen (d. h..cnf → .exp und .ntf → .ntf_exp). Falls die erste Zeile einer Quelldatei einen gültigen CMIS-Antworttypnamen enthält (z. B. CreteResult, GetResult, ...), wird jede Zeile, die mit „currentTime" beginnt, entfernt, bevor die Datei in ihre entsprechende Bestimmungsortdatei kopiert wird. Falls die erste Zeile einer Quelldatei keinen gültigen CMIS-Antworttypnamen enthält, wird die Datei, wie sie ist, in ihre entsprechende Bestimmungsortdatei kopiert.
Durch das Löschen von „currentTime" schlägt ein Test nicht aufgrund von Differenzen bei Testausführungszeiten fehl. Diese Zeilen werden auch durch die Testausführungsmaschine ignoriert, wenn aktuelle Ergebnisse mit erwarteten Ergebnissen verglichen werden.
Obwohl veranschaulichende und derzeit bevorzugte Ausführungsbeispiele der Erfindung hier im Detail beschrieben worden sind, sei darauf hingewiesen, dass die erfindungsgemäßen Konzepte anderweitig verschiedenartig ausgeführt und verwendet werden können, und dass die angehängten Ansprüche so aufgefasst werden sollen, dass dieselben derartige Variationen umfassen, außer so weit dies durch den Stand der Technik eingeschränkt ist.

Claims

Vorrichtung zum Testen einer Funktionalität eines Telekommunikationsverwaltungsnetzwerkagenten außerhalb einer Laufzeitnetzwerkumgebung, wobei die Vorrichtung folgende Merkmale aufweist: a) ein oder mehr computerlesbare Speichermedien; und b) einen computerlesbaren Programmcode, der in den ein oder mehr computerlesbaren Speichermedien gespeichert ist, wobei der computerlesbare Programmcode folgende Merkmale aufweist: i) einen Code (100, 108) zum Erstellen eines internen Enthaltenseinsbaums (700), der einen Laufzeitenthaltenseinsbaum (228) des Telekommunikationsverwaltungsnetzwerkagenten spiegelt, wobei der interne Enthaltenseinsbaum eine Anzahl von Knoten (702, 704) aufweist, die verwalteten Objekten (220, 222) in dem Laufzeitenthaltenseinsbaum entsprechen; ii) einen Code (108) zum Erzeugen von Funktionstests (110), die jedem Knoten des internen Enthaltenseinsbaums entsprechen; und iii) einen Code (116) zum Ausführen der Tests über den Telekommunikationsverwaltungsnetzwerkagenten.
Vorrichtung gemäß Anspruch 1, bei der der Code (108) zum Erstellen eines internen Enthaltenseinsbaums (700) einen Code zum Erstellen eines internen Enthal tenseinsbaums ansprechend auf einen Namen einer Enthaltenseinsbaumspezifikationsdatei (104) aufweist, die in einer Testerzeugungsbefehlszeile bezeichnet ist.
Vorrichtung gemäß Anspruch 2, bei der der Code (108) zum Erstellen eines internen Enthaltenseinsbaums (700) ansprechend auf einen Namen einer Enthaltenseinsbaumspezifikationsdatei (104) konfiguriert ist, um eine Enthaltenseinsbaumspezifikationsdatei in Form einer Textgliederung zu lesen, wobei jede Textzeile, die die Gliederung aufweist: a) eine Instanz einer verwalteten Objektklasse identifiziert, die einen Teil des Laufzeitenthaltenseinsbaums (228) eines Agenten bilden soll; und b) mit ein oder mehr Schriftzeichen beginnt, die die Verschachtelungsstufe einer Instanz einer verwalteten Objektklasse in einem Laufzeitenthaltenseinsbaum eines Agenten anzeigen.
Vorrichtung gemäß Anspruch 3, bei der der Code (108) zum Erstellen eines internen Enthaltenseinsbaums (700) ansprechend auf einen Namen einer Enthaltenseinsbaumspezifikationsdatei (104) einen Code aufweist zum: a) syntaktischen Analysieren jeder Zeile der benannten Enthaltenseinsbaumspezifikationsdatei nach einem Namen einer verwalteten Objektklasse; b) Identifizieren jedes gefundenen Namens einer verwalteten Objektklasse als den Namen einer untergeordneten verwalteten Objektklasse; c) Verwenden der Verschachtelungsstufenanzeigen der benannten Enthaltenseinsbaumspezifikationsdatei, um den Namen einer verwalteten Objektklasse zu identifizieren, die einer untergeordneten verwalteten Objektklasse unmittelbar übergeordnet ist; und d) syntaktischen Analysieren von Dokumenten, die eine Telekommunikationsverwaltungsnetzwerkschnittstelle (218) aufweisen, um eine Namenverbindungsschablone zu lokalisieren, die entsprechende übergeordnete und untergeordnete verwaltete Objektklassen verbindet.
Vorrichtung gemäß Anspruch 4, bei der der Code zum Lokalisieren einer Namenverbindungsschablone einen Code aufweist zum: a) Erzeugen von Listen von Überklassen für entsprechende übergeordnete und untergeordnete verwaltete Objektklassen; und b) Identifizieren einer Namenverbindungsschablone, die die übergeordneten und untergeordneten verwalteten Objektklassen verbindet, wobei der Code zum Identifizieren einer Namenverbindungsschablone Kreuzprodukte von zwei entsprechenden Listen von Überklassen prüft.
Vorrichtung gemäß Anspruch 1, bei der: a) der Code (116) zum Erzeugen von Tests (110) eine Verzeichnisstruktur erzeugt, in der Tests gespeichert werden können; b) die Verzeichnisstruktur den Laufzeitenthaltenseinsbaum (228) des Telekommunikationsverwaltungsnetzwerkagenten spiegelt; und c) jedes Unterverzeichnis der Verzeichnisstruktur einem Knoten (702) des internen Enthaltenseinsbaums (700) entspricht.
Vorrichtung gemäß Anspruch 1, bei der der Knoten (116) zum Ausführen von Tests (110) eine Testbefehlssprache umfasst, die einen Shell-Escape-Mechanismus implementiert, wobei der Shell-Escape-Mechanismus eine externe Verarbeitung oder Synchronisation mit dem Telekommunikationsverwaltungsnetzwerkagenten (212) ermöglicht, wenn Tests ausgeführt werden.
Vorrichtung gemäß Anspruch 1, bei der der Code (116) zum Ausführen von Tests (110) eine Testbefehlssprache umfasst, die einen Paarbefehl implementiert, wobei der Paarbefehl eine Testanforderung sendet und dann sowohl auf eine Bestätigungsantwort als auch auf eine Mitteilung wartet.
Vorrichtung gemäß Anspruch 1, bei der der Code (108) zum Erzeugen von Tests (110) unabhängig von dem Code (116) zum Ausführen von Tests kompiliert ist, und der Code zum Ausführen von Tests durch eine Datenausgabe (110, 112) von dem Code zum Erzeugen von Tests getrieben wird.
Ein Computer-implementiertes Verfahren zum Testen einer Funktionalität eines Telekommunikationsverwaltungsnetzwerkagenten außerhalb einer Laufzeitnetzwerkumgebung, wobei das Verfahren folgende Schritte aufweist: a) Erstellen eines internen Enthaltenseinsbaums (700), der eine rechnergestützte Datenstruktur von verbundenen Knoten (702–710) aufweist, die verwalteten Objekten (220–224) des Laufzeitenthaltenseinsbaums (228) des Telekommunikationsver waltungsnetzwerkagenten entsprechen und dieselben spiegeln; b) Erzeugen von Funktionstests (110), die jedem Knoten (702, 704) des internen Enthaltenseinsbaums entsprechen; und c) Ausführen der Tests durch ein Codieren derselben und ein Senden derselben über einen Telekommunikationskanal (226) an den zu testenden Telekommunikationsverwaltungsnetzwerkagenten.