DE4310615A1

DE4310615A1 - Verfahren und Vorrichtung zur Bereitstellung eines vom Benutzer konfigurierbaren Systems, welches mehrere unterschiedliche Tasks und Softwaretools vereinigt und verwaltet

Info

Publication number: DE4310615A1
Application number: DE4310615A
Authority: DE
Inventors: James Carl Batch; Eileen Marie Burns-Brookens; Pavel Ivanov; Timothy Ivar Michel; Robert Allen Russell
Original assignee: Computervision Corp
Current assignee: Computervision Corp
Priority date: 1993-03-31
Filing date: 1993-03-31
Publication date: 1994-10-06
Anticipated expiration: 2013-04-01
Also published as: DE4310615C2

Description

Die vorliegende Erfindung betrifft Design- und Produktionsautomatisierungssysteme und insbesondere ein Verfahren und eine Vorrichtung zur Bereitstellung eines vom Benutzer konfigurierbaren Systems, welches mehrere unterschiedliche Softwaredesign- und Produktionstasks und -tools vereinigt und verwaltet, wobei zumindest einige dieser Tools ("Softwarewerkzeuge") nicht miteinander und mit dem System zum Vereinigen und Verwalten verträglich sein können.

Heutzutage werden Computer beim Design, der Produktionsvorbereitung, der Herstellung und bei der Untersuchung zahlreicher Erzeugnisse verwendet. Beispiele auf dem Gebiet der Elektronik umfassen integrierte Schaltungen, gedruckte Schaltungsplatinen, und Erzeugnisse, welche derartige Bauteile verwenden, einschließlich Computer, elektronische Haushaltsgeräte und dergleichen. Ähnliche Vorgehensweisen werden bei Erzeugnissen, wie beispielsweise Haushaltsgeräten, Kameras, Kraftfahrzeugen und dergleichen eingesetzt. Daher kann die rechtnergesteuerte Automatisierung des Designs, der Herstellung und der Untersuchung in jedem Industriezweig eingesetzt werden, in welchem mehrere Schritte bei der Schöpfung und Herstellung eines Enderzeugnisses nötig sind.

Typischerweise können mehrere unterschiedliche Ausrüstungsstücke dazu verwendet werden, die verschiedenen Design-Herstellungs- und Versuchsvorgänge durchzuführen, und der Benutzer kann entweder standardisierte oder speziell angepaßte Softwarepakete oder -tools haben, die er zur Durchführung der verschiedenen Funktionen verwendet. In vielen Fällen sind die Sprachen, juristischen Zeichenketten, Formate, die Syntax und andere Faktoren, die in den verschiedenen Softwaretools verwendet werden oder zur Kommunikation mit diesen eingesetzt werden, nicht vollständig kompatibel.

Heutzutage sind die Softwaretools getrennte Prozeduren, welche zur Erfassung, zur Überprüfung und zur Analyse der Leistung eines Designs während der Designphase verwendet werden, zur Darstellung des Designs während der Herstellungsentwurfsphase, zur Durchführung der verschiedenen Herstellungsschritte während der Herstellungsstufe und zur Untersuchung der verschiedenen Komponenten des Endprodukts während der Versuchsstufe. Die getrennten Prozeduren werden sequentiell verwendet, wobei die Ausgabe von einem Tool oder Prozeß die Eingabe für den folgenden Prozeß darstellt. Die häufigste Prozedur zur Verwendung dieser sequentiellen Prozesse besteht darin, darauf zu warten, daß ein Prozeß fertig ist, und einen darauffolgenden Prozeß mit der Ausgabe von dem vorherigen Prozeß durch die Verwendung einer Befehlssequenz zu betreiben, die an einer Tastatur oder einem anderen Eingabegerät eines oder mehrerer Bauteile des Systems eingegeben wird. Auf diese Weise legt der Benutzer unter Verwendung einer Terminalanzeige und einer Tastatur oder eines anderen Eingabegeräts die Folge der Vorgänge fest und stellt in vielen Fällen die ordnungsgemäße Übertragung erforderlicher Information von einem Prozeß zum nächsten sicher.

Diese getrennte Verwendung einzelner Prozesse kann für den Benutzer recht mühsam werden und es sind häufig zusätzliche Programme erforderlich, Übersetzer genannt, um ordnungsgemäß Datenausgaben von einem Prozeß auf einen anderen zu übertragen, infolge verschiedener Inkompatibilitäten zwischen den Programmen. Der Benutzer muß dazu fähig sein, mit den Prozessen in einer Standardbetriebssystemsprache zu kommunizieren, und muß ein klares Verständnis davon haben, wie die Eingaben und Ausgaben der verschiedenen Prozesse gesteuert werden.

Dies erfordert, daß sämtliche Benutzer des Systems den Betrieb des Gesamtsystems vollständig kennen sowie jedes der darin verwendeten Tools. Weiterhin erfordert dies, daß jedesmal dann, wenn in einem der Softwaretools eine Änderung erfolgt, beispielsweise um es zu aktualisieren und zu verbessern, oder in der Sprache oder den Prozeduren eine Änderung erfolgt, die von irgendeiner Komponente in dem System verwendet werden, sämtliche potentiellen Benutzer des Systems von der Änderung in Kenntnis gesetzt werden müssen, und diese verstehen müssen, um Bedienungsfehler zu verhindern und einen optimalen Betrieb des Systems sicherzustellen.

Zusätzlich ist bei existierenden Systemen selbst bei einem kenntnisreichen und erfahrenen Benutzer eine erhebliche Zeit dafür erforderlich, einen Task zu beenden, infolge der Anzahl getrennter, sequentieller Vorgänge, die erforderlich sind, und der Benutzer muß sorgfältig arbeiten, um sicherzustellen, daß der Task ordnungsgemäß beendet wird. Da der Benutzer wenig Führung bei der Durchführung von Betriebsabläufen haben kann, treten selbst bei dem sorgfältigsten Benutzer Fehler auf, und die Systeme stellen keinen systematischen Weg der Ermittlung von Fehlern zur Verfügung, wenn diese eingegeben werden, so daß derartige Fehler durch das System hindurchgelangen können, von einem Prozeß zum nächsten, ohne ermittelt zu werden, was zu kumulativen Fehlern führt, die - wenn sie einmal entdeckt werden - eine zeitaufwendige und teure Korrektur erfordern können.

Wenn darüber hinaus ein Benutzer festlegt, daß ein bislang nicht in dem System verwendetes, neues Softwaretool eingesetzt werden soll, so gibt es keine systematische Vorgehensweise für die Zufügung eines derartigen Tools. Dies kann dazu führen, daß ein neuer Datenübersetzer entworfen, entwickelt, untersucht und bestätigt werden muß, und daß andere Prozeduren erforderlich werden können, um eine Schnittstelle für ein derartiges Tool in dem System zur Verfügung zu stellen, und sämtliche dieser Schritte erfordern eine erhebliche Erfahrung, Zeit und Kosten, bis sie erfolgreich beendet sind.

Insbesondere wird bei existierenden Systemen die Software im allgemeinen nur in Form eines Objektcodes zur Verfügur gestellt, und ein Benutzer kann keine Änderungen durchführen oder kann diese nur im Quellencode durchführen- der in einem getrennten Vorgang kompiliert werden muß, üblicherweise außerhalb des Systems, bevor er für das System nutzbar ist. Es wäre vorzuziehen, wenn der Benutzer das System mit einem Code steuern könnte, der in einer interpretativen Erweiterungssprache geschrieben ist, die sowohl von der Maschine als auch vom Menschen lesbar ist.

Daher besteht ein Bedürfnis für ein verbessertes Verfahren und eine verbesserte Vorrichtung (manchmal gemeinsam als "System" bezeichnet) zur Verwendung mit mehreren unterschiedlichen Softwaredesign- und Produktionstools, welche die Verwendung eines derartigen Systems für den Endbenutzer wesentlich vereinfachen, und nur noch erheblich geringere Kenntnisse des Systems und der mit diesem benutzten Softwaretools vom Endbenutzer erfordern. Insbesondere sollte ein derartiges System auf einfache und systematische Weise die Schnittstelle zwischen dem Systembenutzer und den verschiedenen Tools und Vorgängen steuern, die bei dem System durchgeführt werden sollen, sollte sämtliche Kommunikationsvorgänge zwischen den verschiedenen Softwaretools in dem System steuern und sicherstellen, daß erforderliche Interpretationen und Übersetzungen durchgeführt werden, und die zeitliche Abfolge der Tasks managen, die zur Durchführung eines bestimmten Ziels durchgeführt werden, so daß der Benutzer nur durch eine geeignete Eingabe ein gewünschtes Ziel angibt, und das System damit weitermachen kann, in der richtigen Reihenfolge, die verschiedenen Tasks durchzuführen, die zur Erzielung dieses Ziels erforderlich sind. Derartige Tasks können die Übertragung erforderlicher Information von einem Softwaretool zum nächsten umfassen und Aufforderungen an den Benutzer für zusätzliche Eingaben, wenn dies erforderlich ist. Ein derartiges System sollte sämtliche erforderlichen Übersetzungen und Interpretationen zwischen nicht kompatiblen Softwaretools durchführen, und sämtliche derartige Übersetzungen sollten vorzugsweise sowohl für den Benutzer oder Bediener als auch für die verschiedenen Softwaretools, die momentan laufen, transparent oder verständlich sein. Ein derartiges System sollte darüber hinaus so flexibel sein, daß es unter Verwendung verhältnismäßig einfacher Prozeduren durch eine Systemintegrationseinrichtung konfigurierbar und erneut konfigurierbar ist, wobei derartige Zufügungen, Vergrößerungen oder andere Änderungen wiederum für den Benutzer transparent sind. Insbesondere sollten sämtliche Steuerungen für ein derartiges System in einer interpretativen Ausdehnungssprache geschrieben werden, welche eine einfache Änderung der Steuerungen durch den Benutzer zuläßt, jedoch immer noch von der Maschine lesbar ist. Daher würde der Bediener des Systems immer die jüngste, vergrößerte Version des Systems mit sämtlichen Möglichkeiten des Systems nutzen und sollte immer dann, wenn dies geeignet ist, dazu aufgefordert werden, diese Fähigkeiten zu nutzen. Soweit der Benutzer nicht mit der Funktion einer bestimmten Fähigkeit vertraut ist, könnte eine "Hilfe"-Funktion zur Verfügung gestellt werden, um ihn zu unterstützen.

Wie voranstehend erläutert, betrifft die vorliegende Erfindung ein Verfahren und eine Vorrichtung für ein vom Benutzer konfigurierbares System, welche den Betriebsablauf mehrerer unterschiedlicher Tasks und Softwaretools integriert und verwaltet, wobei zumindest einige dieser Tools mit dem System nicht kompatibel sein können, auf welchem die Tools verwendet werden sollen, und/oder miteinander nicht verträglich sein können. Das System enthält eine Liste von Softwaretools, welche auf oder mit dem System laufen können, wobei die Liste eine Anzeige enthält, ob die Tools mit dem System verträglich sind oder nicht. Mehrere Regelmakros können ebenfalls gespeichert sein, wobei jedes der Makros die Leistung eines bestimmten Prozesses betrifft. Ein durchzuführender Prozeß wird in das System entweder von einem Benutzer oder von einem vorherigen Prozeß eingegeben, und das diesem Prozeß entsprechende Makro wird zurückgeholt. In Reaktion auf das Zurückholen des Makros werden Tasks, die ausgewählte Tools betreffen, in einer vorbestimmten Sequenz ausgeführt. Wird ein nicht kompatibles Tool ausgeführt, so wird es eingekapselt, was dazu führt, daß sämtliche Übertragungen von dem Tool und zu dem Tool hin überprüft und, soweit erforderlich, interpretiert werden. Mehrere der Interpretationsregeln können ebenfalls an einem vorbestimmten Ort in einem Makro gespeichert sein, welches ein Softwaretool enthält, das eingekapselt werden muß. Für jede Übertragung zum Tool und aus diesem heraus wird eine Überprüfung durchgeführt, um zu ermitteln, ob eine oder mehrere der Interpretationsregeln anwendbar sind, und die in der Regel festgelegte Interpretation wird durchgeführt, wenn festgestellt wird, daß eine Interpretationsregel einen übertragenen Gegenstand betrifft. Getrennte Regeln können für Übertragungen an ein nicht kompatibles Tool und Übertragungen von einem nicht kompatiblen Tool vorgesehen sein.

Für bestimmte Ausführungsformen wird jeder Gegenstand in einem Regelmakro in einer interpretativen Ausdehnungssprache geschrieben, die sowohl vom Menschen als auch von der Maschine verstanden wird. Dies umfaßt die Interpretationsregeln, die für die Einkapselung verwendet werden. Ein Makro kann Regeln für mehrere Softwaretools enthalten, zur Durchführung eines vorgegebenen Tasks (Aufgabe), wobei die Regeln unter anderem die Reihenfolge festlegen, in welcher die Tools ausgeführt werden sollen. Ein Makro kann ebenfalls eine Regel oder Regeln enthalten, welche das Zurückholen eines neuen Makros hervorrufen.

Makros können Regeln zur Steuerung der Reihenfolge von Tools enthalten, die Schnittstellen von Tools mit dem System, mit einem Benutzer und untereinander. Der Benutzer des Systems kann Regeln in existierenden Makros hinzufügen oder ändern, oder neue Makros hinzufügen, all dies in der interpretativen Ausdehnungssprache. Dies führt dazu, daß die Regeln von dem System erkannt werden und von dem System in der Ausdehnungssprache sofort ausführbar sind. Daher kann das System umkonfiguriert werden, um neue Funktionen oder neue Tools aufzunehmen, System- oder Toolausdehnungen oder andere Änderungen einzubauen, Fehler zu korrigieren oder für jeden anderen Zweck.

Das Format für zumindest einige der Tools kann von dem Format für andere Tools unterschiedlich sein, wobei Übertragungen in zumindest einer Richtung zwischen solchen bezüglich des Formats nicht kompatiblen Tools auftreten. Eine Regeldatei kann zur Verfügung gestellt sein, die in einer interpretativen Ausdehnungssprache geschrieben ist, welche Formatumwandlungsregelungen für Tools enthält, die nicht kompatible Formate aufweisen. Wenn eine Übertragung zwischen bezüglich des Formats nicht kompatiblen Tools durchgeführt werden soll, so werden die geeigneten Formatumwandlungsregeln aus der Regeldatei zurückgeholt und zur Steuerung der Formatumwandlung des Materials verwendet, welches zwischen derartigen Tools übertragen werden soll.

Es können auch Inkompatibilitäten bei gültigen Zeichenketten (also gültigen Namen) zwischen Tools existieren. Weiterhin wird eine Regeldatei zur Verfügung gestellt, die in einer interpretativen Ausdehnungssprache geschrieben ist, welche Übersetzungsregeln für Tools enthält, die eine derartige Inkompatibilität bezüglich des Namens aufweisen. Wenn eine Übertragung zwischen in bezug auf den Namen nicht kompatiblen Tools erfolgt, werden geeignete Regeln in den Regeldateien zurückgeholt und dazu verwendet, die Übersetzungen durchzuführen, die dazu erforderlich sind, die Tools kompatibel zu machen.

Wenn ein Name in der Originalsprache in einen Namen in der erzeugten Sprache übersetzt wird, so wird in einer Namensliste ein Eintrag für den originalen und den erzeugten Namen durchgeführt. Gibt es einen derartigen Eintrag für einen Namen, der eine Übersetzung erfordert, so wird der Eintrag zur Übersetzung des Namens verwendet. Gibt es keinen Eintrag für einen zu übersetzenden Namen, so werden die geeigneten Regeln in der Regeldatei zur Übersetzung des Namens verwendet. Wenn eine Übersetzung unter Verwendung von Regeln aus der Regeldatei durchgeführt wird, so kann nach der Übersetzung eine Überprüfung durchgeführt werden, um ungültige Zeichen zu entfernen, den übersetzten Namen auf eine geeignete Maximallänge zu begrenzen, falls erforderlich, um dem übersetzten Namen Vorsilben oder Nachsilben zuzufügen, und um den übersetzten Namen so zu ändern, daß er einzigartig ist, falls ein einzigartig übersetzter Name für jeden zu übersetzenden Namen erforderlich ist, und wenn eine derartige Änderung möglich ist. Eine Alias-Datei kann für sämtliche Einträge erzeugt und gespeichert werden, die für eine bestimmte Verwendung vorgenommen wurden, und die Alias-Datei kann zurückgeholt und verwendet werden, wenn eine darauffolgende Übertragung zwischen denselben beiden Tools erforderlich ist. Es ist ebenfalls möglich, daß derartige Alias-Dateien ursprünglich zusammen mit den Übersetzungsregeln zur Verfügung gestellt werden. Weiterhin kann eine Fähigkeit bereitgestellt werden, welche ermöglicht, daß ein Originalname aus dem erzeugten Namen erhalten wird. Wenn der übersetzte oder erzeugte Name nicht einzigartig ist, so kann für jeden erzeugten Namen eine Liste von Originalnamen zur Verfügung gestellt sein.

Eines oder mehrere der Tools können auch eine geschachtelte Hierarchie von Material bezüglich Komponenten oder anderen Gegenständen mit unterschiedlichen Namen aufweisen, die für denselben Gegenstand an unterschiedlichen Niveaus in der Hierarchie verwendet werden. Eine Regeldatei ist vorgesehen, die zumindest Übersetzungseinträge für die Namen der unterschiedlichen Hierarchieniveaus aufweist, wobei diese Regeldatei dazu verwendet wird, den geeigneten Namen für einen Gegenstand auf einem vorgegebenen Hierarchieniveau zu erhalten. Die Regeln zur Benennung eines Gegenstands können auch an unterschiedlichen Hierarchieniveaus verschieden sein, und die Regeldatei kann auch Übersetzungsregeln für die Hierarchieniveaus enthalten.

Eine Informationseingabe kann von einem Benutzer auch für zumindest einige Tools gefordert werden. Derartige Eingaben können Daten- oder Steuereingaben oder Eingaben bezüglich grafischer Signalformen sein. Für Daten- und Steuereingaben stellt eine Regelliste, die in einer interpretativen Ausdehnungssprache geschrieben ist, Standardeingaben für jede Stufe zur Verfügung, in welcher derartige Eingaben für jedes Tool erforderlich sind. Ist ein Tool auf einer Stufe, in welcher derartige Eingaben erforderlich sind, so werden die Standardeingaben für diese Stufe dem Benutzer angezeigt. Der Benutzer kann Änderungen der Standardeingaben vornehmen, und die Standardeingaben in der vom Benutzer modifizierten Weise werden dem System oder dem Tool mitgeteilt. Die Standardeingabeanzeige kann auch den Benutzer bezüglich Gegenständen auffordern, welche der Benutzer als Eingaben in einer gegebenen Stufe des Tools hinzufügen muß, wobei weiterhin der Betriebsablauf des Tools solange gesperrt ist, bis der Benutzer diese geforderten Eingaben vornimmt, und kann auch den Benutzer bezüglich wahlweiser Gegenstände auffordern, die der Benutzer als Eingaben an der vorgegebenen Stufe in dem Tool zufügen kann.

Für grafische Signalformen oder ähnliche Eingaben sind Tabellen vorgesehen, welche die verschiedenen Digitalzustände einzugebender Signalformen festlegen und die logische Regeln für die Behandlung oder die Wechselwirkung mit derartigen Signalformen festlegen. Vom Benutzer eingegebene, erzeugte oder Standard-Signalformanzeigen können angezeigt werden, unter Verwendung der gespeicherten Digitalzustandsinformation, und Befehle von unterschiedlichen Quellen können bezüglich der Signalform oder anderer Grafiken ausgeführt werden, unter Verwendung, soweit erforderlich, der gespeicherten, festgelegten Zustände und logischen Regeln.

Die Erfindung wird nachstehend anhand zeichnerisch dargestellter Ausführungsbeispiele näher erläutert, aus welchen weitere Ziele, Merkmale und Vorteile hervorgehen. Es zeigt:

Fig. 1 ein schematisches Blockschaltbild eines Systems, bei welchem sich die erfindungsgemäße Lehre einsetzen läßt;

Fig. 2 ein Diagramm mit einer Darstellung verschiedener Dateien, die gemäß einer bevorzugten Ausführungsform der Erfindung gespeichert sein können;

Fig. 3 ein Flußdiagramm eines beispielhaften Vorgangs, der unter Verwendung der Lehren der vorliegenden Erfindung durchgeführt werden kann;

Fig. 3A eine Darstellung detaillierterer Schritte zur Durchführung einer der in Fig. 3 gezeigten Funktionen;

Fig. 4 ein Flußdiagramm des grundlegenden Epic-Prozesses, der zur Steuerung und Handhabung bei der Durchführung einer bevorzugten Ausführungsform der Erfindung eingesetzt werden kann;

Fig. 5 ein Diagramm mit einer Erläuterung des Standardanzeigeformats für eine bevorzugte Ausführungsform der Erfindung;

Fig. 6A und 6B zusammen einen erläuternden Befehlssatz für die Epic-Regeldatei, einschließlich zweier erläuternder Makros, für eine bevorzugte Ausführungsform der Erfindung;

Fig. 7 ein Flußdiagramm für den Prozeß der Einrichtung eines "Bildschirms" ("Rahmens") zur Verwendung bei einem allgemeinen Umbenennungsvorgang gemäß einer bevorzugten Ausführungsform der Erfindung;

Fig. 8 ein Flußdiagramm von Routinen zum Hinzufügen bestimmter Information zu einem "Bildschirm" und zur Wiedergewinnung dieser Information von diesem;

Fig. 9 ein Flußdiagramm der allgemeinen Umbenennungsroutine;

Fig. 10 ein Flußdiagramm eines Vorgangs zum Erhalten eines Originalnamens aus einem erzeugten Namen in den allgemeinen Umbenennungsroutinen;

Fig. 11A und 11B Flußdiagramme zur Erzeugung einer Alias-Datei bzw. das Lesen einer Alias-Datei;

Fig. 12 ein Flußdiagramm einer auf Regeln basierenden Schnittstellenroutine;

Fig. 12A ein Beispiel eines Eintrags in einer auf Regeln basierenden (rbi) Regeldatei;

Fig. 13 ein Flußdiagramm einer Designüberprüfungs-(dv)Routine, die als Benutzerschnittstelle zum Sammeln von Informationen zur Verwendung in verschiedenen Tools dient;

Fig. 13A einen beispielhaften Abschnitt einer dv-Regeldatei;

Fig. 14 eine erläuternde Anzeige zur Verwendung mit der dv-Routine;

Fig. 15 ein Flußdiagramm einer interaktiven Grafikroutine, die als Wavedit bezeichnet wird;

Fig. 16 ein detaillierteres Flußdiagramm des Schrittes "Lies Konfigurationsdateien" von Fig. 15;

Fig. 17 ein detaillierteres Flußdiagramm des Schrittes "Führe den Befehl aus" von Fig. 15, dargestellt für einen beispielhaften Befehl;

Fig. 18 ein detaillierteres Flußdiagramm des Schrittes "Zeichne Anzeige" von Fig. 15; und

Fig. 19 ein Flußdiagramm von Vorgängen, die in der Wavedit-Routine durchgeführt werden, wenn ein "Aussteigen"-Befehl empfangen wird.

In Fig. 1 weist ein System 20, in welchem das Verfahren und die Vorrichtung gemäß der Erfindung ausgeführt werden können, einen Prozessor 22 mit ausreichender Kapazität auf, um die verschiedenen Funktionen gemäß der vorliegenden Erfindung durchzuführen. Ein geeigneter Prozessor kann beispielsweise ein Sparc-System sein, welches von Sun Microsystems hergestellt wird. Der Prozessor weist typischerweise verschiedene Eingabegeräte auf, beispielsweise eine Tastatur 24 und/oder eine Maus 26, die von einem Benutzer betätigt werden können. Eine Massenspeichervorrichtung 28, die irgendeine Standardmassenspeichereinheit sein kann, ist zum Speichern verschiedener Dateien vorgesehen, die bei dem System verwendet werden, und eine Anzeigevorrichtung 30, beispielsweise eine übliche Kathodenstrahlröhrenanzeige (CRT) kann auf übliche Weise mit dem Prozessor 22 über eine Schnittstelle verbunden sein, um verschiedene Bildschirmdarstellungen zur Verfügung zu stellen, die von dem System genutzt werden. Derartige Bildschirmanzeigen können Menüs von Ikons oder andere Menüs enthalten, aus welchen unter Verwendung der Maus 26, der Tastatur 24 oder anderer Standardeingabegeräte auf bekannte Weise Auswahlen getroffen werden können, und können auch alphanumerische Anzeigen unterschiedlicher Dateien und von Daten enthalten, die von dem System verwendet werden, und verschiedene Grafikanzeigen einschließlich schematischer Diagramme.

Die Programme und Dateien, welche einen Teil der vorliegenden Erfindung bilden, können dazu verwendet werden, die zeitliche Abfolge verschiedener Computerprogramme zu steuern und zu behandeln, die auch nachstehend als Softwaretools bezeichnet werden, und auf dem Prozessor 22 laufen, ebenso wie Software, die dazu ausgelegt ist, den Betrieb verschiedener anderer Geräte zu steuern oder mit diesen zusammenarbeiten, die in dem System verwendet werden, einschließlich - jedoch nicht hierauf beschränkt - Designgeräte 32, Entwurfsgeräte 34, Herstellungsgeräte 36 und Untersuchungsgeräte 38. Die externen Geräte können an den Prozessor 22 über einen oder mehrere Standardeingabe/Ausgabebusse 40 angeschlossen sein. Sämtliche Geräte auf dem Bus 40 können sich an einem einzigen Ort befinden, oder es können einige der Geräte an unterschiedlichen Orten angeordnet sein und mit dem Prozessor 22 über ein Netzwerksystem oder eine andere geeignete Kommunikationseinrichtung verbunden sein.

Fig. 3 zeigt einen typischen Prozeß, der unter Verwendung des in Fig. 1 gezeigten System durchgeführt werden kann, und unter Verwendung der erfindungsgemäßen Lehren. In diesem Fall wird die Erfindung dazu eingesetzt, eine gedruckte Schaltungsplatine (PCB) zu entwerfen und herzustellen. Der Benutzer kann den Prozeß dadurch beginnen, daß er "Erzeuge Design" aus einem geeigneten Menü auswählt, welches auf der Anzeige 30 dargestellt wird (Schritt 50). Dies kann veranlassen, daß ein Makro aus dem Speicher 28 auf eine noch zu beschreibende Weise ausgewählt wird, welches bestimmte Verwaltungsfunktionen durchführt, und kann dann zum Aufrufen eines geeigneten Tools führen, nämlich "Schema aufbauen". Dies ist durch den gestrichelten Kasten 52 angedeutet. Der erste Schritt bei diesem Vorgang kann darin bestehen, ein Tool aufzurufen, welches zur Erzeugung einer Schemazeichnung führt (Schritt 54). Als Teil dieses Schrittes kann der Benutzer die Art der Schaltung angeben, die entworfen werden soll, und das System kann eine Schaltung zur Durchführung einer derartigen Funktion anzeigen. Der Benutzer kann entweder diese Schaltung benutzen und mit dem Schritt 54 fortfahren, um die gezeigte Schemazeichnung zu überarbeiten, oder kann angeben, daß er seine eigene Schemazeichnung erzeugen möchte, und in diesem Fall wird ein unterschiedliches Tool aufgerufen, welches es dem Benutzer gestattet, eine Schemazeichnung von Grund auf aufzubauen.

Hat der Benutzer die Erzeugung einer Schemazeichnung beendet, so kann dann das System mit dem Schritt 56 fortfahren, um ein geeignetes Makro aufzurufen, welches ein geeignetes Softwaretool oder Tools aufruft, um eine Überarbeitung der Schemazeichnung zu gestatten. Sobald eine geeignete Schemazeichnung erzeugt und überarbeitet wurde, geht der Betriebsablauf mit dem Schritt 58 weiter, in welchem geeignete Makros und Tools aufgerufen werden, welche veranlassen, daß die Schemazeichnung zusammengepackt wird, und geht dann mit dem Schritt 60 weiter, um das Design zu überprüfen. Der Überprüfungsschritt kann den Aufruf geeigneter Tools umfassen, um sowohl die Logik der Schemazeichnung als auch deren Elektronikbestandteile zu überprüfen. Fig. 3A, die etwas später beschrieben wird, erläutert verschiedene Schritte, die während des Überprüfungsschrittes 60 ausgeführt werden können. Wenn während des Überprüfungsschrittes 60 festgestellt wird, daß ein Fehler bezüglich der Logik oder der Elektronikbauteile vorliegt, so kann der Betriebsablauf zum Schritt 56 zurückkehren, um eine weitere Überarbeitung der Schemazeichnung zur Überwindung eines derartigen Problems durchzuführen.

Sobald das Design überprüft wurde, kann der Benutzer entweder davon in Kenntnis gesetzt werden, daß das Design überprüft wurde, und dann zu möglichen nächsten Schritten geführt werden, oder das System kann vorzugsweise zum Schritt 62 übergehen, um die PCB aufzubauen. Der gestrichelte Kasten 64 erläutert verschiedene Schritte, die während des Vorgangs "PCB-Aufbauen" durchgeführt werden können. Für jeden dieser Schritte wird ein geeignetes Makro aufgerufen, was wiederum dazu führt, daß geeignete Tools aufgerufen werden, um die Funktion durchzuführen. Die beispielhaften Funktionen, die für die Funktion des Aufbaus der PCB gezeigt sind, umfassen eine Festigung der Platine, Schritt 66, Anordnen von Bauteilen auf der Platine, Schritt 68, Verlegen von Verdrahtungen für die Platine, Schritt 70, und Rückseitenbeschriftung, Schritt 72, wenn irgendeine Änderung vorgenommen wird.

Wenn in der Hinsicht während des Schrittes 70 ein Problem auftritt, daß es nicht möglich ist, Verdrahtungswege anzuordnen, so kann der Betriebsablauf zum Schritt 66 zurückkehren, um eine erneute Festlegung der Platine vorzunehmen, um so das Problem zu überwinden. Wenn weiterhin Probleme auftreten, so kann es entsprechend nötig werden, zum Schritt 56 zurückzukehren, um das ursprüngliche Design zu überarbeiten, so daß eine einfachere Anordnung und ein einfacherer Aufbau erreicht werden. Im Idealfall führt die Beendigung jedes der Schritte 66 bis 72 zum Aufruf der geeigneten folgenden Schritte.

Sobald der Schritt 64 des Aufbaus der PCB erfolgreich abgeschlossen ist, kann der Betriebsablauf automatisch das erste Makro aufrufen, welches zur Durchführung des Schrittes 74, der Herstellung der PCB erforderlich ist. Alternativ hierzu kann die Beendigung des Schrittes 64 zum Aufbau der PCB nur zu einer geeigneten Anzeige auf der Anzeigevorrichtung 30 führen, um den Benutzer darüber zu benachrichtigen, daß das System dazu bereit ist, die Herstellung der Platine zu beginnen. Der Schritt der Herstellung der PCB kann die Schritte umfassen, die in dem gestrichelten Kasten 66 angegeben sind. Diese Schritte umfassen die Schöpfung der Platine aus der während der Schritte 64 und 78 geschaffenen Zeichnung, das Bohren erforderlicher Löcher in die Platine, Schritt 80, und das Hineinfügen oder Einstopfen der Bauteile in die Platine, Schritt 82. Die Makros zur Durchführung der verschiedenen Schritte 78, 80 und 82 können an geeigneten Punkten veranlassen, daß verschiedene Herstellungsgeräte 36 eingesetzt werden, einschließlich der Bereitstellung erforderlicher Steuereingaben und Dateneingaben für diese Geräte, so daß die Ausrüstung ordnungsgemäß arbeitet.

Hierbei kann auch eine Steuerung der Geräte für den automatischen Transport der Platine zwischen verschiedenen Bearbeitungsgeräten je nach Erfordernis vorgesehen werden.

Wenn während des Schrittes 76 Prototyp-Platinen hergestellt wurden, müssen die Platinen geprüft werden. Dies wird während des Schrittes 84 durchgeführt und kann abhängig von den verwendeten Geräten entweder mit denselben Geräten durchgeführt werden, auf welchen die Platine hergestellt wird, wobei dann die auf dem Prozessor 22 laufenden Makros das System dazu veranlassen können, automatisch eine Prüfung der Platinen durchzuführen, wenn die Herstellung der Platinen beendet ist, jedoch können die Platinen auch auf getrennten Geräten geprüft werden. Im letztgenannten Fall müssen die Platinen entweder automatisch zu derartigen anderen Geräten transportiert werden, in Reaktion auf geeignete Makros, die auf dem Prozessor 22 laufen, oder der Prozessor muß in einen Haltezustand versetzt werden, den Benutzer auffordern, die Platine zu Prüfgeräten zu bewegen, und damit weitergehen, daß er geeignete Makros zum Steuern der Prüfvorgänge erst dann aufruft, wenn der Benutzer angibt, daß sich die Platine in einer geeigneten Prüfstation befindet. Wenn die Platinen einen Versuch nicht erfolgreich durchlaufen, so kann abhängig von dem festgestellten Problem der Prozeß zum Schritt 56, zum Schritt 66, zum Schritt 78 oder zu irgendeinem anderen der Zwischenschritte zurückgehen, in welchem die Prüfung ergeben hat, daß eine Schwierigkeit existiert, die behoben werden muß. Das System würde dann das Problem korrigieren, entweder unter Verwendung von in dem System bereitgestellten Regeln, oder dadurch, daß es den Benutzer auffordert Eingaben einzugeben. Sobald die Platine erfolgreich geprüft wurde, kann das System dann die Versendung der Platine im Schritt 86 steuern, falls dies gewünscht ist.

Hieraus wird deutlich, daß zumindest theoretisch durch Betätigung einer einzigen Steuerung mit geeigneten Makros das System veranlassen kann, die gesamte Sequenz von in Fig. 3 gezeigten Vorgängen durchzuführen, und den Benutzer je nach Erfordernis zur Eingabe bestimmter Eingaben auffordern kann, oder bestimmte Tätigkeiten vorzunehmen, soweit erforderlich. Daher könnte das System von einer Bedienungsperson benutzt werden, welche geringe Kenntnis des Systems oder der verschiedenen, hierauflaufenden Tools aufweist, die jedoch gute Kenntnisse im Design und der Konstruktion von PC-Platinen hat. Selbst diese Kenntnisse müssen nicht erschöpfend sein, da das System Standardeingaben in den meisten Fällen zur Verfügung stellen kann, in welchen Eingaben erforderlich sind, so daß die von dem Benutzer geforderten Eingaben recht begrenzt sein können.

Viele der Softwaretools, die zur Durchführung der verschiedenen, in Fig. 3 gezeigten Funktionen erforderlich sind, stammen von unterschiedlichen Verkäufern und können bezüglich der Sprache, der Namen, des Formats und anderer Faktoren inkompatibel sein. Diese Programme können auch mit den grundlegenden Steuerprogrammen inkompatibel sein, die auf dem Prozessor 22 ablaufen. Zur Überwindung dieses Problems weist das System die Fähigkeit auf, automatisch Interpretationen und Übersetzungen durchzuführen, wie dies für Informationsübertragungen zwischen verschiedenen inkompatiblen Softwaretools erforderlich ist, und auch zur Durchführung der erforderlichen Interpretationen und Übersetzungen für Datenübertragungen zwischen der Systemsoftware, die auf dem Prozessor 22 läuft, und verschiedenen Softwaretools, die hiermit inkompatibel sind. Alle diese Datenübertragungen werden auf eine Weise durchgeführt, die nachstehend beschrieben wird, und die sowohl für den Benutzer des Systems als auch für die verschiedenen Softwaretools durchsichtig ist.

Das System weist darüber hinaus, wie nachstehend noch genauer erläutert, die Fähigkeit auf, den Benutzer zu Eingaben aufzufordern, wenn Eingaben für ein Softwaretool erforderlich sind, welches ausgeführt wird. Es ist möglich, in vielen Fällen Standardeingaben zur Verfügung zu stellen, die von dem System benutzt werden, wenn der Benutzer diese Eingaben nicht ändert, wodurch der Dateneingabevorgang für den Benutzer wesentlich vereinfacht wird.

Fig. 3A erläutert eine detailliertere Betriebsablaufsequenz, die durchgeführt werden kann, wenn der Überprüfungsschritt 60 von Fig. 3 durchgeführt wird. In Fig. 3A besteht der erste derartige Schritt darin, eine "Designregelüberprüfung" bezüglich der elektronischen Schemazeichnung durchzuführen, die während der Schritte 54, 56 und 58 erzeugt wurde. "Designregelüberprüfung" ist ein Softwaretool, welches für das System verfügbar ist, um die Logik oder die Elektronik der Schemazeichnung zu überprüfen. Das Makro, welches im Zusammenhang mit dem Ablauf der Designregelüberprüfung aufgerufen wird, würde auch die Erlangung oder das Bereitstellen erforderlicher Eingaben für dieses Softwaretool steuern, in dem Ausmaß, in welchem derartige Eingaben erforderlich sind, und würde auch irgendwelche Übersetzungen steuern, die zur Information erforderlich sind, oder Befehle, welche diesem Softwaretool zur Verfügung gestellt werden.

Wenn der Vorgang der Designregelüberprüfung fertig ist, so führt das System eine Überprüfung durch, um festzustellen, ob die Designüberprüfung erfolgreich beendet wurde. Wird festgestellt, daß die Designüberprüfung erfolgreich festgestellt wurde, dann ruft das System das Softwaretool mit dem Titel "Signalnetzlistenextraktor für einen digitalen Simulator" auf. Wiederum werden je nach Erfordernis Eingaben bereitgestellt und Übersetzungen durchgeführt. Wenn der Extraktor korrekt extrahiert, dann ruft das System ein Softwaretool mit dem Namen "digitaler Simulator" auf. Das "Simulator"-Tool wird unter Verwendung eines Verhaltenssteuermakros ablaufen gelassen, welches eines der Makros des Steuersystems sein kann, die auf dem Prozessor 22 laufen oder ein getrenntes Softwaretool sein kann. Die Ergebnisse des Simulators werden angezeigt unter Verwendung eines getrennten Softwaretools mit dem Namen "Elektronischer Signalwelleneditor". Alle Fehler, die in der geprüften Entwurfsdatei für die elektronische Schemazeichnung gefunden werden, werden hervorgehoben. Dies kann unter Verwendung eines Makros in dem Basissystem erfolgen, oder es kann für diesen Zweck ein getrenntes Softwaretool aufgerufen werden. Die Hervorhebung, die beispielsweise dadurch vorgenommen werden kann, daß die Leitung, das Bauteil oder ein anderes Schaltungselement, in welchem ein Problem ermittelt wurde, blinkend dargestellt wird, benachrichtigt den Benutzer von diesem potentiellen Problem.

Der Benutzer kann dann Schritte unternehmen, um das Problem zu korrigieren, oder das System selbst kann unter Verwendung von in einem Makro bereitgestellten Regeln entweder dem Benutzer mögliche Lösungen für das Problem vorschlagen oder unter Verfolgung bereitgestellter Regeln eine geeignete Korrektur in der Schemazeichnung vornehmen, um das Problem zu korrigieren.

Falls der Extraktor nicht korrekt extrahiert hat, dann wird der Benutzer auf geeignete Weise über den Signalnetzlistenextraktorfehler informiert. Wie bei dem Simulator, kann das System auch hier mögliche Korrekturen für den Fehler vorschlagen oder es unternehmen, den Fehler selbst zu korrigieren. Entsprechend wird, wenn die Designüberprüfung nicht erfolgreich beendet wurde, der Benutzer über Verletzungen der Regel für das elektronische Design informiert, und das System kann wiederum eine Anzeige möglicher Korrekturen zur Verfügung stellen oder unter Verwendung von Regeln versuchen, das Problem selbst zu korrigieren. Wenn der Überprüfungsvorgang beendet ist, so kehrt das System zum schematischen Editor zurück, geht mit dem Schritt 62 zum Aufbau der PCB weiter oder nimmt eine andere geeignete Austrittsaktion vor.

Entsprechend den erfindungsgemäßen Lehren werden die verschiedenen Funktionen unter Steuerung eines auf Regeln beruhenden Verwaltungs- und Steuersystems oder Programms durchgeführt, welches nachstehend manchmal als "Epic" bezeichnet wird. Wie nachstehend mit weiteren Einzelheiten erläutert wird, verwendet dieses Programm eine Regeldatei, die für jeden Prozeß Makros enthält. Die Makros steuern das Aufrufen geeigneter Softwaretools in der geeigneten Reihenfolge und steuern auch das Sammeln und die Übertragung von Informationen zwischen verschiedenen Tools sowie zwischen dem System und verschiedenen Tools. Weiterhin steuern die Makros die Leistung erforderlicher Interpretationen/Übersetzungen für Übertragungen zwischen Tools und für Übertragungen zwischen Tools und der Systemsteuersoftware. Insbesondere weist Epic die Fähigkeit auf, inkompatible Softwaretools einzukapseln, so daß alle Datenübertragungen von dem Tool an Epic überprüft und geeignete Interpretationsregeln angewendet werden, bevor das Material, welches übertragen wird, von Epic benutzt wird, und so, daß sämtliche Ausgaben von Epic an das Tool ebenfalls überprüft und erforderliche Interpretationen vorgenommen werden, bevor Material an das Tool zurückgegeben wird. Die Einkapselung ist sowohl für das Softwaretool als auch für den Benutzer vollständig transparent.

Epic verwendet verschiedene Zusatzprogramme, die ihm dabei helfen, die Interpretation und die Datenzusammenstellungsfunktionen durchzuführen. Diese Programme umfassen ein Programm, welches als "GRM" bezeichnet wird, was eine Abkürzung für "General Renaming Module" (allgemeines Umbenennungsmodul) darstellt. Dieses Programm weist unterschiedliche Dateien auf, wobei im allgemeinen zumindest eine Datei für jedes Paar inkompatibler Programme oder Softwaretools vorgesehen ist. Jede GRM-Datei umfaßt mehrere Regeln, die zur Durchführung von Übersetzungen für Namen von der Ursprungssprache zu einer erzeugten Sprache verwendet werden können. Eine Datei kann auch eine Auflistung von Übersetzungen von Namen in der Originalsprache in Namen in der erzeugten Sprache aufweisen. Beispielsweise kann hierdurch angezeigt werden, daß bei einer Eingabe "A" die Ausgabe "a" sein sollte. Derartige Übersetzungslisten könnten in der Datei enthalten sein, welche die ursprünglich bereitgestellten Regeln enthält, oder könnte unter Verwendung der Regeln erzeugt werden, während Übersetzungen durchgeführt werden, und als Alias-Dateien für die zukünftige Benutzung gespeichert werden. GRM kann auch dazu eingesetzt werden, Übersetzungen zwischen unterschiedlichen Hierarchiepegeln eines Designs von demselben oder unterschiedlichen Tools durchzuführen, wenn die auf diesen unterschiedlichen Niveaus verwendeten Namen inkompatibel sind.

Übersetzungsdateien wären dann für jede derartige Hierarchieumwandlung vorgesehen.

Ein zweites Programm, welches mit Epic verwendet werden kann, wird manchmal als "RBI" bezeichnet, was eine Abkürzung für "Rools Based Interface" (auf Regeln basierende Schnittstelle) darstellt. Dieses Programm wird dazu eingesetzt, Formatübersetzungen durchzuführen, wenn Programmtools keine kompatiblen Formate aufweisen. Dies kann beispielsweise dann auftreten, wenn ein Softwaretool Information in schematischer Form zur Verfügung stellt, während das andere Softwaretool Information in Netzlistenform verwendet (eine Liste der Bauteile in der Schaltung und der Knoten oder anderer Bauteile, an welches jedes dieser Bauteile angeschlossen ist). Ein Satz von RBI-Regeldateien ist zur Durchführung dieser Funktion vorgesehen.

Ein drittes Programm, welches mit Epic verwendet werden kann, ist die dv-Routine ("Design Verification": Designüberprüfung), die dazu eingesetzt wird, beim Zusammenstellen erforderlicher Information von dem Benutzer oder anderen Quellen für die unterschiedlichen Softwaretools zu helfen, die auf dem System ablaufen. Bestimmte Regeldateien sind auch für dv vorgesehen, und ihre Funktionen werden später erläutert.

Ein viertes Programm, welches mit Epic verwendet werden kann, ist die Wavedit-Routine, die zur Hilfe beim Zusammenstellen, Erzeugen und Bearbeiten grafischer Eingaben im allgemeinen und insbesondere von Signalformdaten verwendet wird. Zur Verwendung mit dieser Routine sind verschiedene Digitalzustandsdefinitionen und Logikregeln vorgesehen.

Die verschiedenen Regelmakros und Regeldateien, die voranstehend beschrieben wurden, sind ursprünglich beispielsweise auf einer Harddisk oder einer Softdisk gespeichert, die in den Speicher 28 eingeführt werden kann oder ein Teil dieses Speichers ist. Standardregeldateien werden typischerweise von dem Bereitsteller des Systems zur Verfügung gestellt. Die Makros und die Regeldateien sind in einer interpretativen Ausdehnungssprache geschrieben, die sowohl von Menschen als auch von der Maschine lesbar sind. Die Makros und Rulen können in einer existierenden Ausdehnungssprache geschrieben sein, beispielsweise LISP, sind jedoch vorzugsweise in einer speziellen Sprache geschrieben, die speziell für diesen Einsatzzweck angepaßt ist. Die Makros und die Regeln können sämtlich in derselben Sprache geschrieben sein, oder es können unterschiedliche interpretative Ausdehnungssprachen für unterschiedliche einzelne oder mehrere Dateien verwendet werden, so daß in jedem Fall die optimale Sprache verwendet wird. Zwar werden Beispiele für eine geeignete interpretative Ausdehnungssprache bei einigen der folgenden Beispiele erläutert, jedoch stellt die bestimmte, verwendete Sprache keinen Teil der Erfindung dar.

Allerdings ist es wesentlich, daß die verschiedenen Regeln und Makros in einer interpretativen Ausdehnungssprache geschrieben sind, so daß eine Person, die als ein "Toolintegrator" bezeichnet wird, die für den Benutzer arbeitet, die Standardregeln und Dateien überprüfen kann, die von dem System bereitgestellt werden, und Makros und Regeldateien modifizieren, hinzufügen oder subtrahieren kann, wie dies erforderlich ist, um das System an die Anforderungen des Benutzers anzupassen. Derartige Änderungen können vorgenommen werden, wenn das System zuerst empfangen wird, und können von Zeit zu Zeit daraufhin unternommen werden, um Aktualisierungen oder Vergrößerungen des Systems widerzuspiegeln, die zur Korrektur von Fehlern vorgenommen werden, die sich beim Betrieb des Systems ergeben haben, oder um neue Softwaretools in das System zu integrieren. Wichtig ist hierbei, daß nur der Toolintegrator die Änderungen bemerken muß. Sobald er derartige Änderungen in die Regelmakros eingebaut hat, werden derartige Änderungen automatisch von dem System durchgeführt, ohne daß der Systemoperator die Änderungen wahrnehmen muß, oder die Tatsache, daß sie eingegeben wurden. Insoweit derartige Änderungen Eingaben von dem Benutzer erfordern, können Aufforderungen für den Benutzer vorgesehen werden, um sicherzustellen, daß er erforderliche Eingaben zur Verfügung stellt. Falls die Bedienungsperson eine Aufforderung nicht versteht, so kann ein Menü oder, gemäß einer weiteren Zielrichtung des Systemablaufs, eine "Hilfe" -Funktion verfügbar sein, um den Benutzer mit erforderlicher Information zu versorgen.

Auf diese Weise sind derartige Änderungen für den Benutzer vollständig transparent, und alles, was er wissen muß, ist der Prozeß, der er durchführen möchte. Durch Bereitstellung der Makros und der Regel in der interpretativen Ausdehnungssprache können einfach Änderungen einer Datei durchgeführt werden, die dann von dem Toolintegrator oder einer anderen Person, welche die Änderungen vornimmt, überprüft werden können, und können sofort auf dem System ablaufen, ohne daß es erforderlich ist, daß das Programm einem Compiler zugeschickt wird, um kompiliert zu werden, bevor es dem System eingegeben wird, damit es ablaufen kann. Dies vereinfacht wesentlich die Erzeugung und Überprüfung der Regelmakros und Dateien und verringert die Zeit, die dafür erforderlich ist, Umkonfigurierungen in das System einzugeben. Ein System, welches einfach konfigurierbar und umkonfigurierbar durch den Benutzer/Kunden ist, wird auf diese Weise zur Verfügung gestellt.

Fig. 2 erläutert ein Format, in welchem die verschiedenen Regelmakros und andere voranstehend beschriebene Dateien auf einer Disk oder einem anderen Speichermedium gespeichert werden können, welches dem Benutzer für dieses System zur Verfügung steht. Die exakte Reihenfolge, in welcher die Regeln gespeichert werden, ist nicht kritisch, solange geeignete Adressen oder andere Einrichtungen vorgesehen sind, um ein bestimmtes Makro oder eine bestimmte Datei zurückzuholen, wenn dies erforderlich ist.

Aus den Fig. 6A und 6B wird zusammengenommen deutlich, daß zu Erläuterungszwecken der erste in der Disk gespeicherte Gegenstand ein Regelmakroabschnitt 90 ist, wobei dieser Abschnitt zusammen mit dem Haupt-Epic-Programm verwendet wird. Dieser Abschnitt beginnt mit einer Vorlaufmarke, welche diesen Abschnitt so bezeichnet, daß er Epic-Regeln enthält. Dann gibt es eine Anzahl an Kommentaren einschließlich bestimmter juristischer Information, beispielsweise Urheberrechtshinweise, und Kommentare an die Benutzer. Ein bestimmter Kommentar könnte den Toolintegrator des Benutzers darüber informieren, daß jedes Softwaretool, welches auf dem System ablaufen soll, in dem Definitionsabschnitt der Epic-Regel-Datei aufgelistet werden muß, oder sonst nicht lauffähig wäre.

Den Kommentaren folgt ein Definitionsabschnitt für die Softwaretools. In diesem Abschnitt ist jedes Softwaretool, welches auf dem System ablaufen soll, aufgelistet, und verschiedene Information, dieses Tool betreffend, wird bereitgestellt. Windows beispielsweise gibt an, ob das Softwaretool seine eigenen Anzeigen erzeugt, oder ob es Hilfe von dem Betriebssystem erfordert, in diesem Fall dem Epic-System, um Anzeigen zu erzeugen. Der Standardzustand ist der, daß keine Hilfe erforderlich ist, wobei "Window" angezeigt wird, wenn Hilfe erforderlich ist. Der wichtigste Gegenstand bezüglich der vorliegenden Erfindung ist die Anzeige von "Keine Verpackung". Ein Programm, welches "Keine Verpackung" enthält, ist ein Programm, welches mit Epic-Programm kompatibel ist und daher nicht eingekapselt werden muß (es sind keine Interpretationen für Übertragungen zwischen dem Softwaretool und Epic erforderlich). Der Standardzustand ist "Verpackung", was bedeutet, daß jedes Softwaretool, welches nicht die Anzeige "Keine Verpackung" in dem Definitionsabschnitt aufweist, eingekapselt wird. Die anderen Informationen, die in dem Definitionsabschnitt vorgesehen sind, sind Standardbefehlszeilenoptionen für das Tool.

Die nächsten beiden Abschnitte sind die "Anfangssätze" und stellen im wesentlichen die Standardausführung dar, wenn nichts anderes angezeigt wird, was ausgeführt werden soll. In diesem Fall ist die Standardausführung "Epic View", nämlich das Programm, das zur Steuerung von Anzeigen für Epic verwendet wird. "Epic View" veranlaßt, daß eine Anzeige, wie beispielsweise die, die in Fig. 5 gezeigt ist, auf dem Bildschirm in der Standardsituation erscheint.

Den Schluß der Epic-Regeln stellt der Makroabschnitt dar, der mehrere Makros enthält, im allgemeinen eines für jede Funktion, die auf dem System durchgeführt werden soll. Jedes Makro enthält eine Ursprungsbeschreibung in Englisch der Funktion, die von dem Makro durchgeführt wird, hauptsächlich für den Toolintegrator des Benutzers, und einen Satz von Regeln oder Befehlen, die in einer vorbestimmten Reihenfolge ausgeführt werden sollen, um die Funktion des Makros auszuführen. Wie voranstehend erläutert, sind diese in einer interpretativen Ausdehnungssprache beschrieben, die sowohl für den Menschen als auch die Maschine lesbar ist. Das bestimmte Makro, welches in Fig. 6A gezeigt ist, ist für ein Tool mit der Bezeichnung "cadat" bestimmt und führt eine Anzahl von Funktionen unter Verwendung von Routinen durch, die später erläutert werden. Die ersten zwei Holbefehle stellen vorher festgelegte Variablen für den ersten und zweiten Parameter ein, die jeweils in das Makro eingegeben werden. Der nächste Befehl gibt an, daß dann, wenn die Variable "schedit_up" "YES" (Ja) eingestellt ist (als Ergebnis eines vorherigen Vorgangs), eines von zwei Dingen passieren kann. Wurde die Variable "hi_type" vorher auf einen Wert "sim" eingestellt, dann wird eine erste Nachricht unter Beteiligung der Routine dv an das Tool "schedit" geschickt, während dann, wenn "hi_type" nicht auf "sim" eingestellt ist, eine andere Nachricht unter Beteilung der Routine "Wavedit" geschickt wird. Ist "scheidit_up" nicht auf "YES" eingestellt, so wird die angezeigte Nachricht an den auf rufenden Prozeß des Makros zurückgeschickt.

Das in Fig. 6B gezeigte Makro ist ein Makro für die Routine Packager (pkgr), und zwar würde, obwohl eine Beschreibung in normalem Englisch der Funktion der Routine nicht in Fig. 6B vorgesehen ist, das Makro tatsächlich normalerweise eine derartige Beschreibung zur Verwendung durch den Programmintegrator enthalten. Packager stellt ein externes Tool dar, welches zumindest hinsichtlich einiger Einzelheiten mit Epic inkompatibel ist und daher eingekapselt werden muß. Wie nachstehend erläutert wird, wird auf derartige Tools in den "Whilexec"-Tools des Systems Bezug genommen. Die ersten drei Befehle in diesem Makro, ebenso wie die für das vorherige Makro, betreffen die Einstellung bestimmter vorher definierter Variablen auf angegebene Werte. Der vierte Befehl gibt an, daß dann, wenn die Variable mit dem Namen "pkgr_file" leer ist, eine der Variablen, die ursprünglich eingestellt war, eine Fehlernachricht zurück an den auf rufenden Prozeß geschickt werden sollte. Anderenfalls wird eine Nachricht an den aufrufenden Prozeß geschickt, daß das Tool pkgr beginnt. Die Whilexec-Anzeige sagt, daß dieses Tool eingekapselt werden soll und daß insbesondere bei der Ausführung dieses Tools sämtliche Ausgaben von pkgr durch die folgenden Regeln interpretiert werden:

1. Wenn die Textzeile, die von "pkgr" zurückgegeben wird, das Wort "error" (Fehler) enthält, dann wird eine Variable mit dem Namen "pkgr_statuis" auf "errors" gesetzt.
2. Wenn bei Beendigung des Prozesses "pkgr" der Prozeß mit einem Fehlerstatus verlassen wird, dann schicke eine Nachricht an den aufrufenden Prozeß mit einem Fehler.
3. Ist der pkgr_status o.k., dann schließe das Fenster, in welchem Packager gelaufen ist, und schicke eine Nachricht an den aufrufenden Prozeß, daß alles gut abgelaufen ist.
4. Anderenfalls lasse das Fenster offen und schicke eine Nachricht, welche einen Fehler angibt.

Wie voranstehend erläutert, ist die exakte, in den Makros verwendete Sprache nicht kritisch, und die Beispiele wurden hauptsächlich zu dem Zweck gebracht, um zu erläutern, wie Makros die Abfolge des Betriebs und die Einkapselung eines inkompatiblen Tools steuern können. Als Anlage A ist ein Handbuch mit dem Titel "Schematic Design Tools - Administrative Guide - Theda Revision 1.0" beigefügt, welches insbesondere im Abschnitt 3 eine bestimmte Sprache beschreibt, die für die Makros in der bevorzugten Ausführungsform verwendet wird und weitere Einzelheiten des Betriebs bei der bevorzugten Ausführungsform zur Verfügung stellt. Dieses Dokument sollte nicht gedruckt werden.

Zwar sind in Fig. 6A und 6B nur zwei Makros gezeigt, jedoch wären normalerweise hunderte oder sogar tausende von Makros in einem bestimmten System vorhanden, wobei die Anzahl der Makros von der Anzahl an Prozessen abhängt, welche das System durchführen können soll.

Abschnitt 92 des Speichers enthält GRM-Dateien für jede Übersetzung, die das System durchführen muß. Eine getrennte GRM-Datei ist für eine Übersetzung vom Tool A zum Tool B und für eine Übersetzung vom Tool B zum Tool A erforderlich. Es gibt daher zwei GRM-Dateien für jeweils zwei bezüglich der Sprache inkompatible Tools, die in dem System verwendet werden. Jede GRM-Datei enthält eine Sequenz von Regeln, die zur Durchführung von Übersetzungen von Namen zwischen den beiden inkompatiblen Tools verwendet werden können. Weiterhin kann eine Auflistung zumindest ausgewählter Namen in dem Ursprungsprogramm zusammen mit den entsprechenden Namen in dem Ausgabeprogramm zur Verfügung gestellt sein.

Abschnitt 94 des Speichers enthält die dv-Regeldateien, welche Regeldateien für die Eingabe von Eingaben oder die Übersetzung von Eingaben für das System darstellen. Diese Dateien enthalten neben anderen Dingen Standardeingaben für jede Stufe in jedem Softwaretool, in welcher Eingaben erforderlich sind. Die Standardanzeige, die durch diese Regeln hervorgerufen wird, kann - falls erforderlich - eine Anzeige enthalten, daß bestimmte Information von dem Benutzer zur Verfügung gestellt werden muß und kann auch eine Anzeige zusätzlicher wahlweiser Information zur Verfügung stellen, die der Benutzer zur Verfügung stellen kann.

Abschnitt 96 enthält Regeldateien für das RBI-Programm, welches von Epic benutzt wird. Diese stellen im wesentlichen Formatübersetzungsregeln für verschiedene Softwaretools dar, die bezüglich des Formats inkompatibel sind. Typischerweise gibt es einen Satz an RBI-Regeln, oder - mit anderen Worten - eine RBI-Regeldatei für jedes Paar von Softwaretools, die bezüglich des Formats inkompatibel sind.

Abschnitt 98 enthält Dateien zur Verwendung in der Wavedit-Routine. Diese Dateien umfassen Zustandsdefinitionen, Logikregeln, Menüdateien und Befehlsquellendateien zur Verwendung durch die Wavedit-Routine. Der Inhalt und die Funktion jeder dieser Dateien wird später im Zusammenhang mit der Wavedit-Routine erläutert.

Wie voranstehend erwähnt, sind sämtliche in Fig. 2 gezeigten Dateien in einer interpretativen Ausdehnungssprache geschrieben, obwohl es nicht erforderlich ist, daß sie alle in derselben interpretativen Ausdehnungssprache geschrieben sind.

Fig. 4 ist ein Flußdiagramm der Epic-Hauptroutine, die zur Verwaltung und zur Steuerung des Betriebs des Systems verwendet wird. Wenn der Benutzer die Epic-Routine durch eine geeignete Eingabe in den Prozessor 22 aufruft, so besteht der Schritt 100, der erste Schritt, darin, die Regelmakros zu lesen, einschließlich der Definitionen und anderer Informationen, aus dem Bereich 90 des Speichers 28, und zwar in einen Arbeitsspeicher-RAM (Speicher mit wahlfreiem Zugriff) in dem Prozessor (Schritt 102). Dies ergibt eine Prozeßliste, die für jeden definierten Prozeß gebildet wird, wobei die Liste das Makro für einen derartigen Task enthält und weiterhin einen Raum enthält, in welchem eine Whilexec-Taskliste und eine suspendierte Taskliste für den gegebenen Task oder die gegebene Funktion gespeichert werden können. Die Gründe für die Whilexec- und die suspendierte Taskliste, die Art und Weise ihrer Erzeugung sowie ihre Funktion werden nachstehend erläutert. Während des Schrittes 106 wird eine Taskliste erzeugt, welche die Makros enthält, die vorher in das System eingelesen wurden. Während des Schrittes 108 wird eine Variablenliste erzeugt. Diese Liste bildet die Datenbasis für sämtliche Variablen, beispielsweise die zahlreichen Variablen, die im Zusammenhang mit den Fig. 6A und 6B beschrieben wurden, die von Epic verwendet und gespeichert werden. Daher geben die Schritte 104, 106 und 108 die Ausbildung der verschiedenen Listen an. Entweder während des Schrittes 102, 104, 106 oder 108, oder während des Schrittes 110, währenddessen andere Startfunktionen durchgeführt werden, können verschiedene Syntaxüberprüfungen oder andere Überprüfungen bei den Regeldateien vorgenommen werden, die in das System eingelesen werden, um sicherzustellen, daß sie keine Fehler enthalten. Während die Dateien, insbesondere die vom Hersteller zur Verfügung gestellten, normalerweise in Ordnung sein werden, gibt es auf in dem Stand der Technik bekannte Weise mehrere Arten, auf welche Fehler eingeführt werden können. Es ist daher anzuraten, und dies stellt in der Industrie die normale Praxis dar, Fehlerüberprüfungen durchzuführen, bevor man ein Programm ablaufen läßt.

Der Startschritt 110 kann auch einen Aufruf des Standard-Epic-View-Programms umfassen, welches eine Anzeige, beispielsweise die in Fig. 5 gezeigte Anzeige, einschließlich eines Menüs 112 von Ikons, von denen ein beispielhafter Satz auf der rechten Seite des Bildschirms in Fig. 5 gezeigt ist, zur Anzeige auf dem Bildschirm der Anzeige 30 veranlaßt. Der Benutzer nimmt Auswahlen aus dem Menü 112 vor, beispielsweise durch Bewegung eines Cursors (Zeigers) auf ein ausgewähltes Ikon, unter Verwendung einer Maus 26. Jedes Ikon zeigt eine bestimmte Funktion an, zu deren Ausführung das System ausgebildet ist. Die Auswahl eines gegebenen Ikons kann dazu führen, daß zusätzliche Ikons angezeigt werden, oder daß eine andere Art eines Menüs angezeigt wird, aus welchem der Benutzer eine detailliertere Auswahl vornehmen kann, bezüglich der durchzuführenden Funktion. Allerdings nimmt bei der bevorzugten Ausführungsform der Benutzer eine Auswahl von Tasks auf einem relativ hohen Niveau vor, und das System führt Entscheidungen aus, welche bestimmte Tasks betreffen, die durchgeführt werden sollen, um eine derartige Funktion zu erreichen.

Sobald die Startfunktionen, die im Zusammenhang mit Epic erforderlich sind, fertig sind, geht der Betriebsablauf zum Schritt 114 über und wartet auf eine Eingabe. Solange keine Eingabe empfangen wird, verbleibt das System in einem Haltestatus und wartet auf eine Eingabe. Wird eine Eingabe empfangen, so geht der Betriebsablauf zum Schritt 116 über, um zu ermitteln, aus welchem Softwaretool oder aus welcher anderen Quelle die Eingabe empfangen wurde. Wenn beispielsweise die Eingabe durch Auswahl eines Ikons aus dem Menü 112 der in Fig. 5 gezeigten Anzeige empfangen wurde, so wäre die Eingabe durch Epic View hindurchgekommen. Die Quelle, von welcher eine Eingabe empfangen wird, ist wesentlich, da dies es dem Epic-Programm gestattet, den Definitionsabschnitt seiner Regeldatei (siehe Fig. 6A) zu überprüfen, um festzulegen, welche Aktionen (falls überhaupt) in bezug auf Eingaben von dieser Quelle erforderlich sind. Insbesondere gestattet dies dem System zu ermitteln, ob Eingaben von dieser Quelle eingekapselt werden müssen.

Vom Schritt 116 aus geht der Betrieb mit dem Schritt 118 weiter, um zu ermitteln, ob der Prozeß ein Beendigungsprozeß ist. Wie nachstehend erläutert wird, können einige Prozesse einen beträchtlichen Zeitraum bis zu ihrer Beendigung in Anspruch nehmen, manchmal bis zu mehreren Stunden, und es ist vorzuziehen, daß nicht das gesamte System besetzt ist, während derartige Prozesse ablaufen. Derartige Prozesse können beispielsweise auf einem anderen Gerät als dem Prozessor 22 ablaufen. Wenn daher derartige Prozesse ablaufen, hat das System die Option, die verbleibende Warteschlange der Funktionen zu speichern, die im Zusammenhang mit diesem Prozeß durchgeführt werden müssen, bis der Prozeß beendet ist. Die übrigen Tasks, die durchgeführt werden sollen, werden in dem Abschnitt der suspendierten Taskliste der Prozeßliste für den bestimmten Prozeß gespeichert.

Ist der Prozeß beendet, so stellt das die Funktion ablaufenlassende Softwaretool eine Eingabe an Epic zur Verfügung, die während des Schrittes 118 erkannt wird.

Dies veranlaßt den Betrieb, zum Schritt 120 überzugehen, während dem eine Ermittlung durchgeführt wird, ob für diesen bestimmten Prozeß irgendetwas anderes in der suspendierten Taskliste gespeichert war. War nichts gespeichert, dann muß bezüglich dieses Prozesses nichts weiteres erfolgen, und der Betrieb geht zum Schritt 114 zurück und wartet auf die nächste Eingabe. Ist für diesen Prozeß irgendetwas in der suspendierten Taskliste gespeichert, so geht der Betrieb zum Schritt 122 über, um Material in der momentanen Ausführungswarteschleife zu sparen. Die momentane Ausführungswarteschleife wird an einem vorbestimmten Ort in dem RAM des Prozessors gespeichert. Während dem Schritt 124, dem nächsten Schritt in dem Befehlsablauf, wird die Ausführungswarteschlange aus der suspendierten Taskliste für den Prozeß geladen, und dann geht der Betrieb zum Schritt 126 über, um sich den Inhalt der Ausführungswarteschlange anzusehen.

Wenn während des Schrittes 118 festgestellt wird, daß die Eingabe nicht von einem Beendigungsprozeß erfolgte, so geht der Betrieb zum Schritt 128 über, um die Eingabe zu lesen. Es erfolgt eine Ermittlung, entweder oder nach dem Schritt 128, ob die Eingabe von einem Whilexec-Prozeß stammt (Schritt 130). Wie voranstehend erläutert, ist ein Whilexec-Prozeß ein Prozeß, der ein Softwaretool betrifft, das bezüglich der Sprache nicht mit Epic kompatibel ist, und bei dem es daher erforderlich ist, daß sowohl Eingaben als auch Ausgaben interpretiert werden, bevor sie an das Tool ausgegeben werden. Die Interpretation kann eine Übersetzung umfassen und auch die Durchführung anderer Operationen umfassen, die dafür erforderlich sind, damit Übertragungen an das inkompatible Tool und von diesem zurück gültig sind. Die Definitionenliste der Epic-Regeln (Fig. 6) bezeichnet ein derartiges Softwaretool als eines, welches "verpackt" werden muß, wobei dies bei der bevorzugten Ausführungsform dadurch angezeigt wird, daß nicht das Wort "No Wrapper" neben dem Programmnamen in dem Definitionsabschnitt steht. Falls festgestellt wird, daß das Programm ein Whilexec-Programm oder -Prozeß ist, so wird die momentane Ausführungswarteschlange während des Schrittes 132 gerettet, und während des Schrittes 134 wird eine Ausführungswarteschlange, die vorher gespeichert wurde, auf eine nachstehend erläuterte Weise, in dem Whilexec-Tasklistenabschnitt der Prozeßliste für den bestimmten Prozeß in die Hauptausführungswarteschlange geladen. Diese Ausführungswarteschlange enthält Interpretationsregeln für den Empfang von Material von dem inkompatiblen Tool. Dann geht der Betrieb damit weiter, daß während des Schrittes 126 die Hauptausführungswarteschlange angesehen wird.

Wenn während des Schrittes 130 festgelegt wird, daß die Eingabe nicht von einem Whilexec-Prozeß stammt, so wird die Eingabe, einschließlich sämtlicher Schritte, die für die Durchführung des bestimmten eingegebenen Prozesses nötig sind, während des Schrittes 126 in die Hauptausführungswarteschlange geladen. Während dieses Schrittes wird auch die Warteschlange betrachtet. Alle Schritte, die während des Epic-Betriebs durchgeführt werden sollen, werden in die Hauptausführungswarteschlange geladen und werden von dieser Warteschlange aus nach dem Prinzip "Zuerst herein, zuerst heraus" (FIFO) ausgeführt. Wenn daher diese Warteschlange leer ist, so bedeutet dies, daß von Epic nichts weiteres durchgeführt werden muß. Daher führt der Prozeß während des Schrittes 136 eine Ermittlung durch, ob die Warteschlange leer ist. Ist die Warteschlange leer, so geht der Betrieb mit dem Schritt 137 weiter, um festzustellen, ob die Ausführungswarteschlangen gerettet wurden. Wenn daher eine Ausführungswarteschlange während beispielsweise dem Schritt 122 oder dem Schritt 132 gerettet wurde, wird während des Schrittes 137 eine Ausgabe "YES" erhalten, welche den Betriebsablauf dazu veranlaßt, zum Schritt 139 überzugehen, um die gerettete Ausführungswarteschlange in die Hauptausführungswarteschlange zu laden. Dann kehrt der Betrieb zum Schritt 126 zurück, um die Hauptausführungswarteschlange zu überprüfen. Wenn während des Schrittes 137 festgestellt wird, daß keine Warteschlange gerettet wurde, so geht der Betrieb zum Schritt 114 zurück, um auf die nächste Eingabe zu warten.

Ist die Warteschlange nicht leer, so geht der Betrieb zum Schritt 138 über, um festzustellen, ob diese Eingabe zum Aufruf eines Makros führt. Wenn während des Schrittes 138 festgestellt wird, daß diese Eingabe ein Task oder ein Prozeß ist, der zum Aufrufen eines Makros führt, dann geht der Betrieb zum Schritt 140 über, um den momentanen Inhalt der Hauptausführungswarteschlange zu retten und um das Makro für den gegebenen Task oder die gegebene Funktion während des Schrittes 142 aus der richtigen Taskliste in die Hauptausführungswarteschlange zu laden. Dann geht der Betrieb damit weiter, daß die Hauptausführungswarteschlange betrachtet wird. Da ein Makro in die Warteschlange geladen wurde, wäre diese nicht leer und würde keine weitere Tasklisteneingabe enthalten. Daher würde der Betrieb zum Schritt 144 übergehen, in welchem eine Ermittlung erfolgt, ob der nächste Gegenstand von der Hauptausführungswarteschlange ein interner Befehl ist. Ist er kein interner Befehl, dann gibt der Betriebsablauf eine entsprechende Fehleranzeige an das System und/oder den Benutzer während dem Schritt 145 aus und kehrt zum Schritt 126 zurück, um den nächsten Gegenstand in der Warteschlange zu betrachten.

Wenn während des Schrittes 144 festgestellt wird, daß der momentan betrachtete Gegenstand aus der Hauptausführungswarteschlange ein interner Befehl ist, so geht der Betrieb zum Schritt 146 über, um den Befehl auszuführen. Die Durchführung eines Befehls während des Schrittes 146 kann zum Aufruf eines weiteren Softwaretools führen, welches auf dem Prozessor 22 ablaufen soll, oder in einem anderen Gerät des Systems ablaufen soll. Es kann dazu führen, daß nur eine einzige Operation durchgeführt wird, oder zur Durchführung mehrerer Operationen. Insoweit während des Schrittes 146 festgestellt wird, daß eine Eingabe an ein inkompatibles Tool (also ein Whilexec-Tool) erforderlich ist, erscheinen Epic-Interpretationsregeln zur Durchführung einer derartigen Übertragung in dem Makro an dem Punkt, an welchem die Übertragung durchgeführt wird, oder durch eine geeignete Bezugnahme. Diese Interpretationsregeln werden auf jeden übertragenen Gegenstand von Epic an das Tool ausgeübt, so daß sämtliche Eingaben an das Tool auf eine Art und Weise behandelt werden, die sowohl für das Tool als auch für den Benutzer bzw. Operator transparent ist.

Wie voranstehend erwähnt, kann in einigen Fällen die Funktion, welche während des Schrittes 146 ausgeführt wird, bis zu ihrer Beendigung einige Stunden benötigen. Während der Schritt 146 durchgeführt wird, geht daher der Betrieb auch zum Schritt 148 über, um festzustellen, ob das System auf eine Prozeßausgabe warten möchte. Dies würde dann auftreten, wenn ein Whilexec-Tool abläuft, wobei es dann erforderlich ist, eine Ausgabe von dem Tool zu empfangen, wenn die Ausführung fertig ist, und eine Interpretation einer derartigen Ausgabe erforderlich ist, bevor sie als gültige Eingabe für Epic arbeiten kann. Gibt es während des Schrittes 148 eine Ausgabe "YES", so geht der Betrieb zum Schritt 150 über, um die Ausführungswarteschlange zur Prozeß-Whilexec-Taskliste in der Prozeßliste für den Prozeß zu bewegen, und kehrt dann zur Hauptausführungswarteschlange zurück, um andere Funktionen auszuführen, während auf eine Ausgabe von dem Whilexec-Tool gewartet wird. Ist eine Ausgabe von dem Whilexec-Tool fertig, so stellt sie eine Eingabe an das System dar und kommt durch den Schritt 114 herein. Dies wird während des Schrittes 130 erkannt und veranlaßt eine erneute Ladung der geretteten Ausführungswarteschlange während des Schrittes 134. Wie voranstehend erläutert, enthält diese gerettete Ausführungswarteschlange die Interpretationsregeln, die von der Einkapselung des Tools gefordert werden, um zu veranlassen, daß Ausgaben von dem Tool gültige Eingaben an Epic sind.

Zur selben Zeit wird auch während des Schrittes 152 eine Überprüfung durchgeführt, um festzustellen, ob darauf gewartet werden soll, daß der durchgeführte Prozeß endet. Wenn gewartet werden soll, dann wird die Ausführungswarteschlange zur suspendierten Taskliste in den Fortschrittsdateien für den durchgeführten Prozeß bewegt, und der Betrieb kehrt zur Hauptausführungswarteschlange zurück. Da die Hauptausführu 71267 00070 552 001000280000000200012000285917115600040 0002004310615 00004 71148ngswarteschlange während des Schrittes 154 geleert wurde, stellt sich während des Schrittes 136 heraus, daß die Warteschlange leer ist, und der Betrieb kehrt zum Schritt 114 zurück, um auf eine neue Eingabe zu warten. Wenn der durchgeführte Prozeß schließlich endet, so wird von Epic eine Eingabe empfangen, die während des Schrittes 118 festgestellt wird und dazu führt, daß die gespeicherte suspendierte Taskliste während des Schrittes 124 erneut in die Hauptausführungswarteschlange geladen wird.

Wenn während des Schrittes 152 festgestellt wird, daß das System nicht darauf warten will, daß der Prozeß endet, so kehrt das System zur Hauptausführungswarteschlange zurück, um den nächsten Schritt in der Warteschlange zu betrachten und, falls möglich, den Schritt auszuführen. Wenn zu diesem Zeitpunkt die Warteschlange leer ist, so geht der Betrieb zum Schritt 114 zurück, um auf die nächste Eingabe zu warten.

Auf diese Weise wird ein auf Regeln basierendes Steuersystem zur Verfügung gestellt, welches die Verwaltung durchzuführender Tasks gestattet und die zeitliche Abfolge der Tasks steuert. Weiterhin steuert das System sowohl Eingaben von bezüglich der Sprache inkompatiblen Softwaretools und Ausgaben von diesen durch Einkapseln derartiger Tools und Durchführung der erforderlichen Übersetzungen bei Eingaben und Ausgaben auf eine Weise, die für den Benutzer und die Softwaretools transparent sind. Epic ist auch dazu fähig, die anderen, nachstehend beschriebenen Softwaretools aufzurufen, soweit dies erforderlich ist, um verschiedene Übersetzungsfunktionen und Datensammelfunktionen, je nach Erfordernis, durchzuführen.

Ein Modul, welches zusammen mit Epic verwendet werden kann und welches je nach Erfordernis von unterschiedlichen Tools oder Routinen aufgerufen wird, ist das allgemeine Umbenennungsmodul (GRM), welches die Hauptübersetzungsroutinen enthält, die von dem System für Übertragungen zwischen Tools benutzt werden, welche unterschiedliche Zeichenketten (also Namen) für einen bestimmten Gegenstand oder andere Bedeutungen benutzen (also bezüglich des Namens inkompatible Tools). GRM kann auch dann verwendet werden, wenn Information auf mehreren unterschiedlichen Hierarchieniveaus in einem vorgegebenen Tool verwendet wird, oder Tools mit unterschiedlichen Namen für denselben oder einen entsprechenden Gegenstand an den unterschiedlichen Niveaus verwendet werden. Der Begriff "Bezüglich des Namens inkompatible Tools" bezeichnet manchmal auch diesen Zustand. GRM umfaßt verschiedene unterschiedliche Routinen, die durch verschiedene Anwendungsprogramme oder durch Epic je nach Erfordernis aufgerufen werden können, wenn Namensübersetzungen erforderlich sind, oder für andere Zwecke, die nachstehend erläutert werden.

Wie voranstehend erwähnt, werden GRM-Dateien im Bereich 92 gespeichert, welcher einen Regelsatz zur Durchführung von Übersetzungen zwischen jeweils zwei bezüglich des Namens inkompatiblen Softwaretools enthält, die in dem System verwendet werden können. Wenn eine Anwendung läuft, welche eine Übersetzung zwischen einem Originalnamen in einem Softwaretool, beispielsweise einem anderen Programm, welches Daten an das bestimmte Anwendungsprogramm schickt, und einem erzeugten Namen in einem zweiten Programm erfordert, welches derartige Daten empfängt, beispielsweise dem Anwendungsprogramm selbst, so fordert das Anwendungsprogramm die Erzeugung eines "Bildschirms" an, welcher die geeigneten Regeln empfängt und speichert, und auch einen Raum zur Verfügung stellt, in welchem Namensübersetzungen, die unter Verwendung der Regeln in dem Bildschirm erzeugt werden, für zukünftige Fälle gespeichert werden.

Fig. 7 ist ein Flußdiagramm der Schritte, die bei der Erzeugung eines Bildschirms zur Verwendung in einer bestimmten Übersetzung beteiligt sind. Der Prozeß beginnt mit dem Schritt 170, in welchem eine Anforderung nach einem Bildschirm von einem Anwendungssoftwaretool oder von einem der anderen Tools oder einer der anderen Routinen empfangen wird, die einen Teil der vorliegenden Erfindung bilden, beispielsweise RBI. Wird eine Anforderung empfangen, so wird eine Überprüfung durchgeführt, um zu ermitteln, ob die Benutzerregeldatei neu ist, oder - in anderen Worten - ob diese Regeln vorher verwendet wurden, um einen Bildschirm zu erzeugen (Schritt 172). Wurden die Regeln schon vorher zur Erzeugung eines Bildschirms verwendet, dann müssen bestimmte Vorlaufvorgänge nicht ausgeführt werden, und der Betrieb geht zum Schritt 174 über, um sich die Regeln zu holen, und dann zum Schritt 176, um einen Bildschirm zu erzeugen und die Regeln in dem Bildschirm zu speichern. Dann wird der Bildschirm an einem ausgewählten Ort in dem RAM des Prozessors 22 gespeichert, und dem Anwendungsprogramm wird die Adresse mitgeteilt, in welcher der Bildschirm gespeichert ist (Schritt 178).

Wenn, wie gewöhnlich, die Regeln nicht vorher in einem Bildschirm gespeichert wurden, so geht der Betrieb vom Schritt 172 zum Schritt 180 über, um verschiedene Verwaltungsfunktionen durchzuführen, die zum Öffnen des neuen Bildschirms erforderlich sind. Dann geht der Betrieb zum Schritt 182 über, in welchem die Regeln von der Datei gelesen werden, und, soweit erforderlich, in eine Form umgewandelt werden, die von GRM oder dem Anwendungsprogramm genutzt werden kann. Wenn beispielsweise der die Regeln enthaltende Bildschirm von einem Anwendungsprogramm benutzt werden soll, so kann eine gewisse Interpretation der Regeln erforderlich sein, so daß sie mit einem derartigen Programm kompatibel sind. Die modifizierten Regeln werden dann während des Schrittes 184 gespeichert und in den Bildschirm gebracht, der in dem Schritt 176 eingerichtet wurde. Dann geht der Betrieb zum Schritt 178 über, um den Bildschirm zu speichern und Information bezüglich der Adresse zur Verfügung zu stellen, in welcher der Bildschirm gespeichert ist, für geeignete Softwaretools.

Fig. 8 ist ein Flußdiagramm eines Prozesses, der dazu verwendet werden kann, für den Benutzer spezifische Daten einem Bildschirm zuzufügen oder derartige Daten aus einem Bildschirm zurückzuholen. Die Umgebung, in welcher der Prozeß von Fig. 8 eingesetzt werden kann, ist beispielsweise eine solche Umgebung, daß eine bestimmte Art von Information in dem Ursprungsprogramm durch das Programm hindurch zerstreut ist, während derartige Daten als ein Block in dem Empfangsprogramm aufrechterhalten werden. Es wäre wünschenswert, wenn derartige Daten als ein Block übertragen werden könnten, und der Bildschirm stellt eine Einrichtung zur Erreichung dieses Ziels zur Verfügung. Insbesondere kann der Systemhersteller eines Anwendungstools für das System oder möglicherweise der Toolintegrator des Benutzers feststellen, daß beim Aufruf eines bestimmten Namens, oder wenn ein bestimmter Bildschirm aufgerufen wird, ausgewählte Daten an das empfangende Tool mit dem gegebenen Namen oder durch den Bildschirm übertragen werden sollten.

In Fig. 8 gibt während des Schrittes 190 die Partei, welche die Daten hinzufügt, an, daß sie benutzerspezifische Daten einem gegebenen Namen oder Bildschirm für ein gegebenes Anwendungstool hinzufügen möchte. Während des Schrittes 192 erfolgt eine Überprüfung, um festzustellen, ob der Bildschirm in dem System existiert. Existiert der Bildschirm nicht, so stellt dies einen Fehlerzustand dar, und die Partei, welche Daten hinzufügt, wird hierüber während des Schrittes 194 informiert. Typischerweise würde diese Information durch eine geeignete Benachrichtigung auf einer Anzeige, wie Beispiel der Anzeige 30, zur Verfügung gestellt.

Existiert der Bildschirm, so geht der Betrieb zum Schritt 196 über, um zu ermitteln, ob das hinzuzufügende Material einem bestimmten Namen zugeordnet ist. Wenn das hinzugefügte Material einem bestimmten Namen zugeordnet werden soll, so wird es dem erzeugten Namen hinzugefügt, der innerhalb des Namens in dem Bildschirm gespeichert ist. Wenngleich dies nicht in Fig. 8 gezeigt ist, kann es auch einen Fehler darstellen, wenn die Daten mit einem gegebenen Namen gespeichert werden sollen und dieser Name nicht existiert. Wenn während des Schrittes 196 festgestellt wird, daß die hinzugefügten Daten nicht mit einem bestimmten Namen gespeichert werden müssen, sondern mit dem Bildschirm gespeichert werden sollen und an das empfangene Tool übertragen werden sollen, immer dann, wenn auf den Bildschirm zugegriffen wird, dann geht der Betrieb zum Schritt 200 über, um Daten dem Bildschirm zuzufügen. Unter einigen Umständen kann der Schritt 200 auch in dem Fall ausgeführt werden, in welchem der Name, mit welchem die Daten gespeichert werden sollen, nicht in dem Bildschirm existiert.

Wenn ein Anwendungsprogramm (Tool) einen bestimmten Namen oder Bildschirm anfordert, Schritt 202, führt das System eine Überprüfung durch, um festzustellen, ob der Bildschirm existiert, Schritt 204, und erzeugt ein Fehlersignal, Schritt 194, wenn der Bildschirm nicht existiert. Existiert der Bildschirm, so geht der Betrieb zum Schritt 206 über, um festzustellen, ob die Anforderung bezüglich eines Namens erfolgt. Betrifft die Anforderung einen bestimmten Namen, so werden die vorher mit diesem Namen gespeicherten Daten zurückgeholt und unter Steuerung des Anwendungsprogramms an einen geeigneten Speicherort für das Anwendungsprogramm übertragen, zusammen mit jedem erzeugten Namen für den Originalnamen, während des Schrittes 208. Ist die Anforderung bezüglich des Bildschirms und nicht bezüglich des bestimmten Namens, so werden während des Schrittes 210 die im Schritt 200 gespeicherten Daten zurückgeholt, und unter Steuerung des Anwendungsprogramms an dieses Programm übertragen.

Fig. 9 erläutert den Vorgang, der sich anschließt, wenn ein eine Übersetzung erfordernder Name zwischen zwei Softwaretools übertragen wird. Der Vorgang beginnt mit Schritt 220, der anzeigt, daß eine Namensübersetzung erforderlich ist. Vom Schritt 220 aus geht der Betriebsablauf zum Schritt 222 über, um festzustellen, ob der Bildschirm existiert. Existiert der Bildschirm nicht, so geht der Betrieb zu der Routine "Hole einen Bildschirm" zurück, die in Fig. 7 gezeigt ist, um einen Bildschirm zu erzeugen (Schritt 224).

Entweder vom Schritt 222, falls eine Ausgabe "JA" erhalten wird, oder vom Schritt 224 geht der Betrieb zum Schritt 226 über, um festzustellen, ob sich der Name in dem Bildschirm befindet. Dies bedeutet normalerweise, daß der Name vorher erzeugt wurde und daß der ursprüngliche und der erzeugte Name in dem Bildschirm für eine zukünftige Bezugnahme gespeichert wurden. Allerdings kann, wie voranstehend erwähnt, eine derartige Namensübersetzungsliste mit den Regeln zur Verfügung gestellt werden und ursprünglich in dem Bildschirm gespeichert sein. Befindet sich der Name in dem Bildschirm, so geht der Betrieb zum Schritt 228 über, um den vorher erzeugten Namen zurückzubringen, im allgemeinen zum anfordernden Anwendungsprogramm. Ist der Name nicht in dem Bildschirm, so geht der Betrieb zum Schritt 230 über, in welchem der ursprüngliche Name in den Bildschirm gebracht und ursprünglich als "einzigartig" markiert wird. Vom Schritt 230 geht der Betrieb zum Schritt 232 über, in welchem jede der Regeln in der Datei aufeinanderfolgend überprüft wird, bis alle Regeln betrachtet wurden. Für jede Regel geht der Betrieb zum Schritt 234 über, um festzustellen, ob die Regel den bestimmten Namen betrifft. Eine Regel könnte beispielsweise anzeigen, daß alle Großbuchstaben in die entsprechenden Kleinbuchstaben umgewandelt werden sollen. Wenn daher der Name in Großbuchstaben vorliegt, würde die Regel anwendbar sein, zu einer Ausgabe "JA" des Schrittes 234 führen und dazu führen, daß der Schritt 236 durchgeführt wird. Während des Schrittes 236 wird die Regel angewendet, um eine Umwandlung des Namens durchzuführen. Entweder vom Schritt 234, wenn eine Ausgabe "NEIN" erhalten wird, oder vom Schritt 236 aus geht der Betrieb zum Schritt 238 über, in welchem die nächste Regel zurückgeholt wird.

Die Regeln 232, 234, 236 und 238 werden aufeinanderfolgend für jede Regel durchgeführt, die in dem Bildschirm gespeichert ist, bis während des Schrittes 232 festgestellt wird, daß alle Regeln in dem Bildschirm durchgeführt wurden. Zu diesem Zeitpunkt wurde die Übersetzung des Namens beendet, abgesehen von verschiedenen Verwaltungsfunktionen, die während der folgenden Schritte durchgeführt werden.

Insbesondere geht, wenn alle Regeln eingesetzt wurden, der Betrieb vom Schritt 232 zum Schritt 240 über, in welchem der erzeugte Namen überprüft wird, um festzustellen, ob er irgendwelche Zeichen enthält, die in dem aufnehmenden Tool ungültig sind. Soweit derartige Zeichen gefunden werden, werden sie entfernt. Der Betrieb geht dann zum Schritt 242 über, um zu ermitteln, ob die Länge des erzeugten Namens eine Maximallänge überschreitet, die durch den Benutzer für Namen in dem empfangenden Programm festgelegt ist. Überschreitet die Länge des erzeugten Namens das Maximum, so wird der Name unter Einsatz geeigneter Abschneideregeln gekürzt. Normalerweise wird dies dadurch erreicht, daß einfach die überschüssige Anzahl an Zeichen vom Ende des Namens entfernt wird. Allerdings können kompliziertere Abschneideregeln eingesetzt werden, beispielsweise das Entfernen von Vokalen in einem ersten Abschneideschritt. Schließlich können während des Schrittes 244 irgendwelche erforderlichen Vorsilben oder Nachsilben, die vom Benutzer definiert werden, dem Namen hinzugefügt werden. Wird der Schritt 244 durchgeführt, so kann während des Schrittes 242 eine Wurzel gekürzt werden, so daß der endgültige Name nicht die Maximallänge überschreitet.

Während des Schrittes 246 erfolgt eine Ermittlung, ob eine Eins-zu-Eins-Abbildung zwischen Originalnamen und erzeugten Namen vorliegen soll. Ist eine Eins-zu-Eins-Abbildung nicht erforderlich, dann wird die Bezeichnung des Namens, die während des Schrittes 230 zur Verfügung gestellt wurde, von "Einzigartig" auf "Nicht einzigartig" während des Schrittes 248 geändert. Wogegen der erzeugte Name tatsächlich einzigartig sein kann, wird der Name als nicht einzigartig während des Schrittes 248 markiert, so daß dann, falls der erzeugte Name später auftaucht, und die spätere Erzeugung es auch zuläßt, daß sie nicht einzigartig ist, das System eine derartige Verwendung zulassen wird. Falls das System annimmt, daß die ursprüngliche Erzeugung einzigartig ist, so würde es keine spätere Erzeugung desselben erzeugten Namens zulassen.

Die voranstehenden Ausführungen werden durch den Schritt 249 erläutert, nämlich den nächsten Schritt im Betriebsablauf. Während des Schrittes 249 erfolgt eine Ermittlung, ob der erzeugte Name mit einem einzigartigen Namen kollidiert, der vorher erzeugt wurde und in der Namensliste enthalten ist. Kollidiert der Name nicht mit einem einzigartigen Namen, so geht der Betrieb zum Schritt 250 über, in welchem der erzeugte Name mit dem ursprünglichen Namen in dem Bildschirm gespeichert wird. Der neu erzeugte Name wird dann an das Anwendungsprogramm zurückgeschickt, welches ursprünglich die Anforderung ausgab, im Schritt 252. Wird während des Schrittes 249 festgestellt, daß der Name mit einem einzigartigen Namen kollidiert, so geht der Betrieb zum Schritt 256 über, um festzustellen, ob der Name so modifiziert werden kann, daß er einzigartig ist. Die Vorgänge, die während des Schrittes 256 und danach durchgeführt werden, sind in den folgenden Absätzen beschrieben.

Wird während des Schrittes 246 festgestellt, daß eine Eins-zu-Eins-Abbildung erforderlich ist, dann erfolgt im Schritt 254 eine Ermittlung, ob der erzeugte Name einzigartig ist. Ist der erzeugte Name einzigartig, dann wird der Name während des Schrittes 250 erinnert und im Schritt 252 zurückgebracht.

Ist der erzeugte Name nicht einzigartig, dann geht der Betrieb zum Schritt 256 über, um zu ermitteln, ob der Name auf eine durch den Benutzer definierte Weise geändert werden kann, insbesondere durch Regeln, die vom Toolintegrator des Benutzers erzeugt werden, oder durch Regeln, die vom Hersteller des Systems zur Verfügung gestellt werden, so daß der Name einzigartig ist. Eine derartige Änderung kann die Hinzufügung vorbestimmter zusätzlicher Zeichen zum Anfang oder Ende, vorzugsweise zum Ende, des Namens umfassen, um ihn so einzigartig zu machen. Beispielsweise können die Zahlen 0 bis 9 aufeinanderfolgend am Ende nicht einzigartiger Namen hinzugefügt werden, um derartige Namen einzigartig zu machen. Falls es nicht möglich ist, den Namen einzigartig zu machen, dann ist eine Übersetzung dieses Namens nicht möglich. Dies ist ein Fehlerzustand, Schritt 258, und dem Benutzer wird eine geeignete Anzeige dieses Fehlers gegeben, normalerweise auf der Anzeigevorrichtung 30.

Falls es möglich ist, den Namen so zu modifizieren, daß er einzigartig ist, so erfolgt eine derartige Modifikation während des Schrittes 260, um einen Namen zur Verfügung zu stellen, der einzigartig und auch in dem empfangenden Tool gültig ist. Vom Schritt 260 geht der Betrieb zum Schritt 250 über, um den erzeugten Namen zu erinnern und den erzeugten Namen an das anfordernde Tool zurückzugeben. Auf diese Weise wird ein auf verallgemeinerten Regeln basierender Übersetzungsmechanismus zur Verfügung gestellt, der sehr flexibel ist und einfach modifiziert werden kann, um irgendwelchen Änderungen in dem System gerecht zu werden.

Es gibt Situationen, in welchen ein Tool, welches einen erzeugten Namen benutzt, zu ermitteln wünscht, wie der Ursprungsname eines derartigen erzeugten Namens war, oder in welchen ein System-Operator eine derartige Information wünscht. Fig. 10 ist ein Flußdiagramm einer Routine zur Bereitstellung einer derartigen Möglichkeit.

Wenn in Fig. 10 eine Anforderung eines Ursprungsnamens erzeugt wird, Schritt 270, so geht der Betrieb zum Schritt 272 über, um festzustellen, ob sich der erzeugte Name in dem geeigneten Bildschirm befindet. Befindet sich der erzeugte Name nicht in dem geeigneten Bildschirm, was beispielsweise bedeuten kann, daß keine Übersetzungsanforderung erfolgte, die zu dem erzeugten Namen führte, dann kann die Anforderung nicht erfüllt werden, und es wird dem anfordernden Tool eine Fehleranzeige zur Verfügung gestellt, die auch dem Benutzer zur Verfügung gestellt werden kann, im Schritt 274.

Befindet sich der erzeugte Name im Bildschirm, so findet die Routine den Ursprungsnamen eines derartigen erzeugten Namens während des Schrittes 276. Im Schritt 278 erfolgt eine Ermittlung, ob der Ursprungsname für den erzeugten Namen einzigartig ist (also ob der vorgegebene erzeugte Name ein erzeugter Name für mehr als einen ursprünglichen Namen ist). Ist der ursprüngliche Name einzigartig, so wird während des Schrittes 280 der ursprüngliche Name an die anfordernde Quelle zurückgegeben. Ist der ursprüngliche Name nicht einzigartig, dann wird während des Schrittes 282 eine Liste aller ursprünglichen Namen zurückgegeben, die auf den erzeugten Namen zeigt.

Da dieselben zwei Programme in zahlreichen Fällen miteinander kommunizieren können, ist es wünschenswert, daß dann, sobald eine Liste ursprünglicher und erzeugter Namen für einen vorgegebenen Bildschirm erzeugt wurde, diese Liste aufgehoben wird, so daß sie zur Verwendung in einem darauffolgenden Bildschirm für dieselben zwei Tools verfügbar ist. Fig. 11A ist ein Flußdiagramm einer Routine zum Retten der Namensliste, die für einen vorgegebenen Bildschirm als eine Namensdatei erzeugt wurde, und Fig. 11B ist ein Flußdiagramm einer Routine zum Einlesen einer derartigen gespeicherten Namensdatei in einen neuen Bildschirm, der für Übertragungen zwischen denselben Softwaretools vorhanden ist. In Fig. 11A fordert die Routine, daß für jeden Namen in dem Originalbildschirm, Schritt 290, eine Ausgabe erzeugt wird, die auf eine durch den Benutzer festgelegte Weise formatiert wird, oder in einem Standardformat, welches durch den Hersteller des Systems festgelegt wird, und daß diese Ausgabe in eine ausgewählte Datei zum Abspeichern eingeschrieben wird (Schritt 292). Wurden sämtliche Namen in dem Bildschirm ausgegeben, so geht der Betrieb vom Schritt 290 zum Schritt 294 über, um zum vorherigen Programm zurückzukehren, welches lief. Die als Ergebnis von Fig. IIA erzeugte Datei wird manchmal als eine Alias-Datei bezeichnet.

Wenn in Fig. 11B eine Anforderung erfolgt, eine vorher gespeicherte Alias-Datei zu lesen, so ist der erste Schritt der Schritt 300, in welchem jeder Eintrag (also jeder Name) in der Datei zurückgeholt wird. Der zurückgeholte Eintrag wird in Stücke vorbestimmter Größe aufgebrochen oder auf andere Weise in einer durch den Benutzer oder das System festgelegten Art behandelt, während des Schrittes 302. Im Schritt 304 wird der behandelte Name dann dem neuen Bildschirm hinzugefügt. Die Schritte 300, 302 und 304 werden wiederholt, bis sämtliche Einträge in der Alias-Datei in dem Bildschirm gespeichert wurden, und dann verzweigt der Betrieb vom Schritt 300 zum Schritt 306 und veranlaßt den Betrieb dazu, zu dem ursprünglichen Tool zurückzukehren.

Zusätzlich zur Anforderung, inkonsistente Namen zwischen Softwaretools zu übersetzen, gibt es darüber hinaus Situationen, in welchen das Format zwischen zwei Programmen nicht kompatibel ist, und modifiziert werden muß, um kompatibel zu sein. Beispielsweise kann ein Tool Information in einem schematischen Grafikdiagramm präsentieren, wie beispielsweise in Fig. 14 gezeigt. Ein anderes Programm kann wünschen, dieselben Daten in einer Netzlistenform zu verwenden, in welcher Bestandteile und Knoten definiert werden, und in welcher für jeden Bestandteil eine Anzeige bezüglich der Knoten und/oder anderer Komponenten zur Verfügung gestellt wird, zwischen die er geschaltet ist. Das erfindungsgemäße System stellt eine Routine zur Verfügung, die als Regelbasisschnittstellenroutine (RBI) bezeichnet wird, welche derartige Transformationen durchführt, und auch zur Durchführung von Standardtransformationen eingesetzt werden kann, soweit dies nötig ist, beispielsweise zwischen inkompatiblen Befehlen zur Durchführung derselben Funktion in den beiden Sprachen. Fig. 1 ist ein Flußdiagramm der RBI-Routine.

In Fig. 12 wird der Betrieb durch die RBI-Routine gestartet, die durch Epic oder ein anderes Programm aufgerufen wird, welches auf dem System läuft, oder als Ergebnis einer Benutzereingabe. Dies wird als der Startschritt 310 in Fig. 12 bezeichnet.

Der erste Schritt im Betrieb, Schritt 312, besteht darin, daß verschiedene Optionen gelesen und an einem geeigneten Ort in dem RAM gespeichert werden, welches zum Speichern von Information für die RBI-Routine verwendet wird. Optionen, Schemata, Signalformen und dergleichen werden manchmal nachstehend als "Objekte" bezeichnet, wobei Objekte Elemente sind, die entweder vom Hersteller des Systems oder Benutzer (Optionen) oder von einem anderen Programm (schematische Komponenten, Signalformen usw.) zur Verfügung gestellt werden, bei welchem die durch RBI bereitgestellten Umwandlungsregeln eingesetzt werden.

Während des Schrittes 314, dem nächsten Schritt im Betrieb, wird die geeignete RBI-Regeldatei oder Dateien, die im Bereich 96 des Speichers 28 gespeichert ist, in einen geeigneten Abschnitt des Prozessorspeichers eingelesen. Während des Schrittes 316 erfolgt eine Überprüfung der Regeln, um sicherzustellen, daß sie korrekte Zeichen an korrekten Orten verwenden, und im Zusammenhang der RBI-Routine gültig sind. Die Regeln sollten gültig sein, jedoch ist es immer möglich, daß sich aus verschiedenen Gründen ein Fehler entwickelt, und es ist daher anzuraten, eine semantische Überprüfung durchzuführen, bevor die Regeln verwendet werden.

Während des Schrittes 318, dem nächsten Schritt im Betrieb, wird die angeforderte Datenbasis, die umgewandelt werden soll, in das System eingelesen und ebenfalls jede externe erforderliche Information, die zur Umwandlung nötig ist. Beispielsweise kann ein GRM-Bildschirm, der auf die voranstehend erläuterte Weise erzeugt wurde, zur Verwendung durch das RBI-Programm zur Verfügung gestellt werden.

Sobald diese einleitenden Betriebsschritte durchgeführt wurden, geht das Programm zum Schritt 320 über, in welchem es mit der Bearbeitung von Regeln beginnt, beginnend mit dem ersten oder obersten Datenbasisobjekt und der ersten Regel. Wie voranstehend erläutert, stellen die Datenbasisobjekte die schematischen Zeichen, Signalformen, Netzlisteneinträge oder Optionen dar, die von dem Benutzer oder anderen eingegeben wurden, und deren Umwandlung erforderlich ist. Vom Schritt 320 aus geht der Betrieb zum Schritt 322 über, in welchem die nächste Regel, in diesem Fall die erste Regel, in ein Register "momentane Regel" übertragen wird. Während des Schrittes 324 erfolgt eine Überprüfung, ob das momentane Regelregister leer ist. Ist das momentane Regelregister leer, so bedeutet dies, daß sämtliche Regeln betrachtet wurden und der Vorgang beendet ist. Dies veranlaßt den Betrieb dazu, zum Schritt 326 zu verzweigen, um das Ergebnis des RBI-Vorgangs oder eines Teils davon auszudrucken, oder anderes Material, welches die Routine ausdrucken soll. Alternativ hierzu kann dieses Material auch nur gespeichert werden, beispielsweise an einem geeigneten Ort im Speicher 28, ohne ausgedruckt zu werden. Sobald der Schritt 326 beendet ist, so verläßt das System die RBI-Routine durch den Schritt 328 und informiert Epic oder ein anderes Programm, welches den Ablauf von RBI gefordert hatte, und/oder den Benutzer, daß dieser Vorgang beendet ist.

Wenn während des Schrittes 324 festgestellt wird, daß das momentane Regelregister nicht leer ist, etwa in einem Fall, wenn in dieses die erste Regel geladen wurde, so geht der Betrieb vom Schritt 324 zum Schritt 330 über, um zu ermitteln, ob dies eine "Bildschirm"-Regel ist. Es gibt im wesentlichen zwei Arten von Regeln in der RBI-Routine, die als "Bildschirmregeln" und "Beendigungsregeln" bezeichnet werden. Eine Beendigungsregel betrifft im allgemeinen einen einzigen Befehl, der sofort ausgeführt werden kann. Im Gegensatz hierzu betrifft eine Bildschirmregel im allgemeinen zwei oder mehr Befehle und kann auch eine Verzweigung oder andere Faktoren umfassen. Jede Regel, die keine "Bildschirmregel" ist, ist eine "Beendigungsregel". Falls daher während des Schrittes 330 festgestellt wird, daß die Regel keine Bildschirmregel ist, dann geht der Betrieb zum Schritt 332 über, um den einzigen Befehl der Beendigungsregel auszuführen, und kehrt dann zum Schritt 322 zurück, um die nächste Regel in die Warteschlange in dem momentanen Regelregister zu laden.

Wenn im Schritt 330 festgestellt wird, daß die Regel in dem momentanen Regelregister eine "Bildschirm"-Regel ist, dann geht der Betrieb zu einem von verschiedenen Schritten über, abhängig von der Art der Bildschirmregel, die empfangen wurde. Es gibt grundsätzlich fünf Arten von Bildschirmregeln, die empfangen werden können. Zwei der Arten an Bildschirmregeln betreffen den Anfang bzw. das Ende einer Vierersequenz. Diese sind in Fig. 12A durch den Befehl oder die Regel "for all (nets)" und für die Regel "for all (symbols)", angegeben, die dieser folgt. Später gibt es auch eine Regel "for_bar all (ports)". Diese Regeln geben an, daß für sämtliche in den Klammern angegebenen Objekte die folgenden Regeln angewendet werden sollen, und eine alles beendende Regel wird durch den Ports-Befehl "thin_for_all bracket" und durch den ähnlichen Beendigungsbefehl für (Symbole) und (Netze) in Fig. 12A angezeigt. Dies sind die Regeln, welche eine Sequenz "for_all" beenden.

Zwei andere Arten von Befehlen entstehen aus einer "if"-Sequenz, von denen zwei in Fig. 12A gezeigt sind. Jede "if"-Sequenz beginnt mit dem Wort "if" ("wenn"), gefolgt von dem Objekt, auf welches "if" ausgeübt werden soll und welches in Klammern angegeben ist. Dann folgen eine oder mehrere Regeln und die "if"-Sequenz wird beendet durch die Regel "fin_if", die ebenfalls das Objekt umfaßt.

Die endgültige Art einer Regel ist eine Bildschirmbruchregel. Dies ist eine Regel, welche untersucht, ob eine bestimmte Bedingung erfüllt ist, und die dann, falls die Bedingung erfüllt wurde, die übrigen Befehle des Bildschirms umgeht; oder, in anderen Worten, verhindert, daß der Rest der Regel durchgeführt wird. Eine Bruchregel ist nicht besonders in Fig. 12A angegeben.

Falls in Fig. 12 im Schritt 330 ermittelt wurde, daß die Bildschirmregel ein Anfang einer Bildschirmregel ist, so geht der Betrieb zum Schritt 334 über, um das nächste Objekt der Art zu holen, die in der "for"-Regel angegeben wird. Beispielsweise mit dem Befehl "for_all_nets" wird während des Schrittes 334 das nächste "Netz" im Schritt 334 zurückgeholt. Vom Schritt 334 geht der Betrieb zum Schritt 336 über, um festzustellen, ob sämtliche Objekte der angegebenen Art angesehen wurden. Wurden nicht sämtliche Objekte angesehen, so wird die nächste Regel innerhalb des "for"-Bildschirms während des Schrittes 338 erhalten, und diese Regel wird in die momentanen Regeln geladen, wenn der Betrieb zum Schritt 322 zurückkehrt. Während des nächsten Zyklus wird das Objekt durch diese Regel betrachtet und durch die Regel bearbeitet. Wird im Schritt 338 für ein gegebenes Objekt "fin_for_all" erreicht, so wird diese Regel während des Schrittes 340 erkannt und veranlaßt, daß das nächste Objekt der in der letzten "for"-Regel festgelegten Art zurückgeholt wird. Dann erfolgt eine Ermittlung, ob das Objekt leer ist, und die "for"-Bildschirmregeln werden auf das neue Objekt ausgeübt, wenn es nicht leer ist, durch einen Kreislauf durch die geeigneten Schritte, und eine Beendigung durch die Beendigungs- und Bildschirmregel. Sobald vom Schritt 340 aus der Schritt 336 erreicht ist und festgestellt wird, daß das Objekt leer ist, so geht der Betrieb zum Schritt 342 über, um zum Ende der "for"-Bildschirmregel überzugehen und so diese Regel zu verlassen.

Entsprechend geht, wenn die ankommende Bildschirmregel während des Schrittes 330 als eine beginnende "if"-Bildschirmregel erkannt wird, der Betrieb zum Schritt 344 über, um festzustellen, ob die "if"-Bedingung wahr ist. Ist die "if"-Bedingung nicht wahr, so geht der Betrieb zum Schritt 346 über, welcher den Betrieb dazu veranlaßt, die erste Regel auszuführen, die dem Ende des "if"-Bildschirms folgt, und der Betrieb kehrt zum Schritt 322 zurück, um diese Regel als die nächste Regel in dem momentanen Regelregister anzuordnen.

Ist die "if"-Bedingung wahr, so geht der Betrieb zum Schritt 348 über, um die Regel innerhalb des "if"-Bildschirms zu erhalten, und diese Regel als die nächste Regel in dem momentanen Regelregister anzuordnen. Dann kehrt der Betrieb zum Schritt 322 zurück, um zu veranlassen, daß diese Regel ausgeführt wird. Ist die Regel innerhalb des "if"-Bildschirms die Regel zur Beendigung des "if-Bildschirms", so geht der Betrieb vom Schritt 330 zum Schritt 350 über, um die nächste Regel außerhalb des "if"-Bildschirms zu holen, und diese Regel als die nächste Regel in das momentane Regelregister zu bringen, und dann kehrt der Betrieb zum Schritt 322 zurück, um die Ausführung dieser Regel zu veranlassen.

Wenn schließlich im Schritt 330 festgestellt wird, daß die Regel eine Bildschirmbruchregel ist, so geht der Betrieb zum Schritt 352 über, um zu ermitteln, ob die Bruchbedingung wahr ist. Ist die Bruchbedingung wahr, dann geht der Betrieb zum Ende des Bildschirms über, oder holt sich, mit anderen Worten, die erste Regel außerhalb des Bildschirms, während des Schrittes 354, und diese Regel wird die nächste Regel in dem momentanen Regelregister. Dann kehrt der Betrieb zum Schritt 322 zurück. Entsprechend wird, wenn im Schritt 352 keine Ausgabe erfolgt, die nächste Regel während des Schrittes 356 zurückgeholt, als die nächste Regel in das momentane Regelregister geladen, und dann kehrt der Betrieb zum Schritt 322 zurück, um diese Regel auszuführen.

Wie voranstehend erläutert, steuern die RBI-Regeln Formatumwandlungen zwischen den beiden betrachteten Programmen, so daß Objekte in einem der Tools in das geeignete Forma für das andere Tool umgewandelt werden. Die Regeln können auch bei Objekten angewandt werden, die Standardbefehle oder andere Gegenstände in einem der Tools sind, die so umgewandelt werden müssen, daß sie bei dem anderen Tool arbeiten.

Eine weitere Anforderung an ein System, welches den Betrieb einer großen Anzahl an Softwaretools steuern soll, ist die Fähigkeit, interaktiv Information zu sammeln, die von diesen Tools in jeder Stufe ihres Betriebs gefordert werden. Derartige Information kann vom Benutzer des Systems, vom Bediener oder von anderen Tools in dem System erlangt werden. Wird die Information von dem Bediener erlangt, so ist es vorzuziehen, daß der Bediener so wenig Information wie möglich zur Verfügung stellt, wobei Standardeingaben für die meisten der geforderten Eingaben verfügbar sind, und daß der Benutzer dazu aufgefordert wird, alle geforderten Eingaben zur Verfügung zu stellen. Dem Benutzer können auch sämtliche wahlweisen Eingaben angezeigt werden, die in dieser Stufe verfügbar sind. Vorzugsweise geht das System nicht mit dem angezeigten Vorgang weiter, bis der Benutzer sämtliche geforderten Eingaben zur Verfügung gestellt hat und diese Eingaben gültig sind.

Die Routine, die die voranstehend beschriebenen Funktionen zur Steuerung, andere nicht-grafische Eingaben und möglicherweise für bestimmte Arten grafischer Eingaben zur Verfügung stellt, wird als die Designüberprüfungs- oder dv-Routine bezeichnet. Fig. 13 ist ein Flußdiagramm dieser Routine, und Fig. 14 ist eine erläuternde Anzeige, die unter Verwendung dieser Routine erhalten wird.

In Fig. 13 geht das Programm mit dem Startschritt 360 von Epic oder einem anderen geeigneten Softwaretool los, welches auf dem System läuft. dv kann immer dann aufgerufen werden, wenn es erforderlich ist, interaktiv Daten oder anderes geeignetes Material in das System einzugeben.

Der nächste Schritt im Betriebsablauf, Schritt 362, ist das Einlesen von Grafik- und Menüinformation für dv, die an einem geeigneten Ort im Bereich 95 des Speichers 28 gespeichert ist, und die Anzeige der grundlegenden dv-Ikonanzeige. Die dv-Ikons sind im Bereich 364 in Fig. 14 gezeigt, und dieser Abschnitt der in Fig. 14 gezeigten Anzeige ist das, was ursprünglich auf dem Bildschirm der Anzeigevorrichtung 30 erscheinen würde.

Das System liest dann die Epic-Regeln, die für diesen Task geeignet sind, vom Bereich 90 des Speichers 28 ein und speichert diese Regeln als eine verstandene Task-Liste, deren Funktion später beschrieben wird (Schritt 366). Während des Schrittes 368, dem nächsten Schritt im Betrieb, liest das System die dv-Regeln aus dem Bereich 94 des Speichers 28, oder zumindest den Anteil dieser Regeln, die für das momentan laufende Softwaretool oder die momentan laufenden Softwaretools relevant sind, und speichert diese Regeln als eine Task-Befehlsliste. Diese Regeln definieren spezielle Befehle für das betreffende Tool und enthalten u. a. Standardeingaben für unterschiedliche Stufen in dem Tool. Ein beispielhafter Abschnitt einer dv-Regeldatei ist in Fig. 13A gezeigt.

Dann liest das System die schematischen Designdateien während des Schrittes 370. Dies sind Dateien, die Information betreffend das betrachtete Schema enthalten, einschließlich beispielsweise einer Erläuterung der Bedeutung jedes Kastens in einem Schema. Die schematischen Designdateien werden ebenfalls an einem geeigneten Ort in dem RAM des Prozessors 22 gespeichert.

Soweit ein ähnlicher Task vorher durchgeführt wurde und irgendwelche Information, die bei einem derartigen vorherigen Lauf erzeugt wurde, für zukünftige Bezugnahme gespeichert wurde, wird derartige Information ebenfalls zurückgeholt und im Schritt 372 in das RAM des Prozessors eingeschrieben. Wenn daher die Schritte 362 bis 372 beendet sind, hat das System eine erhebliche Menge an Informationen und Regeln angesammelt, die erforderlich sein können, um die dv-Funktion durchzuführen. Es wird darauf hingewiesen, daß zwar die Information in einer bestimmten Reihenfolge in Fig. 13 zurückgeholt und gespeichert wurde, daß diese Reihenfolge allerdings nur zum Zwecke der Erläuterung angegeben ist, und daß die Information in jeder gewünschten Reihenfolge zurückgeholt und gespeichert werden kann.

Der nächste Schritt im Betrieb ist der Schritt 374, in welchem ein Kanal geöffnet wird, um mit Epic zu kommunizieren. Dies ist ein bidirektionaler Kanal. Falls dieser Kanal nicht geöffnet werden kann, wird das Programm abgebrochen.

Sobald die voranstehend beschriebenen, einleitenden Funktionen beendet sind, geht der Betrieb mit dem Schritt 376 weiter und wartet auf eine Eingabe. Nichts weiteres passiert, bis eine Ausgabe "JA" im Schritt 376 erhalten wird, die anzeigt, daß eine Eingabe empfangen wurde. Wenn eine Eingabe empfangen wird, geht der Betrieb zum Schritt 378 weiter, um zu ermitteln, ob die Eingabe eine Eingabe in bezug auf "Aussteigen" ist. Ist die Eingabe eine Ausstiegseingabe, die anzeigt, daß dv aufgerufen werden soll, so geht der Betrieb zum Schritt 380 über, um zu ermitteln, ob der Benutzer die Umgebung speichern möchte. Der Schritt 380 stellt die Fähigkeit zur Verfügung, entweder ausgewählte Tasks oder Regeln zu speichern, die von dem Benutzer modifiziert wurden, oder jedes andere Material zu speichern, welches von dem Systemintegrator in den Regeln oder Makros festgelegt wurde, und zwar durch den System-Operator oder den Hersteller des Systems in dem mit dem System bereitgestellten Material. Wenn Information gespeichert werden soll, so geht der Betrieb zum Schritt 382 über, um die angegebene Information zu speichern. Vom Schritt 380, falls eine Ausgabe "NEIN" erhalten wird, oder vom Schritt 382 geht der Betrieb zum Schritt 384 über, um aus der dv-Routine auszusteigen oder diese zu verlassen. Das Umgebungsmaterial, welches während des Schrittes 382 gespeichert wurde, ist dann das Material, welches während des Schrittes 372 gespeichert wird, wenn das Tool das nächste Mal abläuft.

Wird im Schritt 378 eine Ausgabe "NEIN" erhalten, wie dies normalerweise der Fall ist, so geht der Betrieb zum Schritt 386 über, um zu ermitteln, ob die Eingabe eine solche Eingabe ist, die durch Epic (also das in Fig. 4 gezeigte Programm) durchgeführt werden soll, anstatt durch dv. Dies wird unter Verwendung der Epic-Regeln ermittelt, die während des Schrittes 366 gespeichert wurden. Ist das Programm ein Programm, welches von Epic durchgeführt werden soll, so wird der Task an Epic (Schritt 388) durch den Kanal geschickt, der während des Schrittes 374 eingerichtet wurde. Vom Schritt 388 kehrt das System zum Schritt 376 zurück, um auf eine neue Eingabe zu warten.

Falls der Task nicht durch Epic durchgeführt werden soll, geht der Betrieb zum Schritt 390 über, um festzustellen, ob der Task ein dv-Befehl ist. Ist der Task weder ein dv- oder ein Epic-Befehl, dann liegt ein Fehler vor, der dem System und/oder dem Benutzer während des Schrittes 392 auf geeignete Weise angezeigt wird. Vom Schritt 392 geht der Betrieb zum Schritt 376 zurück, um auf eine neue Eingabe zu warten. Die neue Eingabe kann beispielsweise eine Eingabe von dem Benutzer sein, welche den Fehler korrigiert.

Ist der Befehl ein dv-Befehl, so geht der Betrieb zum Schritt 394 über, um die Art des dv-Befehls zu ermitteln, der empfangen wurde. Es gibt drei grundlegende Arten an dv-Befehlen, die allgemein bezeichnet sind als "Informationssammlung", "Übersetzung" und "Design-Lesen". Es wird anfänglich angenommen, daß während des Schrittes 394 ermittelt wird, daß der Befehl der Design-Lesebefehl ist. Unter dieser Bedingung geht der Betrieb zum Schritt 396 über, um das spezifische schematische Diagramm zu lesen und zu speichern, welches an diesem Punkt des Betriebs des Tools erzeugt wurde, beispielsweise das auf dem Bildschirm in Fig. 14 gezeigte schematische Diagramm, und auch die GRM-Alias-Information zu lesen und zu speichern für ein derartiges Tool, und für ein Tool, an welches das Schema übertragen werden soll, oder die GRM-Alias-Information zwischen dem Schema an seinem Hierarchieniveau und einem höheren oder niedrigeren Hierarchieniveau, auf welches das Schema übertragen werden soll. Die während des Schrittes 396 gespeicherte Information wird durch spätere Befehle genutzt, um die gewünschte Wandlung durchzuführen. Vom Schritt 396 kehrt der Betrieb zum Schritt 376 zurück, um auf eine neue Eingabe zu warten.

Falls festgestellt wird, daß die Eingabe ein Übersetzungsbefehl ist, so bedeutet dies, daß eine Übersetzung für ein bestimmtes schematisches Element oder Bestandteil oder auf einem anderen Element oder Bestandteil ausgeübt werden soll, welches dem Benutzer angezeigt wird. Während des Schrittes 398 wird der Benutzer dazu aufgefordert, den Bestandteil oder das andere Element anzugeben, auf welchem die Operation durchgeführt werden soll. Sobald der Benutzer diesen Vorgang beendet, greift während des Schrittes 400 in Reaktion auf die Benutzereingabe dv auf die Datenbasis zu, die während des Schrittes 396 oder 370 gespeichert wurde, um den angegebenen Gegenstand zu übersetzen. Während des Schrittes 402 wird der übersetzte Gegenstand an Epic geschickt, falls dies geeignet ist, und zwar über den während des Schrittes 374 erzeugten Kanal. Einige übersetzte Gegenstände werden nur in dv gespeichert oder können so auf andere Weise umgeleitet werden, wie das durch dv-Regeln angezeigt ist, oder woanders hin. Sobald der Schritt 402 beendet ist, kehrt der Betrieb zum Schritt 376 zurück, um auf eine neue Eingabe zu warten.

Falls festgestellt wird, daß der dv-Befehl ein Informationssammelbefehl ist, so geht der Betrieb vom Schritt 394 zum Schritt 404 über, in welchem dem Benutzer auf dem Bildschirm des Anzeigegerätes 30 eine Standardtaskbefehlseinstellung gezeigt wird, welche die folgenden drei Elemente enthalten kann:

1. Eine Liste von Standardangaben, die für die gegebene Stufe im Betrieb des Softwaretools geeignet ist. Diese werden durch den Systemintegrator des Benutzers oder durch den Hersteller des Systems zur Verfügung gestellt.
2. Eine Anzeige von Eingaben, bei denen es erforderlich ist, daß sie vom Benutzer zur Verfügung gestellt werden. Dies können beispielsweise bestimmte Werte für Bauteile sein, beispielsweise Widerstands- oder Kapazitätswerte.
3. Wahlweise Eingaben, die von dem Benutzer in dieser Stufe des Betriebs des Softwaretools zur Verfügung gestellt werden können, wobei das System jedoch auch ohne diese Eingaben weitermachen kann. Dies kann beispielsweise eine Anzeige eines Herstellers für ein Bauteil oder eine Farbkodierung von Drähten sein, die an diesem Punkt in das Design eingeführt werden könnten, die jedoch nicht erforderlich sind.

Der Benutzer kann eine oder sämtliche Standardeingabe akzeptieren oder diese ändern, muß erforderliche Eingaben für den Fortgang des Betriebs hinzufügen und kann irgendeine der wahlweisen Eingaben hinzufügen. Während des Schrittes 406 erfolgt eine Festlegung, ob der Benutzer irgendwelche Änderungen vorgenommen hat. Hat der Benutzer Änderungen vorgenommen, so geht der Betrieb zum Schritt 408 über, um die Änderungen in die interne Umgebung zu übernehmen, nämlich die Änderungen an dem geeigneten Ort im Speicher aufzuzeichnen. Vom Schritt 406 aus, falls eine Ausgabe "Keine Änderungen" vorliegt, oder vom Schritt 408 aus, geht der Betrieb mit dem Schritt 410 weiter, um zu ermitteln, ob sämtliche erforderlichen Änderungen durchgeführt wurden. Wurden nicht alle erforderlichen Änderungen durchgeführt, so geht der Betrieb zum Schritt 412 über, in welchem der Benutzer dazu aufgefordert wird, erforderliche Änderungen vorzunehmen. Dies umfaßt die Eingabe erforderlicher Eingaben an den angegebenen Orten. Die Aufforderung kann durch irgendeine geeignete Weise durchgeführt werden, beispielsweise durch Blinken oder eine andere Hervorhebung einer erforderlichen Änderung oder Eingabe, die noch nicht gemacht wurde. Vom Schritt 412 geht der Betrieb zum Schritt 406 über, um festzustellen, ob der Benutzer Änderungen durchgeführt hat, und über die Schritte 408 und 410 zu ermitteln, ob nunmehr alle erforderlichen Änderungen durchgeführt wurden.

Wurden alle erforderlichen Änderungen durchgeführt, so geht der Betrieb zum Schritt 414 über, um den geeigneten Epic-Task zu ermitteln, beispielsweise den vom Benutzer ausgewählten Task. Dieser Epic-Task wird dann im Schritt 402 an Epic geschickt, falls dies geeignet ist, zusammen mit Information, die mittels dv über den Kanal gesammelt wurde, der während des Schrittes 374 eingerichtet wurde, und dann kehrt der Betrieb zum Schritt 376 zurück, um auf die nächste Eingabe zu warten.

Das voranstehend beschriebene dv-Programm ist dazu ausgebildet, alphanumerische und andere Steuerinformation von einem Benutzer zu sammeln. Allerdings ist es beim Entwurf elektronischer Schaltungen und insbesondere bei der Durchführung von Simulationsprogrammen im Zusammenhang mit derartigen Entwürfen häufig erforderlich, ausgewählte Grafikdaten und insbesondere bestimmte analoge oder digitale Signalformen in das System einzugeben. Bezüglich dv ist es wünschenswert, daß der Benutzer dazu aufgefordert wird, solche Grafikdaten, soweit erforderlich, zur Verfügung zu stellen- daß für den Benutzer in den meisten Situationen Standardeingaben verfügbar sind, und daß der Gesamtbetrieb für den Operator so einfach und narrensicher wie möglich ist. Es ist ebenfalls wesentlich, daß die Routine dazu ausgebildet ist, mit Softwaretools von verschiedenen unterschiedlichen Quellen zu arbeiten, welche Signalformen in verschiedenen Sprachen zur Verfügung stellen können, unterschiedliche Namen benutzen und/oder unterschiedliche Formate einsetzen, und daß Übersetzungen oder Interpretationen durch das System auf eine Weise zur Verfügung gestellt werden, die sowohl für den Benutzer als auch für den Simulator oder ein anderes Softwaretool transparent ist, für welches Information gesammelt wird. Der Bediener (Operator) sollte die Wahl haben, entweder bereits existierende Signalformen auszuwählen oder andere Grafiken oder seine eigene Signalform auf dem Bildschirm der Anzeigevorrichtung 30 zu zeichnen, beispielsweise unter Benutzung der Maus 26.

Die erfindungsgemäße Routine, welche die verschiedenen, voranstehend angegebenen Fähigkeiten zur Verfügung stellt, wird als "Wavedit" bezeichnet. Zwar erfolgt die Erläuterung in bezug auf "Wavedit" in bezug auf Signalformeingaben, jedoch ist es offensichtlich, daß die beschriebenen Vorgehensweisen auch für andere Arten grafischer Eingaben verwendet werden könnten. Ein Flußdiagramm der Wavedit-Routine ist in Fig. 15 gezeigt, und Flußdiagramme unterschiedlicher Unterprogramme dieser Routine sind in den Fig. 16 bis 19 gezeigt.

Wie zuerst aus Fig. 15 hervorgeht, gelangt man in die Routine durch den Schritt 420. Der Eingang in die Routine kann in Reaktion auf eine Eingabe von Epic erfolgen, von einer der anderen Routinen oder einem der anderen Softwaretools, die auf dem System laufen, beispielsweise ein Simulator, der grafische Eingaben erfordert, oder in Reaktion auf eine geeignete Eingabe von dem Operator. Typischerweise gelangt man in Wavedit in Reaktion auf einen Befehl von einem Makro der Epic-Routine, die zur Durchführung einer Simulationsfunktion läuft.

Nach dem Eingang in Wavedit besteht der erste Schritt, Schritt 422, darin, interne Daten zu initialisieren. Dies erfolgt automatisch in Reaktion auf Befehle, welche einen Teil der Wavedit-Routine bilden, und führt zum Einlesen erforderlicher Daten in das System aus den Wavedit-Dateien 98, um die Erzeugung einer Standardanfangsanzeige hervorzurufen, einschließlich einer Standardsignalform oder von Standardsignalformen und eines Standardmenüs. Die Standardanzeige kann übersteuert werden, wie nachstehend erläutert wird, nämlich durch Benutzereingaben.

Während des Schrittes 424, dem nächsten Schritt im Betriebsablauf, werden verschiedene Konfigurationsdateien in das System eingelesen. Fig. 16 stellt ein detaillierteres Flußdiagramm der Operationen dar, die im Zusammenhang mit dem Schritt 424 durchgeführt werden. In Fig. 16 ist der erste Schritt 426 das Öffnen einer Zustandsdefinitionsdatei. Die Zustandsdefinitionsdatei stellt Werte zur Verfügung, die für jeden digitalen Zustand angezeigt werden sollen, der in einer zu erzeugenden digitalen Signalform auftauchen kann. Als Minimum werden zwei digitale Zustände, 0 und 1, definiert. Jedoch können verschiedene Anstiegs- und Abfallzustände, ebenso wie andere digital definierte Zustände, die im Stand der Technik bekannt sind, in dem System verwendet werden. Jeder Zustand, der zusammen mit einem speziellen Ablauf der Wavedit-Routine verwendet werden soll, muß während des Schrittes 424 definiert werden. Typischerweise gibt es Standarddefinitionen für zumindest die binären Zustände 0 und 1. zusätzliche Standarddefinitionen können zur Verfügung gestellt werden. Diese sind verfügbar, wenn im Schritt 426 eine Zustandsdefinitionsdatei geöffnet wird, und werden während der Schritte 428 und 430 in das System eingelesen. Jede Definition in der Zustandsdefinitionsdatei gibt an, wie der Zustand beim Zeichnen aussieht, wie das System den Zustand identifiziert, und wie das System den Zustand betreffende Information weitergeben soll. Der Benutzer kann entweder die Standarddefinitionen akzeptieren oder eigene Definitionen auf geeignete Weise eingeben. Während des Schrittes 428 erfolgt eine Ermittlung, ob sämtliche Definitionen für den speziellen Ablauf der Wavedit-Routine eingegeben wurden, und im Schritt 430 wird eine zusätzliche Definition in die Tabelle eingelesen, falls noch nicht alle Definitionen gelesen wurden. Die Schritte 428 und 430 werden wiederholt, bis alle Definitionen eingegeben wurden, die für den speziellen Ablauf der Routine erforderlich sind.

Wurden alle Zustandsdefinitionen eingegeben, so geht der Betrieb zum Schritt 432 über. Während des Schrittes 432 erfolgt eine Ermittlung, ob sämtliche zustandslogikregeln aus dem Bereich 98 des Speichers in den RAM des Prozessors 22 eingelesen wurden. Zustandslogikregeln sind beispielsweise Regeln zur Durchführung Bool′scher Algebra, oder andere Regeln, welche potentielle Wechselwirkungen zwischen Signalformen definieren. Falls während des Schritts 432 festgestellt wird, daß noch nicht sämtliche zustandslogikregeln gelesen wurden, so geht der Betrieb zum Schritt 434 über, um zusätzliche Logikregeln in eine interne Logikregeltabelle in einem geeigneten Wavedit-Bereich eines RAM des Prozessors 22 einzulesen. Die Schritte 432 und 434 werden wiederholt, bis ermittelt wird, daß sämtliche Logikzustandsregeln eingelesen wurden, und zu diesem Zeitpunkt geht der Betrieb zum Schritt 436 über, um die Definitionsdateien zu schließen.

Dann geht der Betrieb zum Schritt 438 über, um eine Filterlistendatei zu öffnen. Die Filterlistendatei enthält Informationen, welche es Wavedit gestatten, Eingaben von oder Übertragungen an ihre Ausgänge zu Softwaretools, im allgemeinen Simulatortools zu empfangen, welche bezüglich der Sprache oder des Formats mit Wavedit nicht kompatibel sind. Insbesondere gibt die Filterlistendatei ein Softwaretool an, welches dazu verwendet werden kann, geeignete Übersetzungen zwischen Wavedit und den externen Tool durchzuführen. Eine derartige Übersetzungsroutine kann RBI sein, oder ein anderes Übersetzungstool, welches in dem System verfügbar ist. Sobald eine Filterliste in einem geeigneten Bereich im RAM des Prozessors 22 geöffnet wurde, führt der Betriebsablauf die Schritte 440 und 442 durch, um zu ermitteln, ob es weitere Filterspezifikationen gibt, die aus dem Bereich 98 ausgelesen werden sollten, oder aus einem anderen geeigneten Ort, und zwar in die Filterlistendatei, und um die Filterspezifikationen in die interne Filterlistendatei einzulesen, bis sämtliche Filterspezifikationen in diese Datei eingelesen wurden. Falls dies auftritt, wird während des Schrittes 444 die Filterdatei geschlossen.

Vom Schritt 444 geht der Betrieb zum Schritt 446 über, um Menüdateien in einen geeigneten Bereich in dem RAM des Prozessors für Wavedit einzulesen. Hier handelt es sich um verschiedene Menüs, die auf dem Bildschirm der Anzeigevorrichtung 30 während des Ablaufs der Wavedit-Routine erscheinen können. Die Menüs sind typischerweise Menüs aus Ikons. Der Lesemenüdateischritt umfaßt typischerweise auch eine Öffnung der Datei, eine Ermittlung, ob es mehr zu lesende Menüs gibt, ein Ablesen der Menüs und Schließen der Datei ebenso wie bei den vorherigen zwei Dateien, jedoch wurde zum Zwecke der Vereinfachung des Diagramms dieser Betrieb nur als ein einziger Schritt in Fig. 16 gezeigt.

Entsprechend wurde der Leebefehlsquellendateischritt 484 auch nur als ein einziger Schritt gezeigt, obwohl er auch vier getrennte Schritte umfassen würde. Die Befehlsquellendatei definiert Makros zur Verwendung beim Ablauf von Wavedit. Diese Makros, wie diejenigen für Epic, enthalten eine Schrittsequenz zur Durchführung einer bestimmten Funktion und sind in einer interpretativen Ausdehnungssprache beschrieben.

Nach Beendigung des Schrittes 448 ist der Lesekonfigurationsdateischritt beendet, und der Betrieb geht zum Schritt 450 (Fig. 15) über, um zu ermitteln, ob es irgendwelche zu lesenden Datendateien gibt. Dieser Schritt legt im allgemeinen fest, ob der Benutzer eine Signalformdefinition zur Verfügung gestellt hat, welche er angezeigt haben möchte. Hat der Benutzer keine Anzeige definiert, dann geht der Betrieb zum Schritt 452 über, um das System dazu in Bereitschaft zu setzen, eine Editierung ohne eine Datei durchzuführen. Dies bedeutet, daß dann, wenn eine Anzeige unter diesen Bedingungen erzeugt wird, die Anzeige eine Anzeige der Standardsignalformen und -menüs darstellen wird, die während des Schrittes 422 eingegeben wurden.

Hat der Benutzer Eingaben zur Verfügung gestellt, so geht der Betrieb vom Schritt 450 zum Schritt 454 über, um festzustellen, ob die von dem Benutzer eingegebene Datei ein Filtern erfordert. Filtern ist dann erforderlich, wenn die Eingabe von dem Programm einer dritten Partei empfangen wurde, statt beispielsweise von einer vorher existierenden Wavedit-Datei und bezüglich des Namens und des Formats mit Wavedit inkompatibel ist. Ist eine Filterung erforderlich, so geht der Betrieb zum Schritt 456 über, um das geeignete Filter oder Interpretations/Übersetzungs-Tool aufzurufen, wie es von der Filterlistendatei angegeben wird, die während der Schritte 438 bis 444 gespeichert wurde, um mit der Eingabe eine erforderliche Übersetzung oder andere Interpretationen durchzuführen.

Entweder vom Schritt 454, wenn eine NEIN-Ausgabe erhalten wird, oder vom Schritt 456 aus geht der Betrieb zum Schritt 458 über, um festzustellen, ob eine Wavedit-Datei existiert. Dieser Schritt besteht im wesentlichen darin, durch Nachsehen zu ermitteln, ob tatsächlich während der Interpretation, die im Schritt 456 durchgeführt wurde, eine Datei erzeugt wurde, oder aus der empfangenen Eingabe. Wurde eine Datei erzeugt, so wird die Datei gelesen und im Schritt 460 gespeichert. Wurde keine Datei erzeugt, so wird im Schritt 462 eine leere Datei erzeugt. Diese Datei kann später hinzugefügt werden, wenn Eingaben empfangen werden.

Vom Schritt 460 oder vom Schritt 462 geht der Betieb zum Schritt 464 über, um festzustellen, ob es weitere zu lesende Dateien gibt. Sind weitere Dateien zu lesen, so kehrt der Betrieb zum Schritt 454 zurück, um zu ermitteln, ob diese Dateien eine Filterung erfordern.

Gibt es im Schritt 464 keine weiteren Dateien zu lesen, oder wird der Schritt 452 durchgeführt, so geht der Betrieb zum Schritt 466 über. Schritt 466 veranlaßt die Durchführung bestimmter Operationen zum Initialisieren des Systems zur Anzeige von Signalformen. Der Betrieb geht dann zum Schritt 468 über, um die Signalformen zu zeichnen. Fig. 18 ist ein detaillierteres Flußdigramm der Schritte, die beim Anzeigeschritt 468 des Zeichnens ablaufen.

In Fig. 18 besteht Schritt 470, der erste Schritt in dieser Operation, darin zu ermitteln, ob es bei einer Ansicht weitere zu zeichnende Signalformen gibt. Zum diesem Zeitpunkt sollte erwähnt werden, daß eine Wavedit-Darstellung eine Hierarchie von Darstellungen enthält. Auf dem höchsten Niveau der Hierarchie befindet sich der Grafikbildschirm, auf welchem alles gezeichnet wird. Auf dem einzigen Grafikbildschirm kann eine oder mehrere Ansichten vorgesehen sein, wobei jede Ansicht eine Achse aufweist und eine oder mehrere Signalformen oder Spuren enthält. Daher führt der Schritt 470 ursprünglich eine Abfrage durch, ob in der ursprünglichen Ansicht Signalformen gezeichnet werden sollen.

Gibt es in einer anfänglichen Zeichnung zu zeichnende Signalformen, so geht der Betrieb zum Schritt 472 über, um die erforderlichen Operationen zum Zeichnen der erforderlichen Achse für die Ansicht und der Signalform durchzuführen, und erforderliche Etiketten auf der Ansicht durch die Signalform anzubringen.

Sobald Schritt 472 beendet ist, geht der Betrieb zum Schritt 474 über, um festzustellen, ob die Signalform digital ist. Ist die Signalform nicht digital, so geht der Betrieb zum Schritt 476 über, um die analoge Signalform zu zeichnen, unter Verwendung einer geeigneten Signalformerzeugungsroutine, welche keinen Teil der vorliegenden Erfindung bildet, unter Verwendung der X-Y-Zahlinformation, die für die analoge Signalform zur Verfügung gestellt ist.

Wird festgestellt, daß die Signalform eine digitale Signalform ist, so geht der Betrieb zum Schritt 478 über, um zu ermitteln, ob es weitere Zustände in der Signalform gibt, welche angezeigt werden sollen. Gibt es weitere Zustände in der Signalform, welche angezeigt werden sollen, so geht der Betrieb zum Schritt 480 über, um den betreffenden Digitalzustand zu zeichnen, unter Verwendung der geeigneten Zustandsdefinition von der Zustandsdefinitionstabelle, die während der Schritte 426 bis 430 erzeugt wurde. Dann kehrt der Betrieb zum Schritt 478 zurück, um zu ermitteln, ob es weitere zu zeichnende Zustände gibt, und durchläuft die Schleifen der Schritte 478 und 480, um die gewünschte Signalform zu erzeugen, bis im Schritt 478 festgestellt wird, daß sämtliche Zustände der Signalform gezeichnet wurden.

Wenn das Zeichnen einer bestimmten Signalform beendet ist, so kehrt der Betrieb zum Schritt 470 zurück, um festzustellen, ob es in dieser bestimmten Ansicht weitere zu zeichnende Signalformen gibt. Gibt es weitere Signalformen, die in der Ansicht gezeichnet werden sollen, so geht der Betrieb zum Schritt 472 über, um der Ansicht für die neue Signalform eine Achse und/oder Etiketten hinzuzufügen, falls dies erforderlich ist, und geht dann zu den Schritten 474 bis 480 über, um die Signalform zu zeichnen. Wird während des Schrittes 470 festgestellt, daß es für diese bestimmte Ansicht keine weiteren, zu zeichnenden Signalformen gibt, so verzweigt der Betrieb zum Schritt 482, um festzustellen, ob es mehrere Ansichten gibt, die auf diesem Grafikbildschirm erscheinen sollen. Sollen weitere Ansichten auf dem Grafikbildschirm erscheinen, so kehrt der Betrieb zum Schritt 470 zurück, um festzustellen, ob es Signalformen für die neue Ansicht gibt, und, falls dies der Fall ist, geht es mit den Schritten 472 bis 480 weiter, um Etiketten und eine Achse für eine derartige Signalform zu zeichnen, und die Signalform zu zeichnen. Diese Operationssequenz dauert an, bis sämtliche Signalformen für eine zusätzliche Ansicht gezeichnet wurden, und dann kehrt der Betrieb zum Schritt 482 zurück, um zu ermitteln, ob es weitere zu zeichnende Ansichten gibt. Wurden sämtliche Ansichten gezeichnet, so wird im Schritt 482 eine NEIN-Ausgabe erhalten, was dazu führt, daß der Betrieb den Anzeigeschritt 468 für das Zeichnen verläßt.

Verläßt der Betrieb den Anzeigeschritt 468 für das Zeichnen, so geht er dann zum Schritt 486 über, um auf eine Eingabe zu warten. Wird im Schritt 486 eine Eingabe empfangen, so geht der Betrieb zum Schritt 488 über, um zu ermitteln, ob die Eingabe von der Tastatur empfangen wurde (eine Benutzereingabe) oder von Epic (Buchse). Wurde die Eingabe als eine Tasteneingabe von dem Benutzer oder von Epic empfangen, so geht der Betrieb zum Schritt 490 über, um den Befehl zu suchen, der von der Eingabe angefordert wurde. Ein Befehl kann entweder in den Makros gefunden werden, die während des Schrittes 448 eingegeben wurden, oder in internen Befehlen, die als Teil der Wavedit-Routine gespeichert wurden, wobei zunächst in einem Makro nach Befehlen gesucht wird, und dann in den internen Befehlen. Wird im Schritt 492 ein Befehl gefunden, so geht der Betrieb zum Schritt 494 aus, um den Befehl auszuführen.

Fig. 17 ist ein detaillierteres Flußdiagramm des Befehlsausführungsschrittes 494 für einen beispielhaften Befehl, in diesem Fall einen Bewertungsbefehl. Der Bewertungsbefehl kann beispielsweise zur Ausbildung einer dritten Signalform aus einer Kombination zweier anderer Signalformen führen. Wenn während des Schrittes 496 ermittelt wird, daß für bestimmte Signalformen ein Bewertungsbefehl empfangen wurde, so geht der Betrieb zum Schritt 498 über, um festzustellen, ob die Signalformen digital sind. Sind die Signalformen nicht digital, so geht der Betrieb zum Schritt 500 über, um die Signalformen unter Verwendung mathematischer Standardfunktionen zu kombinieren, beispielsweise Varianz oder Covarianz, und unter Verwendung existierender Softwaretools, die nicht spezifisch einen Teil der vorliegenden Erfindung bilden.

Falls die Signalformen als digital festgestellt werden, so geht der Betrieb zum Schritt 502 über, um festzustellen, ob sämtliche digitalen Zustände der Signalformen, die kombiniert werden sollen, kombiniert wurden. Gibt es weitere, zu kombinierende digitale Zustände, so geht der Betrieb zum Schritt 504 über, um die entsprechenden Zustände der beiden Signalformen zu kombinieren, unter Verwendung der geeigneten Logikregeln aus der Logikregeltabelle, die während der Schritte 432 und 434 gespeichert wurde (Fig. 16). Eine derartige Kombination kann einen einzigen Schritt oder mehrere Schritte umfassen, abhängig von der Komplexität der Kombinationslogik. Vom Schritt 504 aus kehrt der Betrieb zum Schritt 502 zurück, um festzustellen, ob es weitere, zu kombinierende digitale Zustände gibt, und der Betrieb durchläuft die Schleifen der Zustände 502 und 504, bis sämtliche digitale Zustände der beiden, zu kombinierenden Signalformen tatsächlich kombiniert wurden. Wurde die Kombination der beiden Signalformen beendet, entweder als Ergebnis einer analogen Kombination unter Verwendung von Schritt 500, oder als das Ergebnis einer digitalen Kombination durch die Schritte 502 und 504, so geht der Betrieb zum Schritt 506 über, um eine neue Signalform aus dem Ausgang der kombinierten Signalformen zu erzeugen, und zum Schritt 508, in welchem die neue Signalform der Anzeige zugefügt wird. Die Signalform sollte unter Verwendung derselben Schritte zum ursprünglichen Hinzufügen einer Signalform zur Anzeige gemäß Fig. 18 hinzugefügt werden, wobei geeignete Eingaben bezüglich der Ansicht empfangen werden, in welcher die Signalform erscheinen soll.

Sobald Schritt 508 beendet ist, ist der Befehl fertig, und der Betrieb kehrt zum Schritt 510 zurück, um festzustellen, ob der Befehl korrekt ausgeführt wurde. Wurde während des Schrittes 492 kein Befehl gefunden, so wird eine Fehlernachricht im Schritt 512 ausgedruckt, und der Betrieb geht darüber hinaus zum Schritt 510 über, um festzustellen, ob der Befehl ordnungsgemäß ausgeführt wurde. Wird der Befehl nicht ordnungsgemäß ausgeführt, wie dies geschehen würde, falls man zu diesem Schritt über den Schritt 512 gelangt, so sucht der Betrieb nicht nach irgendwelchen weiteren Tastatur- oder Epic-Einträgen, sondern geht zum Schritt 514 über, um festzustellen, ob es eine Mauseingabe gibt.

Wird während des Schrittes 514 festgestellt, daß eine Mauseingabe vorhanden ist, so geht der Betrieb zum Schritt 518 über, um den Bereich auf der Anzeigevorrichtung zu finden, in welcher sich die Maus befindet. In dieser Situation liegt typischerweise die Maus in einem Bereich einer Signalform, die auf dem Bildschirm angezeigt wird. Die Maus kann mit mehreren Tasten versehen sein, beispielsweise drei Tasten, wobei jede Taste einen unterschiedlichen Befehl repräsentiert, der für den Bereich ausgeführt werden kann, über welchem sich die Maus befindet. Während des Schrittes 520, dem nächsten Schritt im Betrieb, wird der Befehl ermittelt, der als Ergebnis der auf der Maus betätigten Taste ausgeführt werden soll, und der Befehl wird ausgeführt. Ein derartiger Befehl könnte beispielsweise darin bestehen, einen Punkt auf der Signalform anzubringen, um eine Durchführung von Messungen an dem Punkt und ihre Aufzeichnung zu gestatten. Messungen können auch in Reaktion auf einen Befehl zwischen dem angezeigten Punkt und einem vorher angezeigten Punkt durchgeführt werden.

Gibt es im Schritt 514 keine Mauseingabe oder ist der Schritt 520 beendet, so geht der Betrieb zum Schritt 522 über, um festzustellen, ob es eine Menübefehlseingabe gibt. Eine Menübefehlseingabe wird dann erhalten, wenn sich beispielsweise die Maus über einem Ikon auf einem Menü befindet, welches dargestellt wird, und eine geeignete Taste betätigt wird. Ist eine Menübefehlseingabe vorhanden, so geht der Betrieb zum Schritt 524 über, um den Befehl zu finden, entweder in den gespeicherten Makros oder in dem internen Befehlssatz von Wavedit, und geht dann zum Schritt 526 über, um den Befehl auszuführen. Der Befehl wird im wesentlichen auf die gleiche Weise ausgeführt wie der Befehl im Schritt 494, wie für einen beispielhaften Befehl in Fig. 17 dargestellt ist.

Wenn im Schritt 522 keine Menüeingabe gefunden wird, oder wenn die Ausführung eines Befehls im Schritt 526 beendet ist, so kehrt der Betrieb zum Schritt 486 zurück, um auf eine zusätzliche Eingabe zu warten. Die beschriebenen Operationen werden für zusätzliche Eingaben wiederholt, bis ein Ausstiegsbefehl festgestellt wird, als Ergebnis entweder einer Tastatur- oder Epic-Eingabe oder einer Menüeingabe.

Fig. 19 erläutert die Operationssequenz, die dann auftritt, wenn dieser Befehl festgestellt wird. Wenn in Fig. 19 ein Ausstiegsbefehl während des Schrittes 530 ermittelt wird, so geht der Betrieb zum Schritt 532 über, um festzustellen, ob alle geänderten Daten gerettet wurden. Wurden nicht alle geretteten Daten geändert, dann geht der Betrieb zum Schritt 534 über, um den Benutzer darüber zu informieren, daß benutzte, geänderte Daten nicht gerettet wurden, und den Benutzer dazu aufzufordern zu bestätigen, daß es zulässig ist, die Wavedit-Routine zu verlassen, was nämlich zum Verlust derartiger geänderter Daten führen würde. Gibt der Benutzer an, daß es nicht akzeptierbar ist auszusteigen, wobei sämtliche geänderten Daten nicht gerettet werden, dann verzweigt der Betrieb zum Schritt 536, um den Ausstiegsbefehl zu verlassen, und geht zu Wavedit zurück, um das Retten der geänderten Daten zu gestatten. Wird eine Ausgabe "JA" entweder während des Schrittes 532 oder des Schrittes 534 erhalten, so geht der Betrieb damit weiter, daß die Wavedit-Routine verlassen wird, wodurch die Operation beendet ist.

Es wurde daher ein System zur Verfügung gestellt, welches die Verwendung automatisierter Designsysteme und automatisierter Herstellungssysteme wesentlich vereinfacht, während es ein hohes Niveau an Konfigurierbarkeit zur Verfügung stellt, um spezielle Anforderungen eines gegebenen Benutzers zu erfüllen und mit Änderungen derartiger Anforderungen fertig zu werden, sobald sie auftreten. Das System gestattet die Verwendung von Tools, die bezüglich der Sprache, des Namens und/oder des Formats inkompatibel sind, auf eine Weise, die sowohl für den Benutzer als auch die Softwaretools vollständig transparent ist, und zwar all dies durch Verwendung eines einzigen integrierten Systems.

Zwar wurde die Erfindung voranstehend unter Bezug auf eine bevorzugte Ausführungsform dargestellt und beschrieben, jedoch wird darauf hingewiesen, daß die Ausführungsform nur zum Zwecke der Erläuterung dient, und daß sich zahlreiche Änderungen der verschiedenen angegebenen Schritte und der Reihenfolge dieser Schritte durchführen lassen, und daß auch andere Änderungen bezüglich der Form und Einzelheiten durch einen Fachmann vorgenommen werden könnten, wobei man immer noch innerhalb des Wesens und Umfangs der Erfindung bleibt.

Claims

1. System zum Integrieren und Verwalten der Operationen mehrerer unterschiedlicher Softwaretools, von denen zumindest einige mit dem System inkompatibel sind, gekennzeichnet durch:
eine Einrichtung zum Speichern mehrerer Regelmakros, die sich jeweils auf einen bestimmten Prozeß beziehen;
eine Einrichtung zur Eingabe eines Prozesses in das System;
eine auf einen eingegebenen Prozeß reagierende Einrichtung zum Zurückholen eines entsprechenden Makros;
eine Ausführungseinrichtung, welche auf das zurückgeholte Makro reagiert, um ausgewählte Tools zur Ausführung in einer vorbestimmten Sequenz zu veranlassen;
eine Einrichtung zur Ermittlung, ob ein ausgeführtes Tool mit dem System kompatibel ist; und
eine auf die Ausführung eines inkompatiblen Tools reagierende Einrichtung zum Einkapseln des Tools, welche veranlaßt, daß sämtliche Übertragungen an das Tool und von diesem überprüft und interpretiert werden, soweit erforderlich.

2. System nach Anspruch 1, dadurch gekennzeichnet, daß eine Liste der in dem System zu verwendenden Softwaretools vorgesehen ist, wobei die Liste in der Speichereinrichtung gespeichert ist, und eine Anzeige in der Liste für jedes Tool bezüglich der Tatsache vorgesehen ist, ob das Tool ein inkompatibles Tool ist.

3. System nach Anspruch 1, dadurch gekennzeichnet, daß die Einkapselungseinrichtung mehrere Interpretationsregeln an einem vorbestimmten Ort in einem Makro enthält, welche ein Softwaretool betreffen, das eine Einkapselung erfordert, eine Einrichtung zur Überprüfung jeder Übertragung zum Tool und von diesem für einen Gegenstand, auf welchen sich eine der Interpretationsregeln bezieht, und eine Einrichtung, die auf die Übertragung eines Gegenstands reagiert, auf welchen sich eine Interpretationsregel bezieht, zur Durchführung der in der Regel festgelegten Interpretation.

4. System nach Anspruch 3, dadurch gekennzeichnet, daß die Interpretationsregeln getrennte Regeln für Gegenstände umfassen, die von dem inkompatiblen Tool übertragen werden, und für Gegenstände, die an das Tool übertragen werden, und daß die Einrichtung zum Überprüfen und die Einrichtung zur Durchführung eine Überprüfung bzw. Durchführung in bezug auf die geeigneten Regeln für die Richtungen durchführen, in welcher ein Gegenstand übertragen wird.

5. System nach Anspruch 4, dadurch gekennzeichnet, daß weiterhin eine Einrichtung vorgesehen ist, die betreibbar ist, wenn ein inkompatibles Tool ausgeführt wird, um zu ermitteln, ob die Interpretationsregeln zur Übertragung von einem derartigen Tool gespeichert werden sollten, daß eine Einrichtung zum Speichern derartiger Regeln vorhanden ist, sowie eine Einrichtung, die auf eine Ausgabe von diesem Tool reagiert, um die Regeln zurückzubringen und die Regeln dazu einzusetzen, Ausgaben von diesem Tool zu interpretieren.

6. System nach Anspruch 2, dadurch gekennzeichnet, daß die Regelmakros, einschließlich der Interpretationsregeln, in einer interpretativen Ausdehnungssprache geschrieben sind, die sowohl für den Menschen als auch die Maschine lesbar ist.

7. System nach Anspruch 6, dadurch gekennzeichnet, daß ein Makro Regeln für mehrere Softwaretools zur Durchführung einer gegebenen Funktion enthalten kann, wobei die Regeln die Reihenfolge angeben, in welcher die Tools ausgeführt werden sollen.

8. System nach Anspruch 7, dadurch gekennzeichnet, daß zumindest eines der Makros eine Regel enthält, welche das Zurückholen eines neuen Makros aus der Speichereinrichtung veranlaßt.

9. System zum Integrieren und Verwalten der Operationen mehrerer unterschiedlicher Softwaretools, von denen zumindest einige mit dem System inkompatibel sind, gekennzeichnet durch:
eine Einrichtung zum Speichern mehrerer Regelmakros, von denen jedes eine bestimmte Funktion betrifft, wobei die Makros in einer interpretativen Ausdehnungssprache geschrieben sind, die sowohl für den Menschen als auch die Maschine lesbar ist;
eine Einrichtung zur Eingabe eines Prozesses in das System;
eine auf einen eingegebenen Prozeß reagierende Einrichtung zum Zurückholen eines korrespondierenden Makros;
eine auf das zurückgeholte Makro reagierende Einrichtung zur Veranlassung der Ausführung ausgewählter Tools in einer vorbestimmten Sequenz;
wobei ein Makro Regeln zum Steuern der Sequenzabfolge von Tools und der Schnittstellenbildung von Tools mit dem System enthalten kann, mit einem Benutzer und untereinander, und wobei ein Benutzer des Systems Regeln in existierenden Makros hinzufügen oder ändern kann, oder ein neues Makro hinzufügen kann, sämtlich in der interpretativen Ausdehnungssprache, wobei die Regeln von dem System erkannt werden und sofort in dieser Sprache ablaufen, wodurch das System einfach erneut konfiguriert werden kann.

10. System nach Anspruch 9, dadurch gekennzeichnet, daß das Format für zumindest eines der Tools von dem Format für ein anderes Tool verschieden ist, und daß eine Übertragung in zumindest einer Richtung zwischen dem einen und dem anderen Tool erfolgen kann;
wobei eine Regeldatei vorgesehen ist, die in einer interpretativen Ausdehnungssprache geschrieben ist, und Formatumwandlungsregeln für Tools mit inkompatiblen Formaten enthält;
eine Einrichtung vorgesehen ist, die betreibbar ist, wenn eine Übertragung zwischen bezüglich des Formats inkompatiblen Tools erfolgen soll, um die geeigneten Formatumwandlungsregeln aus der Regeldatei zurückzuholen; und
eine Einrichtung zur Verwendung der zurückgeholten Regeln vorgesehen ist, um die Formatumwandlung von Material zu steuern, welches zwischen den bezüglich des Formats inkompatiblen Tools übertragen werden soll.

11. System nach Anspruch 10, dadurch gekennzeichnet, daß zumindest zwei bezüglich des Formats inkompatible Tools auch bezüglich des Namens inkompatibel sind; und daß eine Einrichtung vorgesehen ist, um erforderliche Namensübersetzungen bei Material durchzuführen, welches zwischen den bezüglich des Namens inkompatiblen Tools übertragen wird.

12. System nach Anspruch 9, dadurch gekennzeichnet, daß zumindest einige der Tools bezüglich des Namens inkompatibel sind; und daß eine Regeldatei vorgesehen ist, die in einer interpretativen Ausdehnungssprache geschrieben ist, die Übersetzungsregeln für Tools enthält, die bezüglich des Namens inkompatibel sind; und eine Einrichtung, die betätigbar ist, wenn eine Übertragung zwischen bezüglich des Namens inkompatiblen Tools erfolgen soll, um geeignete Regeln in der Regeldatei einzusetzen, um erforderliche Übersetzungen zu bewirken, um die Tools kompatibel zu machen.

13. System nach Anspruch 12, dadurch gekennzeichnet, daß eine Einrichtung vorgesehen ist, um mit jeder Regeldatei eine Liste von Namensübersetzungen für die bezüglich des Namens inkompatiblen Tools zu speichern.

14. System nach Anspruch 13, dadurch gekennzeichnet, daß die Regeln und die korrespondierende Namensliste in einem Bildschirm gespeichert sind, wobei ein Namensübersetzungseintrag jedesmal dann der Liste zugefügt wird, wenn eine Übersetzung eines Namens erfolgt, der sich noch nicht auf der Liste befindet.

15. System nach Anspruch 14, dadurch gekennzeichnet, daß eine auf die Übertragung eines Namens, der eine Übersetzung erfordert, zwischen den bezüglich des Namens inkompatiblen Tools reagierende Einrichtung vorgesehen ist, um festzustellen, ob es einen Eintrag für diesen Namen in der Namensliste gibt, daß eine Einrichtung vorgesehen ist, die darauf reagiert, daß ein Eintrag für den Namen vorgesehen ist, um den Eintrag zur Übersetzung des Namens zu verwenden, und daß eine Einrichtung vorgesehen ist, die darauf reagiert, daß kein Eintrag für den Namen vorgesehen ist, um die geeigneten Regeln zur Übersetzung des Namens zu verwenden.

16. System nach Anspruch 15, dadurch gekennzeichnet, daß die Einrichtung zur Verwendung der geeigneten Regeln eine Einrichtung zum Suchen nach jeder geeigneten Regel umfaßt, um festzustellen, ob sie auf den Namen anwendbar ist, und eine Einrichtung zum Ausführen geeigneter Regeln, um die Übersetzung des Namens durchzuführen.

17. System nach Anspruch 16, dadurch gekennzeichnet, daß eine Einrichtung zur Entfernung aller ungültigen Zeichen nach einer Namensübersetzung durch die Einrichtung zum Ausführen geeigneter Regeln vorgesehen ist.

18. System nach Anspruch 16, dadurch gekennzeichnet, daß eine Einrichtung zum Abschneiden eines übersetzten Namens auf eine geeignete Maximallänge vorgesehen ist.

19. System nach Anspruch 16, dadurch gekennzeichnet, daß eine Einrichtung zur Zufügung irgendwelcher erforderlicher Vorsilben oder Nachsilben zu einem übersetzten Namen vorgesehen ist.

20. System nach Anspruch 16, dadurch gekennzeichnet, daß eine Einrichtung vorgesehen ist, um zu bestimmen, ob ein einzigartiger übersetzter Name für jeden zu übersetzenden Namen erforderlich ist, eine Einrichtung, die betreibbar ist, falls ein einzigartiger übersetzter Name erforderlich ist, ob zur Ermittlung der übersetzte Name einzigartig ist, eine Einrichtung, die betreibbar ist, wenn der übersetzte Name nicht einheitlich ist, um zu ermitteln, ob der übersetzte Name so modifiziert werden kann, daß er einzigartig ist, und eine Einrichtung zum Modifizieren des übersetzten Namens, so daß er einzigartig ist, wenn eine derartige Modifikation möglich ist.

21. System nach Anspruch 20, dadurch gekennzeichnet, daß eine Einrichtung zur Anzeige für jeden Eintrag in der Namensliste vorgesehen ist, um anzuzeigen, ob dieser Eintrag zu einem übersetzten Namen gehört, der einzigartig sein muß.

22. System nach Anspruch 14, dadurch gekennzeichnet, daß eine Einrichtung zur Speicherung der Namensliste eines Bildschirms als eine Alias-Datei vorgesehen ist.

23. System nach Anspruch 14, dadurch gekennzeichnet, daß eine Einrichtung zur Verwendung der Namensliste in einem Bildschirm vorgesehen ist, um aus erzeugten Namen Originalnamen zur Verfügung zu stellen, wobei nicht für jeden Originalnamen ein einzigartiger Name vorhanden ist, und wobei die Bereitstellungseinrichtung eine Liste von Originalnamen für jeden bei ihr eingesetzten erzeugten Namen zur Verfügung stellt.

24. System nach Anspruch 9, dadurch gekennzeichnet, daß eines oder mehrere der Tools eine geschachtelte Hierarchie von Material bezüglich einer Komponente umfassen kann, wobei unterschiedliche Namen für denselben Gegenstand an unterschiedlichen Niveaus in der Hierarchie verwendet werden; und
daß eine Regeldatei für Übersetzungen der Namen für die verschiedenen Hierarchieniveaus vorgesehen ist, sowie eine Einrichtung zur Verwendung der Regeldatei, um den geeigneten Namen für einen Gegenstand auf einem gegebenen Hierarchieniveau zu erhalten.

25. System nach Anspruch 9, dadurch gekennzeichnet, daß
Eingabeinformationen von einem Benutzer für zumindest einige Tools erforderlich ist; und
Regeldateien vorgesehen sind, die in einer interpretativen Ausdehnungssprache geschrieben sind; und
eine Einrichtung zur Verwendung der Regeldateien vorgesehen ist, um aktiv angeforderte Eingabeinformation einzugeben.

26. System nach Anspruch 25, dadurch gekennzeichnet, daß die Regeldateien Standardeingaben für jede Stufe zur Verfügung stellen, an welcher Eingaben von jedem Tool gefordert werden, und daß eine Einrichtung vorgesehen ist, die betreibbar ist, wenn ein Tool auf einer Stufe ist, in welcher Eingaben zur Darstellung der Standardeingaben für diese Stufe für den Benutzer erforderlich sind, eine Einrichtung vorgesehen ist, um dem Benutzer die Vornahme von Änderungen der Standardeingaben zu gestatten, und eine Einrichtung vorgesehen ist, um die von dem Benutzer modifizierten Standardeingaben an das Tool weiterzugeben.

27. System nach Anspruch 26, dadurch gekennzeichnet, daß eine Einrichtung vorgesehen ist, die dem Benutzer eine Anzeige gestattet, daß er Eingaben zu einem Tool oder zum System zu machen wünscht.

28. System nach Anspruch 26, dadurch gekennzeichnet, daß eine Einrichtung vorgesehen ist, um den Benutzer in der Standardeingabendarstellung bezüglich Gegenständen aufzufordern, welcher der Benutzer als Eingaben an der gegebenen Stufe dem Tool hinzufügen muß.

29. System nach Anspruch 28, dadurch gekennzeichnet, daß eine Einrichtung vorgesehen ist, um einen weiteren Betrieb des Tools zu sperren, bis der Benutzer die erforderlichen Eingaben durchführt.

30. System nach Anspruch 28, dadurch gekennzeichnet, daß eine Einrichtung vorgesehen ist, um den Benutzer in der Standardeingabenanzeige bezüglich zusätzlicher Gegenstände aufzufordern, welche der Benutzer als Eingaben an der gegebenen Stufe in dem Tool hinzufügen kann.

31. System nach Anspruch 25, dadurch gekennzeichnet,
daß eine Einrichtung zum Speichern von Information, ein Design betreffend, und zum Speichern von Übersetzungsinformation, ein ausgewähltes Tool oder mehrere Tools betreffend, vorgesehen ist;
daß eine Einrichtung vorgesehen ist, um einen Benutzer dazu aufzufordern, ein Element des gespeicherten Designs auszuwählen, auf welchem eine ausgewählte Übersetzung durchgeführt werden soll; und
daß eine Einrichtung vorgesehen ist, die auf eine Benutzereingabe reagiert, um die ausgewählte Übersetzung bei dem Element durchzuführen, das von dem Benutzer ausgewählt wurde.

32. System nach Anspruch 25, dadurch gekennzeichnet,
daß die erforderliche Eingabeinformation digitale grafische Information ist; und
daß eine Einrichtung vorgesehen ist, um Zustandsdefinitionen für gültige digitale Zustände für die grafische Information zu speichern;
eine Einrichtung zum Empfang grafischer Informationen, die eingegeben werden sollen, und
eine Einrichtung zum Einsatz der gespeicherten Zustandsdefinitionen, um die empfangene Grafikinformation darzustellen.

33. System nach Anspruch 32, dadurch gekennzeichnet, daß die empfangenen Grafikinformationen entweder Standardgrafikinformation von dem System oder von einem Benutzer bereitgestellte Grafikinformation ist.

34. System nach Anspruch 32, dadurch gekennzeichnet, daß
die Einrichtung zum Speichern von Regeldateien eine Einrichtung zum Speichern von Logikregeln zur Operation auf der Grafikinformation aufweist;
eine Einrichtung zum Empfangen und Erkennen von Befehlen zur Operation auf der Grafikinformation; und
eine Einrichtung zum Einsatz geeigneter gespeicherter Logikregeln zur Ausführung eines empfangenen und erkannten Befehls.

35. System nach Anspruch 32, dadurch gekennzeichnet,
daß die digitale Grafikinformation Signalformen sind; und
daß die Einrichtung zum Darstellen die gespeicherten Zustandsdefinitionen zum Steuern der Darstellung für jeden aufeinanderfolgenden Zustand einer darzustellenden Signalform einsetzt.

36. Verfahren zum integrieren und Verwalten der Operationen mehrerer unterschiedlicher Softwaretools, von denen zumindest einige mit dem System nicht kompatibel sind, gekennzeichnet durch folgende Schritte:
Speichern mehrerer Regelmakros, von denen jedes einen bestimmten Prozeß betrifft;
Eingabe eines Prozesses in das System;
Zurückholen eines entsprechenden Makros in Reaktion auf einen eingegebenen Prozeß;
Ausführen ausgewählter Tools in einer vorbestimmten Sequenz in Reaktion auf das zurückgeholte Makro;
Ermittlung, ob ein Tool, welches ausgeführt wird, mit dem System kompatibel ist; und
Einkapseln des Tools und Veranlassung einer Überprüfung und Interpretation sämtlicher Übertragungen zum Tool und von dem Tool je nach Erfordernis in Reaktion auf die Ausführung eines inkompatiblen Tools.

37. Verfahren nach Anspruch 36, dadurch gekennzeichnet, daß eine Liste der in dem System zu verwendenden Softwaretools vorgesehen ist, wobei die Liste mit den Makros gespeichert wird, und in der Liste eine Anzeige für jedes Tool vorgesehen ist, ob das Tool ein inkompatibles Tool ist.

38. Verfahren nach Anspruch 36, dadurch gekennzeichnet, daß der Einkapselungsschritt folgende Schritte umfaßt: Überprüfung mehrerer Interpretationsregeln an einem vorbestimmten Ort in einem Makro, welches ein Softwaretool betrifft, welches Einkapselung erfordert, während jeder Übertragung an das Tool und von dem Tool für einen Gegenstand, auf den eine der Interpretationsregeln zutrifft, und durch Durchführen der in der Regel angegebenen Interpretation in Reaktion auf die Übertragung eines Gegenstands, auf welchen eine Interpretationsregel zutrifft.

39. Verfahren nach Anspruch 38, gekennzeichnet durch folgende Schritte, die durchgeführt werden, wenn eine Ausführung mit einem inkompatiblen Tool erfolgt: Ermitteln, ob die Interpretationsregeln zur Übertragung von einem derartigen Tool gespeichert werden sollen, in einer Einrichtung zum Speichern derartiger Regeln, und Zurückbringen der Regeln in Reaktion auf eine Ausgabe von dem Tool, und Verwendung der Regeln zur Interpretation von Ausgaben von diesem Tool.

40. Verfahren nach Anspruch 37, dadurch gekennzeichnet, daß die Regelmakros einschließlich der Interpretationsregeln in einer interpretativen Ausdehnungssprache geschrieben sind, die sowohl für Menschen als auch Maschinen lesbar ist.

41. Verfahren nach Anspruch 40, dadurch gekennzeichnet, daß ein Makro Regeln für mehrere Softwaretools aufweisen kann, um eine bestimmte Funktion durchzuführen, wobei die Regeln die Reihenfolge festlegen, in welcher die Tools durchgeführt werden.

42. Verfahren nach Anspruch 41, dadurch gekennzeichnet, daß zumindest eines der Makros eine Regel enthält, welche die Rückgewinnung eines neuen Makros aus der Speichereinrichtung verursacht.

43. Verfahren zum Integrieren und Verwalten der Operationen mehrerer unterschiedlicher Softwaretools, von denen zumindest einige nicht mit dem System kompatibel sind, gekennzeichnet durch folgende Schritte:
Speichern mehrerer Regelmakros, von denen jedes eine bestimmte Funktion betrifft, wobei die Makros in einer interpretativen Ausdehnungssprache geschrieben sind, die sowohl für Menschen als auch Maschinen lesbar ist;
Eingeben eines Prozesses in das System;
Zurückholen eines entsprechenden Makros in Reaktion auf einen eingegebenen Prozeß;
Ausführen ausgewählter Tools, die in einer vorbestimmten Sequenz ausgeführt werden sollen, in Reaktion auf das zurückgeholte Makro; und
wobei ein Makro Regeln zum Steuern der Sequenzfolge der Tools und der Schnittstellenverbindung der Tools mit dem System aufweisen kann, mit einem Benutzer und untereinander, und wobei ein Benutzer des Systems Regeln in existierenden Makros hinzufügen oder ändern kann, oder ein neues Makro hinzufügen kann, sämtlich in der interpretativen Ausdehnungssprache, wobei die Regeln von dem System erkannt werden und sofort in dieser Sprache ablaufen können, wodurch das System einfach erneut konfiguriert werden kann.

44. Verfahren nach Anspruch 43, dadurch gekennzeichnet,
daß das Format für zumindest eines der Tools unterschiedlich von dem Format für ein anderes Tool ist, und eine Übertragung in zumindest einer Richtung zwischen dem einen und dem anderen Tool erfolgen kann;
wobei eine Regeldatei vorgesehen ist, die in einer interpretativen Ausdehnungssprache geschrieben ist, und Formatumwandlungsregeln für Tools mit inkompatiblen Formaten enthält; und
Schritte zum Zurückführen der geeigneten Formatumwandlungsregeln aus der Regeldatei, wenn eine Übertragung zwischen bezüglich des Formats inkompatiblen Tools erfolgen soll; und
wobei die zurückgeholten Regeln zum Steuern der Formatumwandlung von Material eingesetzt werden, welches zwischen den bezüglich des Formats inkompatiblen Tools übertragen werden soll.

45. Verfahren nach Anspruch 44, dadurch gekennzeichnet,
daß zumindest zwei bezüglich des Formats inkompatible Tools auch bezüglich des Namens nicht kompatibel sind, und
daß weiterhin der Schritt der Durchführung erforderlicher Namensübersetzungen auf Material vorgesehen ist, welches zwischen den beiden bezüglich des Namens inkompatiblen Tools übertragen wird.

46. Verfahren nach Anspruch 43, dadurch gekennzeichnet, daß zumindest einige der Tools bezüglich des Namens nicht kompatibel sind, und daß eine Regeldatei vorhanden ist, die in einer interpretativen Ausdehnungssprache geschrieben ist und Übersetzungsregeln für Tools enthält, die bezüglich des Namens nicht kompatibel sind; wobei die Schritte durchführbar sind, wenn eine Übertragung zwischen bezüglich des Namens inkompatiblen Tools erfolgt, daß geeignete Regeln in der Regeldatei genutzt werden, um die Übersetzungen durchzuführen, die dazu erforderlich sind, die Tools kompatibel zu machen.

47. Verfahren nach Anspruch 12, dadurch gekennzeichnet, daß eine Einrichtung zum Speichern, mit jeder Regeldatei, einer Liste von Namensübersetzungen für die bezüglich des Namens inkompatiblen Tools vorgesehen ist.

48. Verfahren nach Anspruch 47, dadurch gekennzeichnet, daß die Regeln und die entsprechende Namensliste in einem Bildschirm gespeichert werden, wobei ein Namensübersetzungseintrag der Liste jedesmal dann zugefügt wird, wenn eine Übersetzung für einen Namen durchgeführt wird, der sich noch nicht auf der Liste befindet.

49. Verfahren nach Anspruch 48, dadurch gekennzeichnet, daß folgende Schritte vorgesehen sind: Feststellung, wenn eine Übertragung eines Namens, der eine Übersetzung erfordert, zwischen den bezüglich des Namens inkompatiblen Tools erfolgt, ob ein Eintrag für diesen Namen in der Namensliste vorhanden ist, und, falls ein Eintrag für den Namen vorhanden ist, Verwendung des Eintrags zur Übersetzung des Namens, und wenn kein Eintrag für den Namen vorhanden ist, Verwendung der geeigneten Regeln zur Übersetzung des Namens.

50. Verfahren nach Anspruch 49, dadurch gekennzeichnet, daß die Verwendungsschritte folgende Schritte umfassen: Betrachtung jeder geeigneten Regel, um zu ermitteln, ob sie auf den Namen anwendbar ist, und Einsetzen geeigneter Regeln zur Durchführung der Übersetzung des Namens.

51. Verfahren nach Anspruch 50, dadurch gekennzeichnet, daß weiterhin die Schritte der Entfernung jedes ungünstigen Zeichens nach einer Namensübersetzung während des Schrittes des Einsetzens geeigneter Regeln vorgesehen sind.

52. Verfahren nach Anspruch 50, dadurch gekennzeichnet, daß die Schritte des Abschneidens eines übersetzten Namens auf eine geeignete Maximallänge vorgesehen sind.

53. Verfahren nach Anspruch 50, dadurch gekennzeichnet, daß weiterhin der Schritt der Hinzufügung irgendwelcher geeigneter Vorsilben oder Nachsilben zu einem übersetzten Namen vorgesehen ist.

54. Verfahren nach Anspruch 50, dadurch gekennzeichnet, daß weiterhin folgende Schritte vorgesehen sind: Ermittlung, ob ein einzigartiger übersetzter Name für jeden zu übersetzenden Namen erforderlich ist, und wenn ein einzigartiger übersetzter Name erforderlich ist, Ermittlung, ob der übersetzte Name einzigartig ist, und wenn der übersetzte Name nicht einzigartig ist, Ermittlung, ob der übersetzte Name so modifiziert werden kann, daß er einzigartig ist, und Modifizieren des übersetzten Namens so, daß er einzigartig ist, wenn diese Modifizierung möglich ist.

55. System nach Anspruch 20, dadurch gekennzeichnet, daß eine Einrichtung zur Bezeichnung jedes Eintrags in der Namensliste in der Hinsicht vorgesehen ist, ob dieser Eintrag für einen übersetzten Namen dient, der einzigartig sein muß.

56. Verfahren nach Anspruch 14, dadurch gekennzeichnet, daß die Schritte des Speicherns der Namensliste eines Bildschirms als eine Alias-Datei vorgesehen sind.

57. System nach Anspruch 48, dadurch gekennzeichnet, daß folgende Schritte vorgesehen sind: Verwendung der Namensliste in einem Bildschirm zur Bereitstellung von Originalnamen aus erzeugten Namen, wenn kein einzigartiger Name für jeden Originalnamen vorhanden ist, wobei der Bereitstellungsschritt eine Liste von Originalnamen für jeden hierbei eingesetzten erzeugten Namen bereitstellt.

58. Verfahren nach Anspruch 43, dadurch gekennzeichnet, daß ein Tool oder mehrere Tools eine geschachtelte Hierarchie von Material bezüglich eines Bauteils enthält bzw. enthalten, wobei unterschiedliche Namen für denselben Gegenstand auf unterschiedlichen Niveaus in der Hierarchie verwendet werden.

59. Verfahren nach Anspruch 43, dadurch gekennzeichnet, daß von einem Benutzer für zumindest einige Tools Eingabeinformation erforderlich ist, wobei Regeldateien vorhanden sind, die in einer interpretativen Ausdehnungssprache geschrieben sind, und weiterhin der Schritt vorgesehen ist, die Regeldateien dazu einzusetzen, interaktiv erforderliche Eingabeinformation einzugeben.

60. Verfahren nach Anspruch 59, dadurch gekennzeichnet,
daß die Regeldateien Standardeingaben für jede Stufe zur Verfügung stellen, an welcher Eingaben von jedem Tool gefordert werden; und
daß die Schritte der Darstellung der Standardeingaben für diese Stufe für den Benutzer vorgesehen sind, wenn sich ein Tool an einer Stufe befindet, an welcher Eingaben erforderlich sind, wodurch dem Benutzer die Vornahme von Änderungen an den Standardeingaben ermöglicht wird, um die von dem Benutzer modifizierten Standardeingaben an das Tool zu übertragen.

61. Verfahren nach Anspruch 60, dadurch gekennzeichnet, daß der Schritt vorgesehen ist, dem Benutzer eine Anzeige zu gestatten, daß er Eingaben zu einem Tool oder zum System zu machen wünscht.

62. Verfahren nach Anspruch 60, dadurch gekennzeichnet, daß der Schritt vorgesehen ist, den Benutzer in der Standardeingabendarstellung bezüglich Gegenständen aufzufordern, welche der Benutzer als Eingaben an der gegebenen Stufe in das Tool hinzufügen muß.

63. Verfahren nach Anspruch 62, dadurch gekennzeichnet, daß der Schritt der Sperrung einer weiteren Operation des Tools vorgesehen ist, bis der Benutzer die erforderlichen Eingaben vornimmt.

64. Verfahren nach Anspruch 62, dadurch gekennzeichnet, daß der Schritt vorgesehen ist, den Benutzer in der Standardeingabedarstellung bezüglich wahlweiser Gegenstände aufzufordern, welcher der Benutzer als Eingaben an der gegebenen Stufe in das Tool hinzufügen kann.

65. Verfahren nach Anspruch 59, dadurch gekennzeichnet,
daß die Schritte der Speicherung von Information, ein Design betreffend, vorgesehen sind; und
das Speichern von Übersetzungsinformation, welche ein ausgewähltes Tool oder mehrere Tools betrifft;
Auffordern eines Benutzers, ein Element des gespeicherten Designs auszuwählen- auf welchem eine ausgewählte Übersetzung durchgeführt werden soll; und
Durchführung, in Reaktion auf eine Benutzereingabe, der ausgewählten Übersetzung bei dem Element, welches von dem Benutzer ausgewählt wurde.

66. Verfahren nach Anspruch 59, dadurch gekennzeichnet,
daß die geforderte Eingabeinformation digitale Grafikinformation ist; und
daß folgende Schritte vorgesehen sind: Speichern von Zustandsdefinitionen für gültige digitale Zustände für die grafische Information;
Empfangen grafischer Informationen, die eingegeben werden sollen; und
Einsetzen der gespeicherten Zustandsdefinitionen zur Darstellung der empfangenen Grafikinformation.

67. Verfahren nach Anspruch 66, dadurch gekennzeichnet, daß die empfangenen Grafikinformationen entweder Standardgrafikinformation von dem System oder durch einen Benutzer zur Verfügung gestellte Grafikinformation ist.

68. Verfahren nach Anspruch 66, dadurch gekennzeichnet, daß folgende Schritte vorgesehen sind: Speichern von Logikregeln zum Operieren auf der Grafikinformation;
Empfangen und Erkennen von Befehlen zum Operieren auf der Grafikinformation; und
Verwendung geeigneter, gespeicherter Logikregeln zur Ausführung eines empfangenen und erkannten Befehls.

69. Verfahren nach Anspruch 66, dadurch gekennzeichnet, daß die digitale Grafikinformation Signalformen darstellt, und daß die gespeicherten Zustandsdefinitionen dazu verwendet werden, die Anzeigedarstellung für jeden aufeinanderfolgenden Zustand einer darzustellenden Signalform zu steuern.