DE69327318T2

DE69327318T2 - Unterstützung für systementwicklung.

Info

Publication number: DE69327318T2
Application number: DE69327318T
Authority: DE
Inventors: Einar Wennmyr
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 1992-06-10
Filing date: 1993-05-06
Publication date: 2000-05-25
Anticipated expiration: 2013-05-07
Also published as: US5485615A; NO944717D0; FI945742A; EP0645032A1; KR950701102A; WO1993025960A1; FI945742A0; NO944717L; BR9306516A; EP0645032B1; MX9303341A; ES2142343T3; CN1069424C; KR100314262B1; AU4363693A; DE69327318D1; DK0645032T3; GR3032780T3; CN1079830A; AU673528B2

Description

HINTERGRUND DER ERFINDUNG

Gebiet der Erfindung

Die vorliegende Erfindung bezieht sich auf ein System, welches, bei der Entwicklung von Softwareprodukten gemäß einem beschriebenen Satz von Prozeduren hilft, und insbesondere auf ein interaktives Unterstützungsmedium, welches automatisch vergangene, gegenwärtige und zukünftige Handlungen automatisch überwacht, aufzeichnet, abruft und vorschlägt, gemäß einem Satz von Prozeduren, wie jene, welche bei vielen Verfahren gefunden werden, die sich auf Computerprogramm-Design beziehen.

Beschreibung des Standes der Technik

Jahrelang suchten und wünschten sich Computersoftware- Entwickler Werkzeuge, welche die Last verringern, die einher geht mit der Schaffung von komplexen Computerprogrammen. Die Software-Entwicklung der fernen und nicht so fernen Vergangenheit erforderte die spezifische Aufmerksamkeit des Programmierers für jedes Detail, das mit dem Fortschritt des Programms zusammenhing, und für all die Dokumente, Beschreibungen und dergleichen, welche damit zusammenhingen. Ein Computersoftware-System wurde aufgebaut, getestet, die Komponenten überholt und das System neu gebaut, bis der Programmierer das gewünschte Produkt geschaffen hatte. Da Softwaresysteme in ihrer Größe und Komplexität gewachsen sind, hat auch die Zahl der für das Design eines einzigen Systems erforderlichen Programmierer dramatisch zugenommen. Folglich ist es nun weit verbreitet, daß verschiedene individuelle Programmierer getrennte Elemente eines gesamten Softwaresystems entwickeln werden, bei welchem jedes im Endprodukt wechselwirken und zusammen arbeiten muß. Klarerweise treten in solchen Projekten Probleme der Konsistenz und Einheitlichkeit auf. Wenn zum Beispiel ein Programmierer seinen bzw. ihren Abschnitt des Programms modifiziert, ergeben sich Auswirkungen in anderen Teilen des Programms, auf welche die Entwickler, welche an jenen Teilen arbeiten, aufmerksam gemacht werden sollten. Somit besteht ein Bedarf an Entwicklungs- Unterstützungssystemen, welche Softwareentwickler während der Schaffung von komplexen Computerprogrammen begleiten und helfen.
Eine Lösung ist im US-Patent Nr. 4,860,204 an Gendron et al. gezeigt, wobei eine Arbeitsstation bzw. Workstation Verfahren zur Konstruktion von Computerprogrammen verwendet, durch die Verwendung von visuellen, graphischen Darstellungen. Die Arbeitsstation auf Computerbasis nach Gendron erlaubt es dem Benutzer ein Computerprogramm zu schaffen, in dem graphische Programmierblöcke miteinander verbunden werden, und dadurch das gewünschte funktionelle Resultat geschaffen wird. Während das Gendron-System Vollständigkeitsüberprüfungen bzw. Integritätsprüfungen für die gewählte Verbindungen durchführt, stellt das System dem Benutzer keine Vorschläge bereit betreffend die verfügbaren Vorgehensmöglichkeiten und die Konsequenzen der von dem Benutzer unternommenen Aktionen.
Ähnlich wird in dem US-Patent Nr. 4,734,854 an Afshar ein System zur Entwicklung von generischen Programm-Modulen gelehrt, welche gemeinsam benötigte Berechnungsfunktionen durchführen. Der Benutzer kann dann das generische Modul in eine spezifische oder konkrete Softwareeinheit integrieren, und das Afshar-System erzeugt automatisch eine konkrete Version des generischen Moduls, die in die spezifische Softwareeinheit paßt. Während dieses System einige automatisierte Merkmale hat, informiert es den Benutzer nicht darüber, welches generische System oder Werkzeug erforderlich ist während der Entwicklung, und es schlägt dem Benutzer auch keine alternativen Wege der Implementierung vor.
In jüngster Zeit wurden jedoch computerunterstützte Software- Ingenieur-Umgebungen (CASE-Umgebungen, d. h. Computer-Aided Software Engineering) nicht nur nützlich, sondern in vielen Fällen wesentlich für komplexe Softwareprojekte; genau wie CAD- Systeme (Computer-Aided Design) wesentlich für komplexe Hardwareprojekte geworden sind. Der Begriff "Software- Ingenieur-Umgebung" (Software Engineering Environment) bezieht sich allgemein auf eine Betriebssystemumgebung und eine Sammlung von Werkzeugen oder Unterroutinen, welche innerhalb des Bereichs von Bedingungen arbeiten, die durch das Entwicklungscomputerprogramm erzeugt werden. Beispielsweise lehrt das US-Patent Nr. 4,809,170 für Leblang et al ein Unterstützungssystem für computerunterstützte Software- Ingenieur-Anwendungen. Das Unterstützungssystem von Leblang überwacht Veränderungen, die im Entwicklungssystem gemacht werden, und zeichnet solche Veränderungen für späteren Abruf auf. Zusätzlich setzt das System gleichzeitig Benutzer des Systems über alle solche Veränderungen in Kenntnis. Leblang lehrt jedoch nicht ein Unterstützungssystem, welches automatisch verschiedene Programmkonstruktions-Werkzeuge aufruft und interaktiv Vorschläge an den Benutzer weiterleitet.
Die frühen Software-Ingenieurumgebung-Systeme, genauso wie die Theorien und Ziele von Softwareentwicklungs-Unterstützung werden auf allgemeine Weise in den folgenden Artikeln beschrieben:
Griffiths et al., "ALF: Its Process Model an its Implementation on PCTE," ESPRIT ALF Project, Technical Paper 1989.
Kaiser et al., "Intelligent Assistance for Software Development and Maintenance," IEEE Software, 1988.
Clemm, "Replacing Version-Control with Job-Control", Association for Computing Machinery, 1989.
Zusätzlich unterstützen CASE-Systeme Benutzer auf andere Weise als durch Codegenerierung. Zum Beispiel beeinflussen Aufgaben bzw. Tasks, welche von Softwareentwicklern unternommen werden, die einen bestimmten Aspekt des Programms modifizieren, nicht nur Programmodulelemente, sondern auch Nichtcodeelemente des Programms. Die Hinzufügung einer Verbesserung zum Programm kann auch die Aktualisierung der Entwicklungsspezifikation des Benutzerhandbuchs und von Online-Hilfedateien verlangen. Einige Schritte können Offline-Aktivitäten beinhalten, wie die Mitteilung der Veränderung an andere, die an dem Programm arbeiten oder das Programm benutzen, die Konstruktion von Floppy-Disketten für das aktualisierte Programm, und die Übersendung der neuen Disketten an Programmierer und Verwender. Der Software-Entwicklungsprozeß beinhaltet viel mehr als nur programmieren, und eine praktische Softwareentwicklungs- Umgebung sollte mehr als nur programmieren unterstützen.
Die industrielle Computerprogramm-Entwicklung beginnt heute mit der Beschreibung der Verfahren und Prozeduren, durch welche bestimmte Software sich entwickeln sollte. Die Beschreibung enthält verschiedene Standards und komplexe Prozesse, welche zur Vollendung eine Vielzahl von Schritten erfordern. Frühere Software-Unterstützungssysteme umfaßten "Werkzeugkästen" (Toolboxes), welche verschiedene Werkzeuge enthielten zur Erfüllung eines spezifischen Tasks bzw. einer spezifischen Aufgabe. Werkzeuge, welche innerhalb dieser Unterstützungssysteme verwendet wurden, umfaßten Editoren, Compiler, Flußdiagramm-Editoren usw.. Der Programmierer war dafür verantwortlich, das korrekte Werkzeug auszuwählen und die Konsistenz zwischen verschiedenen Programmelementen sicherzustellen.
Andere Software-Unterstützungssysteme enthielten Prozeßprogrammiertechniken, welche einem Prozeß anhand von Software beschreiben. Prozeßprogrammierung implementiert Softwareprozesse als Software. Dieser Ansatz beschreibt den Softwareprozeß soweit wie möglich mittels einer Formalsprache, und die Prozeßbeschreibung wird durch den Computer interpretiert, welcher dann den Benutzer bei der Ausführung einer spezifischen Aufgabe führen kann. Während man behaupten kann, daß sie als Softwareentwicklungs-Hilfemittel arbeiten, stellen Prozeßprogrammiertechniken des Standes der Technik dem Benutzer keine flexible Hilfe bereit. Statt dessen zwingt die Prozeßprogrammierung des Standes der Technik den Benutzer dazu, durch eine Vielzahl von verschiedenen Schritten im Entwicklungsprozeß zu schreiten. Benutzer akzeptieren jedoch widerwillig das erzwungene Regiment, welches durch die Prozeßprogrammiertechnik aufgezwungen wird. Um im Software- Entwicklungsprozeß wirklich effektiv zu sein, ist ein flexibleres Unterstützungssystem erforderlich, einschließlich eines Systems, welches die von dem Benutzer unternommenen Aktionen überwacht, es dem Benutzer gestattet in verschiedene Richtungen voranzugehen, welche konsistent sind mit dem zu Grunde liegenden Entwicklungsprozeß, die Aktionen des Benutzers interpretiert und für die durchgeführte Aktivitäten Unterstützung leistet. Somit besteht auf diesem Gebiet ein Bedarf für ein interaktives Prozeßprogrammierungs- Unterstützungssystem, welches Softwareprogrammierer und Ingenieure auf eine flexible Weise bei der Entwicklung von komplexen Computerprogrammen unterstützt.

ZUSAMMENFASSUNG DER ERFINDUNG

In einem Aspekt gemäß Anspruch 1 enthält die vorliegende Erfindung ein Verfahren zur Bereitstellung von interaktiver Unterstützung für die Entwicklung eines Softwareprodukts gemäß eines spezifizierten Softwareprozesses. Das Verfahren umfaßt den ersten Schritt der Definition eines Softwareprozesses in einer spezifischen Sprache, welche den Satz von Schritten, welcher bei der Entwicklung eines Softwareprodukts verwendet wird, in Beziehung bringt. Die erzeugte Beschreibung muß dann in eine von einem Interpreter ausführbare Form umgewandelt werden. Während der Interpretation erzeugt das Verfahren ein Menü von Möglichkeiten, in welchem jede der Möglichkeiten ein Vorschlag bildet bezüglich möglicher Aktionen, die relevant sind für den spezifizierten Softwareprozeß. Der Verwender wählt eine der Möglichkeiten, worauf eines einer Gruppe von Systemwerkzeugen initiiert und eine Werkzeugoperation ausgeführt werden kann. Der Benutzer kann Werkzeugoperationen auch direkt initiieren. Die Resultate jeder über das Werkzeug ausgeführten Operation wird verfolgt, um zu sehen, ob es für den Prozeß relevant ist. Eine Analyse der Resultate wird gemacht, und als ein Effekt können andere Systemwerkzeuge oder andere Werkzeugoperationen automatisch initiiert werden. In der Folge wird dem Benutzer eine Rückkopplung bereitgestellt, welche den gegenwärtigen Status der Entwicklung im Lichte der vorangehend ausgeführten Schritte abdeckt.
Das Verfahren der vorliegenden Erfindung enthält Konsistenzüberprüfungen, welche in einer formalen Prozeßbeschreibung spezifiziert sind. Diese Konsistenzüberprüfungen können nach jeder Benutzung der Systemwerkzeuge auftreten, und Berichte von Fehlern, die während der Konsistenzüberprüfungen entdeckt werden, werden erstellt. Ein zusätzliches Element des vorangegangenen Verfahrens gestattet das Stöbern (Browsing) durch Objekte innerhalb einer mit der Entwicklung in Beziehung stehenden Datenbank. Das Suchen nach spezifischen Objekten innerhalb der Datenbank kann auftreten, genauso wie die Initiierung von irgendeinem der verfügbaren Systemwerkzeuge von dem Browser.
In einem weiteren Aspekt nach Anspruch 8, enthält die Erfindung ein Computersystem, welches eine interaktive Unterstützung während der Entwicklungsphase gemäß eines spezifizierten Softwareprozesses schafft. Das interaktive Unterstützungssystem enthält ein Mittel zur Spezifizierung und Speicherung einer formalen Prozeßbeschreibung. Weiterhin wird innerhalb des Systems ein Mittel bereitgestellt für die Transformation der funktionalen Prozeßbeschreibung in eine interpretierbare Form. Der Interpreter enthält sowohl ein Expertensystem als auch eine Datenbank, welche für den Logik-Interpreter elektronisch zugänglich ist. Ein Botschafts-Abwickler (message handler), welcher mit dem Logik-Interpreter elektronisch gekoppelt ist, wickelt die Kommunikation mit einer Gruppe von Systemwerkzeugen ab, welche konfiguriert sind spezifische Aufgaben bzw. Tasks auszuführen, die mit dem beschriebenen Prozeß in Zusammenhang stehen. Schließlich kommuniziert eine Benutzerschnittstelle graphisch mit dem Benutzer des Systems und erlaubt auch eine Benutzereingabe.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Die Erfindung wird besser verständlich, und ihre verschiedenen Aufgaben, Merkmale und Vorteile werden dem Fachmann durch Bezugnahme auf die begleitenden Zeichnungen erkennbar, in welchen:
Fig. 1 ein Blockdiagramm ist, welches die Schritte veranschaulicht, die erforderlich sind, um eine formale Spezifikation eines Prozesses zu definieren;
Fig. 2 ein Blockdiagramm ist, welches die Schritte veranschaulicht, die erforderlich sind, um eine formale Spezifikation ausführbar zu machen;
Fig. 3 ein Blockdiagramm ist, welches die Primärkomponenten eines Expertensystems veranschaulicht, wie es in der vorliegenden Erfindung verwendet werden kann;
Fig. 4 ein Blockdiagramm ist, welches die Primärkomponenten des Unterstützungssystems der vorliegenden Erfindung veranschaulicht;
Fig. 5 ein Flußdiagramm ist, in welchem die Schritte, welche in der interaktiven Unterstützung des Prozesses ausgeführt werden, in sequentieller Reihenfolge veranschaulicht sind;
Fig. 6 ein Flußdiagramm des Stöbermerkmals bzw. Browser- Merkmals der vorliegenden Erfindung ist;
Fig. 7 ein Flußdiagramm ist, welches die Initiierung und den Betrieb der Werkzeugfunktionen veranschaulicht;
Fig. 8 die Elemente zeigt, welche eine Aktivität umfassen, die in Übereinstimmung mit den Lehren der vorliegenden Erfindung verwendet wird;
Fig. 9A-9C Flußdiagramme von verschiedenen Teilen des Verfahrens zur Verarbeitung von Daten in Übereinstimmung mit den Lehren der vorliegenden Erfindung sind;
Fig. 10 ein Flußdiagramm ist, welches weiterhin das Verfahren zur Verarbeitung von Daten in Übereinstimmung mit den Lehren der vorliegenden Erfindung veranschaulicht;
Fig. 11 ein Flußdiagramm ist, welches weiterhin die Verwendung von graphischen Symbolen innerhalb des Verfahrens zur Verarbeitung von Daten in Übereinstimmung mit den Lehren der vorliegenden Erfindung veranschaulicht;
Fig. 12 ein Flußdiagramm ist, welches ein Verfahren zum Datenretrieval veranschaulicht, welches die Lehren der vorliegenden Erfindung verwendet;
Fig. 13 ein Flußdiagramm ist, welches weiterhin das Verfahren zur Verarbeitung von Daten veranschaulicht, und insbesondere die Ausführung eine Aktivität gemäß den Prinzipien der vorliegenden Erfindung lehrt;
Fig. 14 ein Flußdiagramm ist, welches weiterhin in diagrammartiger Form die Ausführung einer Aktivität veranschaulicht, die nicht unterstützt wird von einem Werkzeug in Übereinstimmung mit den Lehren der vorliegenden Erfindung; und
Fig. 15 ein Flußdiagramm ist, welches die Vollendung des Datenverarbeitungs-Unterprozesses veranschaulicht.

AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG

Alles was ein Benutzer eines Unterstützungssystems tut, kann mit der Erreichung eines Ziels in Beziehung gebracht werden, zum Beispiel die Erschaffung eines neuen Softwareprodukts. Im folgenden wird der Begriff "Prozeß" verwendet um die Schritte zu beschreiben, die zur Erreichung solcher Ziele notwendig sind, einschließlich der Reihenfolge in welcher solche Schritte auftreten und dergleichen. Prozesse sind ein natürlicher Weg zur Strukturierung der Arbeit eines Entwicklers. Die Beschreibung eines Prozesses muß daher das Ergebnis einer vorsichtigen Analyse von Experten sein, darüber, wie ein Designer auf optimalem Weg vorgehen sollte, um das angestrebte Ziel zu erreichen. Um einen Prozeß formal in der vorliegenden Erfindung zu beschreiben, wird eine spezielle Sprache verwendet, welche PDL (Process Description Language, d. h. Prozeßbeschreibungssprache) heißt. Um einem Designer bei der durch den Prozeß definierten Arbeit zu helfen, muß die PDL- Beschreibung ausführbar sein, sonst wäre sie nur eine Beschreibung, welche einer Textbeschreibung vergleichbar ist. Durch Ausführung der Beschreibung erhält der Benutzer des Systems eine Führung durch alle Schritt, welche erforderlich sind, um das angestrebte Ziel zu erreichen.
Man sollte beachten, daß die vorliegende Erfindung zwei verschiedene Elemente umfaßt. Als erstes das Prozeßelement und als zweites das Unterstützungssystem-Element. Bevor er Hilfe bzw. Assistenz erhält, muß der zu unterstützende Prozeß formal beschrieben sein, unter Verwendung von PDL, wie oben beschrieben. Diese Prozeßbeschreibung wird dann (in modifizierter Form) in einen Prozeßbeschreibungs-Interpreter eingegeben, wodurch das Unterstützungssystem Hilfe bei der Erreichung der Prozeßziele bereitstellen kann. Somit veranschaulicht Fig. 1 die anfänglichen Schritte der Prozeßdefinition. Die Prozeßerfordernisse werden in Block 300 analysiert und ein informelles Model des Prozesses wird dann in Block 302 erzeugt (zum Beispiel als Textbeschreibung). In den Blöcken 300 und 302 haben wir eine informelle Angabe darüber, welche Ergebnisse erzeugt werden sollten, und welche unterschiedlichen Schritte in dem Prozeß unternommen werden müssen. Als nächstes wird im Block 304 eine PDL- Prozeßspezifikation erzeugt, während das Informationsmodell des Prozesses, wie Datenschemata, im Block 306 hergestellt werden.
Die PDL-Spezifikation wird durch Systemdesigner gemacht, die für das Unterstützungssystem verantwortlich sind, und welche spezialisiert sind auf die Entwicklung von Prozessen, die maßgeschneidert sind für die Bedürfnisse einer spezifischen Firma und/oder für einen spezifischen Zweck, z. B. Merkmalsdesign, Fehlerberichte, usw. (obwohl auch ein gewöhnlicher Benutzer im Prinzip eine Prozeßbeschreibung entwerfen könnte). Die PDL-Beschreibung enthält zum Beispiel eine Anzahl von Grundmerkmalen. Als erstes beschreibt sie die Aufteilung eines Prozesses in getrennte Unterprozesse, wobei jeder Unterprozeß Aufgaben (Tasks) beschreibt, welche parallel mit Aufgaben aufgeführt werden können, die durch andere Unterprozesse beschrieben werden, um so die Produktivität zu erhöhen. Dies deckt sich eng mit der Situation, in welcher sich ein Designer befindet, der eine moderne Arbeitsstation (Workstation) benutzt, wo eine Anzahl von Computerwerkzeugen parallel ausgeführt werden kann. Jedes der Werkzeuge würde dann durch irgendeinen Prozeß in PDL beschrieben werden, wobei der Unterprozeß beschreibt, was durch die Verwendung des Werkzeuges erzielt werden soll und wie das Werkzeug mit den anderen Unterprozessen oder Werkzeugen wechselwirkt. Zweitens beschreibt sie wie die durch verschiedene Unterprozesse beschriebenen Aufgabe wechselwirken, durch spezifizieren von Ereignissen, welche zwischen den Prozessen asynchron kommuniziert werden. Drittens beschreibt die PDL-Beschreibung Bedingungen für den Beginn und das Ende eines spezifischen Unterprozesses. Viertens beschreibt sie verschiedene Schritte und Aktivitäten, welche einen Unterprozeß umfassen, z. B. Edit, Kompilieren, Linken, Testen, und für jede der Aktivitäten die Bedingungen, welche erfüllt sein müssen, um jenen Schritt oder jene Aktivität zu starten. Schließlich veranschaulicht die PDL- Beschreibung die Wechselwirkung mit dem Benutzer, indem vorgeschrieben wird, wie Information über den Zustand des Prozesses präsentiert werden soll, und welche möglichen Schritte im gegenwärtigen Zustand des Prozesses passend ausgeführt werden sollen.
Damit der Benutzer seine eigenen Entscheidungen treffen kann, und um zu verhindern, daß das Unterstützungssystem dadurch als Hindernis empfunden wird, daß der Benutzer auf eine bestimmte Sequenz von Aktivitäten beschränkt ist, sind drei Eigenschaften der PDL-Beschreibung wesentlich. Erstens bestimmt nur der Zustand der Prozesses darüber, was getan werden kann; dies stellt sicher, daß die Reihenfolge, in welcher Aktivitäten durchgeführt werden, von minimaler Wichtigkeit ist. Zweitens stellt die PDL-Beschreibung eine Flexibilität sicher, indem dem Benutzer eine Anzahl von Vorschlägen präsentiert wird, welche relevant sind für den gegenwärtigen Zustand des Prozesses, wobei der Benutzer eine freie Wahl treffen kann. Somit zwingt das Unterstützungssystem den Benutzer nicht, eine bestimmte Auswahl von Aktionen zu folgen. Drittens kann der Benutzer Aktivitäten direkt ausführen, ohne Verwendung der Möglichkeiten, die von der vorliegenden Erfindung präsentiert werden. Diese drei Eigenschaften der PDL-Beschreibung stellen sicher, daß die verschiedenen Aufgaben, welche der Entwickler auszuführen hat, auf eine Weise bearbeitet werden können, die nicht als zu starr empfunden wird.
In Fig. 2 werden die Schritte gezeigt, welche erforderlich sind, damit die PDL-Beschreibung des in Fig. 1 definierten Prozesses ausgeführt werden kann, und somit Hilfe bzw. Assistenz gegeben wird für irgendeinen bestimmten Prozeß. Als erstes wird in Block 350 die PDL-Beschreibung des Prozesses geschaffen. Diese Beschreibung wird dann im Block 352 analysiert und in das geeignete Format für den Assistenzlogikinterpreter umgewandelt. Sobald die Beschreibung korrekt formatiert ist, wird sie in den Assistenzlogikinterpreter 44 (siehe Fig. 4) bei Block 354 geladen, so daß das System die notwendige Unterstützung für den Benutzer bereitstellen kann. Diese Schritte werden von einem Systemprogrammierer unternommen, um das Unterstützungssystem vorzubereiten, damit es die Hilfe geben kann, die in der PDL- Beschreibung vorgesehen ist. Somit macht dies den zweiten Aspekt der Erfindung bereit, d. h. das Hilfselement. Wenn der Benutzer sich entschließt, mit Aufgaben bzw. Tasks zu arbeiten, die durch einen bestimmten Prozeß beschrieben werden, startet der Assistenzlogikinterpreter 44, um das konvertierte Format der PDL-Beschreibung zu interpretieren, wodurch dem Entwickler, der versucht seine Aufgabe zu lösen, Hilfe gegeben wird. Somit ist ein weiterer Name für die PDL-Beschreibung "Assistentenlogik", da die PDL die Logik der Hilfe bzw. des Assistenten beschreibt, d. h. wie er arbeitet.
Während der Ausführung der Assistentenlogik, wird eine Anzahl von "Schatten"-Objekten in dem Assistenten geschaffen. Diese Schattenobjekte stellen "reale" Objekte dar, Dateien, Beschreibungen, usw., welche der Entwickler erzeugt und mit denen er als Teil seiner Aufgabe arbeitet. Diese Schattenobjekte werden in der Assistentenlogik benutzt, um den Status jedes der realen Objekte bezüglich des die Arbeit beschreibenden Prozesses zu verfolgen. Indem der Zustand der Objekte verfolgt wird, können Bedingungen geprüft werden, um zu sehen, ob neue Aktionen passend sind, um in jenem Fall diese dem Benutzer vorzuschlagen. Diese Schattenobjekte sind Teil des in Fig. 1 beschriebenen Informationsmodells.
In Fig. 3 wird ein Blockdiagramm gezeigt, welches die Primärkomponenten eines Expertensystems zeigt, ähnlich dem Expertensystem 20 der vorliegenden Erfindung. Das typische Expertensystem stützt sich auf einen Wissenskörper, welcher während der Erstellung des Systems selbst akkumuliert wird. Dieser Wissenskörper sitzt innerhalb der Wissensbank 30 des Expertensystems 20. Information, welche innerhalb der Wissensbank 30 gespeichert ist, kann in kategorische Einheiten und diskrete Abschnitte der Wissensbank 30 aufgespalten werden. Dieser Aspekt ist durch die #1KB und die #2KB gezeigt, welche in der Wissensbank 30 enthalten sind. Das erforderliche Wissen für den korrekten Betrieb des Unterstützungssystems 8 muß für das Expertensystem 20 explizit und zugänglich sein.
Das allgemeine Problemlösungselement des Expertensystems 20 umfaßt die Folgerungsmaschine (inference engine) 32. Die Folgerungsmaschine 32 ruft Regeln auf, welche innerhalb der Regelbank 34 gespeichert sind. Die Folgerungsmaschine 32 bestimmt wie die innerhalb der Regelbank 34 enthaltenen Regeln auf das vorliegende Problem angewendet werden, und die Reihenfolge, in welcher diese Regeln ausgeführt werden sollen. Viele der Regeln in dem Expertensystem 20 sind in Form von Heuristiken, welche aus vereinfachten Ansätzen für die Suche einer Lösung bestehen. Im Betrieb tastet die Folgerungsmaschine 32 Daten in der Datenbank 36 ab, wobei Daten mit den Kriterien aus der Regelbank 34 verglichen werden. Seinerseits erzeugt der heuristische Ansatz, welcher sich auf die Regelbank 34 bezieht, Information für die Wissensbank 30. Anfänglich stammen die in dem Prozeß verwendeten Regeln von einem Experten 38, ohne daß eine spezifische Reihenfolge für die Regeln erforderlich ist. Ferner unterliegt die Information der Wissensbank 30 während des Betriebs des Expertensystems 20 einer Echtzeit- Aktualisierung.
Alternativ kann der Betrieb des Expertensystems 20 voranschreiten indem der Induktionsmotor 40 (induction engine) verwendet wird, um Regeln für die Regelbank 34 zu formulieren. Die Induktionsmaschine 40 arbeitet durch Ableitung von allgemeinen Prinzipien, welche anwendbar sind auf den Prozeß, aus bestimmten Informationen, die innerhalb der Wissensbank 30 gefunden werden. Der Experte 38 kann entweder Regeln direkt bereitstellen oder Beispiele geben, welche durch die Induktionsmaschine 40 in Regeln umgewandelt werden können.
In Fig. 4 ist ein Blockdiagramm des Unterstützungssystems gezeigt, welches dessen Komponententeile in Übereinstimmung mit den Lehren der vorliegenden Erfindung zeigt. Als computergestütztes System, um ihre Vorteile bereitzustellen, sitzt die bevorzugte Ausführung der vorliegenden Erfindung in einem Computer 41, welcher eingerichtet ist, vorgefertigte Sequenzen von Logikaussagen (d. h. Programme und/oder Firmware) auszuführen, und in einen Speicher zu schreiben bzw. aus dem Speicher zu lesen. Von zentraler Bedeutung für den Betrieb des Unterstützungssystems 8 ist der Assistent 12. Der Assistent 12 umfaßt das Assistentenlogikmodul 42 und den Assistentenlogikinterpreter 44. Das Assistentenlogikmodul 42 besteht aus einer umgewandelten PDL-Beschreibung, wie oben beschrieben, welche den Prozeß definiert und das zu erreichende Ziel darstellt.
Der Assistentenlogikinterpreter 44 beherbergt das Expertensystem 20. In einer bevorzugten Ausführung wird das Expertensystem in ProKappa-Sprache programmiert, entworfen durch Intellecorp, Inc. 1975 E1 Camino Real West, Mountain View, California. Die vorliegende Erfindung fügt der gelieferten ProTalk-Sprache zur Erhöhung der Betriebseinfachheit Grafik hinzu. Der Assistent 12, und speziell der Assistentenlogikinterpreter 44 kommunizieren durch den Botschafts-Abwickler 46 mit Werkzeugen in dem Unterstützungssystem, einschließlich Compilern und Editoren, ohne auf selbige beschränkt zu sein. Das Werkzeug und die Werkzeugfunktionen sind die grundlegenden Baublöcke anhand von welchen der Prozeß ausgedrückt wird, und der Weg, durch welchen der Prozeß in dem Unterstützungssystem implementiert wird. Auf diese Weise kann das meiste des prozeßspezifischen Wissens der PDL-Beschreibung zugewiesen werden, statt in den Werkzeugen. Daher ist es leichter, die verschiedenen Werkzeuge in anderen Prozessen wiederzuverwenden, und die Werkzeuge müssen nicht verändert werden, wenn der Prozeß modifiziert wird. Mit dem Assistenten 12 ist ebenfalls die Datenbank 36 verbunden. Die Datenbank 36 speichert Informationen, welche von dem Unterstützungssystem 8 allgemein erzeugt oder verarbeitet wurden, und stellt einen Zugriff für den Assistentenlogikinterpreter 44 und die Assistentenlogik 42 auf vorher gespeicherte Prozeßinformationen bereit.
Um die Produktivität bei der Benutzung des Unterstützungssystems 8 zu erhöhen, arbeitet jedes der Werkzeuge 22 parallel mit jedem anderen Werkzeug 22 (in unterschiedlichen UNIX-Prozessen, wenn auf einer UNIX-Platform implementiert). Jedes Werkzeug wechselwirkt mit dem Assistenten 12 durch Austausch von Nachrichten (messages) betreffend den gegenwärtigen Status von Aktionen, die von jenem Werkzeug unternommen werden. Somit geschehen viele gleichzeitige Aktivitäten innerhalb des Unterstützungssystems 8, und jede dieser gleichzeitigen Aktivitäten wird von dem Assistenten 12 überwacht und analysiert.
In Fig. 4 ist auch das Benutzerschnittstelle-Aktivitätsfenster 48 des Assistenten veranschaulicht. Die Benutzerschnittstelle 48 übermittelt dem Benutzer 16 den Status des Prozesses und stellt dem Benutzer Führung bei der Durchführung der durch den Prozeß definierten Aktivitäten bereit. Die Benutzerschnittstelle umfaßt das einzige Element des Assistenten 12, das dem Benutzer 16 erscheint. Das Expertensystem 20 in dem Assistenten analysiert die Aktionen des Benutzers 16 (durch Nachrichten, die aus den Werkzeugen empfangen werden, oder durch Entscheidungen, die in der Benutzerschnittstelle des Assistenten getroffen werden) im Kontext des gegenwärtigen Prozesses, und erzeugt die geeignete grafische Information für die bestimmte Situation.
Innerhalb der Benutzerschnittstelle 48 ist die Übermittlung von Information unter Verwendung einer Anzahl von verschiedenen Darstellungen möglich. Die dargestellte Information kann z. B. die Form von Listen annehmen, oder kann die Form von grafischen Darstellungen und Flußdiagrammen annehmen. Die vielzähligen verfügbaren Schnittstellen sind mittels des Blocks 50 dargestellt, welcher eine erste alternative Schnittstelle wiedergibt, und mittels des Blocks 52, welcher eine zweite alternative Schnittstelle wiedergibt. Der Benutzer hat die Wahl darüber, welcher Schnittstellenmodus für seine Fähigkeiten und die vorliegende Aufgabe am geeignetsten ist.
In Fig. 5 ist ein ausführlicheres Flußdiagramm dargestellt, welches beschreibt wie der Assistent in der Laufzeit arbeitet, wenn die Prozeßbeschreibung in den Assistentenlogikinterpreter 44 geladen wird, wie oben beschrieben. Aus dem Flußdiagramm geht hervor, daß der Assistent 12 von einer Anzahl von Faktoren betreffend die Werkzeuge 22, welche Teil des Unterstützungssystems 8 sind, abhängt. Erstens muß der Assistent 12 in der Lage sein, die Werkzeuge 22 zu starten und die Werkzeugfunktionen aufzurufen. Dies wird erreicht durch einen Botschafts-Abwickler 46, welcher sich um die Kommunikation kümmert. Auch müssen die Werkzeuge über verschiedene stattfindende Ereignisse berichten, da die meisten der Werkzeugereignisse relevant sind für den Zustand des Prozesses und die Erreichung des Entwurfsziels, wie die Modifikation einer Datei, die Erzeugung einer Schnittstellenbeschreibung, oder das Kompilieren eines Programms. Über welche Ereignisse ein Werkzeug berichten sollte, wird entschieden, wenn die Prozeßbeschreibung, welche die Aufgabe beschreibt, entworfen wird.
Da ein Werkzeug mit dem Assistenten 12 kommunizieren kann egal wo es gestartet wurde (aus dem Assistenten-Aktivitätsfenster, aus einem Datenbank-Browser, oder aus einer UNIX-Shell), erlaubt es das System 8 dem Benutzer 16, Werkzeuge durch andere Mittel als den von dem Assistenten abgewickelten Aktivitätsfenstern 48-52 zu starten. Der Benutzer kann auch verschiedene Werkzeugfunktionen direkt aus den Werkzeugen ausführen, welche nicht notwendigerweise als Vorschläge in den Aktivitätsfenstern angezeigt werden. Daher müssen der Assistent 12 und die Assistentenlogik 42 in der Lage sein, jederzeit Ereignisse zu verarbeiten, welche aus unterschiedlichen Werkzeugen stammen. Dies ist möglich, da die PDL-Beschreibung, welche beschreibt was zu tun ist wenn ein Ereignis auftritt, sich nur auf den gegenwärtigen Zustand des Prozesses bezieht, und nicht auf die Reihenfolge, in welcher Ereignisse stattgefunden haben (dies ist möglich unter Verwendung der Auslösemechanismen bzw. Triggermechanismen des zugrunde liegenden Expertensystems). Jedes Ereignis wird daher anhand des Zustandes des Prozesses interpretiert, unabhängig davon ob es in Beziehung steht zu einem Vorschlag aus dem Assistenten 12 oder nicht.
Es folgt nun eine ausführliche Beschreibung des Flusses der Fig. 5. Bei Block 60 wählt der Benutzer die Aufgabe bzw. den Task, den er oder sie ausführen soll. Zum Beispiel könnte die Aufgabe darin bestehen, ein neues Softwareprodukt zu entwerfen, oder sich um einen Fehlerbericht zu kümmern. In Block 61 wählt der Assistent 12 die geeignete PDL-Beschreibung der bestimmten Aufgabe (dies geschieht intern und automatisch innerhalb des Assistenten). Diese Beschreibung wurde vorher analysiert und umgewandelt, wie in Fig. 2 beschrieben. In Block 62 wird der gegenwärtige Zustand des die Aufgabe beschreibenden Prozesses in den Assistenten 12 aus der Datenbank 36 geladen. Dieses Laden ist am relevantesten, wenn der Benutzer 16 vorher die Aufgabe bearbeitet und den Status der vorangegangenen Arbeit abgespeichert hat. Im Block 63 macht der Assistent 12 Vorschläge für die auszuführenden Aktionen, auf der Grundlage des gegenwärtigen Zustandes. Die Art und Weise, in welcher die Vorschläge abgebildet werden, hängt von der verwendeten Benutzerschnittstelle ab, wie oben beschrieben.
Der Block 65 beschreibt den Assistenten, wie er darauf wartet, daß Ereignisse in dem Unterstützungssystem 8 auftreten. Die Verzweigung zum Block 66 zeigt an, daß ein Werkzeug das Ergebnis eines Funktionsaufrufs als ein Ereignis an den Assistenten 12 berichtet. Als Antwort auf das im Block 66 erzeugte Ereignis, verändert der Block 67 den Zustand des Prozesses, da es abgeleitet ist aus den in dem Unterstützungssystem stattfindenden Ereignissen. Wenn der Benutzer 16 eine Wahl getroffen hätte bezüglich einer der Vorschläge des Assistenten aus dem Aktivitätsfenster, wäre der Block 68 aktiv. Wenn der Verzweigung vom Block 68 zum Block 69 gefolgt wird, und der innerhalb des Aktivitätsfensters ausgewählte Vorschlag mit der Ausführung einer Werkzeugfunktion einhergeht, wird das Werkzeug 22 gestartet (wenn notwendig) und die korrekte Funktion über den Botschafts-Abwickler 46 aufgerufen. Im Block 70 wird der Zustand des Prozesses verändert, was das Aufrufen der Werkzeugfunktion wiedergibt. Wenn jedoch der von dem Benutzer 16 gewählte Vorschlag keinen Aufruf der Werkzeugfunktion mit sich bringt, wird der innere Zustand des Prozesses nur durch die von dem Benutzer 16 getroffene Wahl verändert. In diesem Fall gibt der Benutzer 16 gewöhnlich an, daß irgendeine manuelle Aktivität in dem Prozeß durchgeführt wurde.
Nachdem die Zustandsveränderung bewirkt wurde, deduziert der Assistent 12 im Block 72 die Auswirkungen der Veränderung. Als ein Resultat der in Block 72 durchgeführten Analyse, kann der Assistent dann automatisch andere Werkzeuge aufrufen, im Block 73. Ferner, als ein Ergebnis der Analyse im Block 72, kann eine Konsistenzüberprüfung zwischen verschiedenen Informationselementen automatisch im Block 74 herbeigeführt werden, und die dort gefundenen Fehler würden dann im Block 75 berichtet. Zusätzlich kann der Assistent 12 als Ergebnis der Analyse des Blocks 72 einen automatischen Werkzeugaufruf als nicht notwendig ansehen, und statt dessen einen neuen Satz von Vorschlägen für den Benutzer 16 erzeugen. Der neue Satz von Vorschlägen beruht auf dem neu geschaffenen Prozeßzustand, woraufhin der Zyklus wiederholt wird. Wenn jedoch der Benutzer 16 abzubrechen wünscht (quit), geschieht dies im Block 77, und der Zustand des Prozesses wird im Block 78 gespeichert.
Unter Bezugnahme nun auf Fig. 6, wird der Aspekt des Browser- Servers 90 der vorliegenden Erfindung beschrieben, welcher ein unabhängiges Element des Unterstützungssystems 8 umfaßt. Der Browser-Server 90 erlaubt es dem Benutzer 16 nach Objekten in der Systemdatenbank 36 zu suchen, und jene Objekte ohne Führung des Assistenten 12 auszuwählen. Der Browser-Server 90 stellt dem Benutzer 16 keine Vorschläge bereit. Gefundene Objekte, wie Beschreibungen, Flußdiagramme, Programme, usw. können durch den Browser-Server 90 untersucht werden, und Werkzeugoperationen bezüglich der Objekte können initiiert werden. In Fig. 6 beginnt der Browser-Server 90 mit dem Startbrowserblock 92. Nach Anlauf des Browser-Servers 90 kann der Benutzer 16 bei Block 93 und 94 nach einem Objekt in der Systemdatenbank 36 suchen und es auswählen. Wenn des Objekt ausgewählt ist, kann bei Block 95 ein Menü angezeigt werden von für das Objekt verfügbaren Operationen. Der Block 96 startet das Werkzeug 22, und diese Tatsache wird dem Assistenten 12 in Block 98 berichtet. Dies gestattet, daß die Assistentenansicht des Systems konsistent ist betreffend das Wissen darüber, welche Ereignisse stattfinden. Somit kann der Benutzer 16 mit dem Unterstützungssystem 8 auf eine Vielzahl von Weisen wechselwirken, wovon eine durch den Browser-Server 90 ist, wobei immer noch Unterstützung von dem Assistenten empfangen wird.
In Fig. 7 ist ein Flußdiagramm des Werkzeugaufrufs abgebildet. Da der Benutzer 16 die Werkzeuge 22 initiieren kann, ohne Hilfe aus dem Assistenten 12, kann der Benutzer 16 auch unterschiedliche Werkzeugfunktionen ausführen, welche nicht notwendigerweise als Vorschläge in dem von dem Assistenten 12 abgewickelten Aktivitätsfenster angezeigt werden (wie oben beim Browser-Aspekt beschrieben). Somit müssen der Assistent 12 und die Assistentenlogik 42 in der Lage sein, mit Ereignissen umzugehen, die gleichzeitig aus den verschiedenen Werkzeugen stammen. Dies ist möglich, da die PDL-Beschreibung, welche beschreibt was zu tun ist wenn ein Ereignis auftritt, sich nur auf den gegenwärtigen Zustand des Prozesses bezieht, und nicht auf die Reihenfolge, in welcher Aktivitäten ausgeführt worden sind, wie oben beschrieben. Jedes Ereignis wird daher anhand des Zustandes des Prozesses interpretiert, unabhängig davon, ob oder ob nicht der Assistent es als Vorschlag weitergeleitet hat.
Folglich muß das Werkzeug auf die folgende Art arbeiten, damit ein Werkzeugentwickler die durch den Assistenten 12 erzwungenen Forderungen erfüllen kann. Als erstes wird die Werkzeugfunktion bei Block 370 gestartet, und diese Tatsache wird dem Assistenten berichtet. Nach dem Start kann das Werkzeug einen Aufruf einer Werkzeugfunktion in Block 371 akzeptieren. Die Werkzeugfunktion wird entweder durch den Assistenten 12 über Block 372 oder durch die Werkzeugbenutzerschnittstelle über Block 374 aufgerufen. Als nächstes wird die Werkzeugfunktion bei Block 376 ausgeführt, und wenn es durch den Prozeß erforderlich ist, werden die sich ergebenden Resultate bei Block 378 dem Assistenten 12 berichtet. Erneut werden die für den Prozeß relevanten Werkzeugfunktionen (und welche daher dem Assistenten berichtet werden müssen) während des Entwurfs des Prozesses bestimmt. Der Zyklus wird wiederholt, und das Werkzeug ist bereit dafür, daß die nächste Werkzeugfunktion initiiert wird, aus dem Warten auf den Aufrufblock 371, oder das Werkzeug wird bei Block 380 angehalten.
In Fig. 9 ist ein PDL-Diagramm eines Beispiels einer typischen Prozeßbeschreibung gezeigt, welche die Hilfe bzw. Assistenz spezifiziert, die in einem der Prototypen der vorliegenden Erfindung gegeben wird, welche illustrativ die verschiedenen Schritte beschreibt, welche eine Sekretärin ergreifen muß bei der Abwicklung einer Besprechung. Da die Prozeßbeschreibung durch grafische Symbole ausgedrückt wird, verwendet das Flußdiagramm der Fig. 9 solche grafischen Symbole in der folgenden Beschreibung. Ferner wandelt das System 8 das grafische Flußdiagramm in ein Format um, welches von dem Assistentenlogikinterpreter interpretiert werden kann, wie oben beschrieben.
Die in den Fig. 9-15 gezeigte Textinformation ist eine partielle Ansicht des kompletten Inhalts des Flußdiagramms. An jedes grafische Symbol können unterschiedliche Arten von Textinformation angehängt sein; ein informeller Kommentar, implizit oder explizit spezifizierte, ausführbare Codes, Dokumentation, Parameterspezifikationen, usw.. Die in den Fig. 9-15 präsentierte Ansicht zeigt nur die Parameterspezifikationen für die Icons, um die Diagramme zu vereinfachen und sie besser verständlich zu machen. In dieser Ansicht werden sowohl Variablen als auch Konstanten als Parameter spezifiziert, wobei Variablen durch ein Fragezeichen als erstes Schriftzeichen bezeichnet werden. In dem grafischen Editor, welcher diese Sprache unterstützt, kann diese Ansicht in irgendeine andere der vorher beschriebenen Ansichten verändert werden.
In Fig. 8 werden weitere Beispiele der Komponenten der PDL- Icons gezeigt. Ein grundlegender Baublock in PDL ist das Aktivitätskonstrukt, welches die Bedingungen und Wirkungen einer Aktivität beschreibt und die in Fig. 8 veranschaulichte allgemeine Struktur annimmt. Das Aktivitäts-Icon 386 wird auf der einen Seite durch die Vorbedingungs-Icons 388 umgeben. Die Vorbedingungs-Icons 388 beschreiben die notwendigen Bedingungen, daß die Aktivität ausgeführt werden kann. Zum Beispiel sind in Fig. 11 die Symbole 140, 142 und 144 alles Vorbedingungen. Das Aktivitäts-Icon 386 arbeitet als eine Referenz auf das komplette Konstrukt, d. h. alle Vorbedingungen und Wirkungen. Das Wirkungs-Icon 390 kann eine auszuführende Operation darstellen, sei es von dem Benutzer 16 oder automatisch durch den Assistenten 12. Es bestehen auch eine Anzahl von unterschiedlichen, vordefinierten Icons, welche spezifische Bedingungen und Wirkungen darstellen, z. B. Menü- Icons, Datei-Icons, Uhren-Icons usw.. Vordefinierter ausführbarer Kode, Dokumentation, usw. werden diesen Icons angehängt, und den Icons können Parameter gegeben werden. Man beachte, daß alle in einer Aktivität eingeführten Variablen für die Aktivität lokal sind.
Wie oben ausgesagt, sind Schattenobjekte, welche für den Assistenten intern sind, Halter von Zustandsinformation. Um Dokumente, Programme, die verschiedenen Prozesse, Unterprozesse, usw. zu verfolgen, werden sie im Assistenten als Schattenobjekte dargestellt. Diese Schattenobjekte werden erzeugt, wenn die entsprechenden Realobjekte geschaffen werden. Es gibt in PDL ein spezifisches Icon, das Instantiations-Icon (Instantiation bedeutet im allgemeinen die Schaffung eines bestimmten Beispiels für eine Schablone bzw. Template, wie eine Beschreibung eines Schattenobjekts), welches die Schaffung eines Schattenobjekts darstellt. Im Falle des Instantiations- Symbols 102 in Fig. 9, wird eine Sekretärsaufgabe instantiiert. Das Diagramm der Sekretärsaufgabe beschreibt im allgemeinen eine Anzahl von möglichen Aufgaben und viele verschiedene Treffen können unter Verwendung dieser Beschreibung arrangiert werden. Wenn die Beschreibung ausgeführt wird, um einen Benutzer beim Arrangieren eines bestimmten Treffens zu helfen, muß diese bestimmte Treffarrangement-Aufgabe eine Darstellung haben, d. h. ein Schattenobjekt. Das Instantiations-Symbol 102 stellt die Schaffung einer solchen Instanz da, welche dann Statusinformation über diese bestimmte Treffarrangement-Aufgabe halten kann, und auf welche dann von anderen Teilen des Diagramms hingewiesen werden kann.
In den Flußdiagrammen der Fig. 9A-9C bezieht sich der beschriebene Prozeß auf die von einer Sekretärin geforderten Aufgaben zur Arrangierung eines Geschäftstreffens oder dergleichen. Die Diagramme zeigen verschiedene Aspekte des Prozesses. Der oberste Teil, Fig. 9A, ist eine beschreibende Veranschaulichung der Startbedingungen des Prozesses, während der Mittelteil, Fig. 9B, das Aufteilen des Prozesses in Unterprozesse beschreibt. Der Sekretärsprozeß kann verschiedene Unterprozesse haben, wie es für jeden anderen von dem Unterstützungssystem 8 abgewickelten Prozeß möglich ist. Die in Fig. 9B dargestellten Unterprozesse sind der Material- Unterprozeß, der Bekanntmachungs-Unterprozeß, der Treffen- Unterprozeß 118, der Texteditier-Unterprozeß 119 und der Protokollabwicklungs-Unterprozeß 122. Der Material-Unterprozeß 108 beschreibt wie die für das besondere Treffen erforderlichen Materialien zu sammeln sind, während der Bekanntmachungs- Unterprozeß 116 beschreibt, wie Informationen an die Beteiligten des Treffens zu schicken sind. Der Treffen- Unterprozeß 118 beschreibt wie das Treffen durchzuführen ist, und der Texteditier-Unterprozeß 119 beschreibt wie Text einzugeben ist (z. B. welches Werkzeug zu benutzen ist). Dez Protokollabwicklungs-Unterprozeß 122 beschreibt wie die Unteraufgabe der Erstellung eines Protokolls abzuwickeln ist. Der untere Teil, Fig. 9C, beschreibt die Anhaltebedingung des Prozesses. Man bemerke, daß es andere Ansichten des Prozesses (Schnittstellenansicht, Aktivitätsansicht, usw.) gibt, welche nicht in den Fig. 9A-9C gezeigt sind.
Jeder der Unterprozesse beginnt automatisch, sobald die Kriterien für die Instantiierung erfüllt worden sind, was beispielsweise sein kann, daß ein Dienst, den der Prozeß bereitstellt, angefordert wurde (wie die Texteingabe aus irgend einem anderen Unterprozeß). Eine Sequenz von Prozessen oder Unterprozessen kann auch beschrieben werden, und in diesem Fall ist das für die Aufgabe eines folgenden Prozesses wichtige Ereignis das Ereignis "Abgeschlossen", das von dem vorangegangenen Prozeß berichtet wird. Der Übergang von Information, welcher diagrammartig durch Pfeile angegeben wird, wie den "Edit"-Pfeil 112 und den "Material fertig"-Pfeil 114 in Fig. 10, veranschaulicht weiter den Austausch von Ereignissen, welche für die Unterprozesse relevant sind, die gleichzeitige Aufgaben beschreiben. Die Pfeile haben keine semantische Bedeutung in dem Diagramm und sind nur eine informelle Weise zur Beschreibung des Informationsflusses. Der reale Austausch von Information wird durch die Folgerungsmaschine des zugrunde liegenden Expertensystems abgewickelt, und wird ausführlich in den entsprechenden Unterprozessen beschrieben.
Das Icon 100 stellt die Tatsache dar, daß das Unterstützungssystem 8 seinen Betrieb beginnt, indem es ein äußeres Ereignis empfängt, welches den Prozeß initiiert (entsprechend beispielsweise, daß der Benutzer eine neue Treffenarrangement-Aufgabe erzeugt); die Parameter des Ereignisses sind der Name ("Start") und die Art des zu startenden Prozesses ("Sekretär"). Die Instantiation geschieht bei Icon 102. Das Symbol 104 stellt die Einstellung von Initialwerten dar, welche mit dem Sekretärsprozeß in Beziehung stehen, und< wird als eine Zustandsveränderung des Prozesse beschrieben (der Aspekt "gestartet" des Prozesses wird auf Wahr gestellt). Das Aktivitäts-Icon 101 stellt die abgeschlossene Aktivität dar, wie oben beschrieben.
Nun unter Bezugnahme auf die verschiedenen in Fig. 9 gezeigten Teile zeigt der Edit-Pfeil 112 den Material-Unterprozeß 108 an, der auf einen Dienst weist, welcher von einem anderen Unterprozeß abgewickelt wird. In diesem Fall wird der Texteditier-Unterprozeß 119 von innerhalb des Material- Unterprozesses 108 verwendet. Der Texteditier-Unterprozeß 119 beschreibt wie ein Texteditor zu verwenden ist, was parallel und gleichzeitig ausgeführt werden kann mit Aktivitäten, die von anderen Unterprozessen in dem System beschrieben werden. Sobald der Material-Unterprozeß 108 und der Bekanntmachungs- Unterprozeß 116 ihre jeweiligen Aufgaben abgeschlossen haben, geschehen die fertigen Ereignisse 114 und 115. Das "Notizen vom Treffen"-Ereignis 120 aus dem Treffen 118 zeigt an, daß Daten aus dem Treffen verfügbar sind. Die Treffendaten werden verwendet von dem das Protokoll abwickelnden Unterprozeß 122, welcher die Arbeiten darstellt, die nachdem Treffen erledigt werden müssen. Das Edit-Ereignis 112 führt zu weiterem Texteditieren durch den Texteditier-Unterprozeß 119. Somit veranschaulicht die Fig. 9 Ereignisaustauschvorgänge zwischen Unterprozessen, welche Aufgeben beschreiben, die parallel ausgeführt werden können. Die Aufgaben des Material- Unterprozesses 108 und des Bekanntmachungs-Unterprozesses 116 können beispielsweise parallel geschehen, wie durch das Fehlen des Austauschs von Synchronisier-Ereignissen zwischen ihnen aufgezeigt wird.
In Icon 124 beschreibt die Bedingung den Zustand, wo der angehaltene Aspekt in irgendeinem Unterprozeß wahr ist. In Icon 126 sagt die Bedingung, daß ein Prozeß von der Art "Protokollabwicklung" sein muß, um für diese Aktivität von Interesse zu sein. In Icon 128 wird der Sekretärsprozeß (identifiziert durch ?Prozeß) gefunden, welcher den angehaltenen Unterprozeß besitzt. Schließlich wird der Sekretärsprozeß in Icon 130 angehalten.
In Fig. 10 wird auch das Verfahren zur Verarbeitung von Daten gemäß den Lehren der vorliegenden Erfindung veranschaulicht. Dies stellt eine Instantiierung des Bekanntmachungs- Unterprozesses 116 aus Fig. 9 dar. Somit muß die Sekretärsaufgabe gestartet worden sein, was durch die Symbole 130 und 132 dargestellt wird (der gestartete Aspekt ist wahr und die Art des Prozesses ist "Sekretär"). Wenn die Vorbedingung wahr ist, wird die Aktivität 135 begonnen, und die Instantiierung des Bekanntmachungs-Unterprozesses 116 wird im Symbol 136 bewirkt (der Bezug auf diese Instanz ist "Unterprozeß"). Dann werden bei Symbol 138 die Anfangswerte des Bekanntmachungs-Unterprozesses als Zustandsinformation aufgezeichnet.
In Fig. 11 wird ausführlicher das Verfahren zur Verarbeitung von Daten gemäß den Lehren der vorliegenden Erfindung veranschaulicht, und insbesondere eine Edit-Aktivität 145. Die Mechanismen des zugrunde liegenden Expertensystems werden erfassen, wann die Vorbedingungen der Aktivität wahr sind. Damit die Edit-Aktivität 145 möglich wird, zeigt das Symbol 140, daß der Bekanntmachungs-Unterprozeß gestartet sein muß. Das Symbol 142 zeigt an, daß Daten, welche eine temporäre Speicherung erfordern, erzeugt werden durch die gegenwärtige Aktivität, und daher muß ein temporärer Dateiname bekannt sein, um die Information zu speichern (die Art und Weise in welcher dies geschieht, wird in dem Code-Abschnitt des Symbols beschrieben, welcher hier nicht gezeigt ist). Als nächstes arbeitet das Menü 144 als Beschreibung der Wechselwirkung mit dem Benutzer 16. In der PDL-Sprache abstrahiert das Menüsymbol die Art und Weise, in welcher der Assistent 12 mit dem Benutzer 16 wechselwirkt, beispielsweise können dem Benutzer 16 Aktivitätslisten präsentiert werden. Als erstes stellt das Symbol den Text (in diesem besonderen Fall "Schreibbekanntmachung") dar, welcher dem Benutzer 16 präsentiert < wird. Der präsentierte Text beschreibt eine Aktivität, welche von dem Benutzer 16 ausgeführt werden kann oder werden sollte. Das Menü 144 impliziert auch ein Objekt, z. B. eine Datei, Code, usw., über welchem die Aktivität ausgeführt wird (in diesem Fall die durch ?temp dargestellt temporäre Datei). Ferner stellt das Menü 144 eine Bedingung dar. Bevor der Benutzer 16 explizit die Aktivität in der Aktivitätsliste auswählt, ist diese Bedingung immer falsch, und die Wirkungen, wie die Ausführung einer Werkzeugfunktion oder eine Zustandsveränderung, werden nicht bewirkt. Wenn der Benutzer 16 die Aktivität in der Benutzerschnittstelle auswählt, wird die Bedingung wahr, und Wirkungen werden ausgeführt. In diesem Fall, wenn der Benutzer 16 die Schreibbekanntmachung-Auswahl in der Aktivitätsliste wählt, wird eine Edit-Ereignis geschickt (entsprechend dem Pfeil 112 in der Fig. 9) in Symbol 146 an einen anderen Unterprozeß, welcher eine Edit-Aufgabe anfordert. Diese Anforderung wird von dem Texteditier-Unterprozeß (hier nicht abgebildet) abgewickelt, wobei der Editor gestartet wird und der Benutzer 16 dann den Editor verwendet, um die Bekanntmachung des Treffens zu schreiben.
In Fig. 12 werden weitere Details der Datenverarbeitung der vorliegenden Erfindung gezeigt. Die Beschreibung des Bekanntmachungs-Unterprozesses 116 wird fortgesetzt mit einer Aktivität 51, welche das Retrieval von Daten umfaßt, die sich darauf beziehen, wer an dem Treffen teilnehmen wird. Das Symbol 150 zeigt an, daß Information geholt werden muß, wenn der Zustand des "Andere"-Aspekt des Prozesses falsch ist. Das Symbol 152 könnte zu einem Menüfenster führen, welches die Eingabe der zum Treffen erwarteten anfordert, was dann in der Codeansicht des Icons 152 beschrieben werden würde, unter Verwendung von basischen Fenster-Grundelementen, die von dem System unterstützt werden. Das Symbol 154 stellt den Zustand des Bekanntmachungs-Unterprozesses 116 dar und symbolisiert, daß das Retrieval der Namen stattgefunden hat (der Zustand des "Andere"-Aspekts ist nun wahr). Diese Aktivität wird durch die unten im Zusammenhang mit Fig. 13 beschriebene Aktivität ausgelöst.
In Fig. 13 wird die Beschreibung des Bekanntmachungs- Unterprozesses fortgesetzt. Beginnend mit dem Symbol 160 wird ein Ereignis aus einem anderen Unterprozeß erfaßt, in welchem eine Datei gespeichert wurde. Diese Information stammt aus dem Texteditier-Unterprozeß 119. Beim Symbol 162 führt das System eine Überprüfung durch, um zu verifizieren, daß die gespeicherte Datei die gleiche Datei ist, wie jene auf welche in dem temporären Dateinamen 142 hingewiesen wird (dies ist Teil des Zustandsinformation des Prozesses). Das System prüft als nächstes ob die nächste Bedingung erfüllt wurde, d. h. ob alle Teilnehmer erfaßt wurden, was bei Symbol 164 geschieht. Wenn dies nicht wahr ist, wird die Aktivität der Fig. 12 ausgelöst bzw. getriggert, um die Beteiligten zu holen. Hier wird der zielgerichtete Aspekt des zugrunde liegenden Expertensystems verwendet, d. h. wenn eine Bedingung nicht erfüllt ist und eine Aktivität existiert, deren Wirkungen die Bedingung erfüllen werden, wird diese Aktivität ausgeführt. Beim Symbol 166 stellt das System sicher, ob Bekanntmachungen vorher an die Teilnehmer geschickt wurden (dies wird als Zustandsinformation auf dem ?Datei-Objekt aufgezeichnet). Dies veranschaulicht den nicht-sequentiellen Charakter des gesamten Unterstützungssystems 8. Mit jedem der Prozesse und Unterprozesse, die auf parallele Weise und gleichzeitig geschehen, muß das System Überprüfungen durchführen, um für sich sicherzustellen, daß Arbeit nicht wiederholt wird, und dadurch fehlerhafte Ergebnisse, verminderte Leistungsfähigkeit und langsamere Verarbeitungsfähigkeiten des Systems resultieren. Somit, da nur eine Bekanntmachung des Treffens erforderlich ist, führt das Symbol 166 die Überprüfung durch. Durch Erfüllung der letzten Bedingung, stellt das Menü 170 dem Benutzer die Auswahl bereit, die "Schicke Bekanntmachung"- Aktivität 171 zu wählen. Beim Symbol 172 schickt der Assistent der vorliegenden Erfindung die Bekanntmachung und druckt sie. Das Symbol 172 symbolisiert einen Vorgang, welcher die Bekanntmachung zur Übertragung an alle notwendigen Parteien lädt, versendet und druckt (was erzielt werden könnte durch Verwendung der UNIX-Mail und von Druckdiensten, welche erneut in den Codeansicht des Icons beschrieben werden). Das Symbol 174 zeichnet die Zustandsinformation, daß die Bekanntmachung geschickt wurde, in dem ?Datei-Objekt auf, und dadurch kann diese Aktivität nicht wiederholt werden.
Unter Bezugnahme nun auf Fig. 14 werden die Elemente des Bekanntmachungs-Unterprozesses in diagrammartiger Form weiter ausgeführt. Das Symbol 180 zeigt an, daß die Bedingung, daß eine "Hartkopie" der Bekanntmachung bereits geschaffen worden sein muß; in anderen Worten, die Bekanntmachung wurde gedruckt (dies geschieht in der obigen Aktivität 171). Das Menü 182 sagt dem Benutzer 16, daß die Bekanntmachung auf dem Bekanntmachungsaushang an dem gewünschten Ort plaziert werden sollte. Die Aktivität 184 stellt in diesem Fall eine Aktivität dar, bei welcher das Unterstützungssystem 8 nicht durch Lieferung von Werkzeugen helfen kann; statt dessen muß der Benutzer 16 die Bekanntmachung selbst physisch plazieren. Daher zeigt das Icon 186, daß nur eine innere Zustandsveränderung bei dieser Aktivität stattfindet, und keine externes Werkzeug beteiligt ist. Schließlich, unter Bezugnahme auf Fig. 15, wird die Aktivität 184, welche die Vollendung des Bekanntmachungs- Unterprozesses umfaßt, dort veranschaulicht. Die Bedingungen 190 und 192 sind wahr, wenn die Bekanntmachung geschickt und ausgehängt wurde. Das Symbol 196 stoppt den Prozeß, und das Symbol 198 zeichnet diese Zustandsveränderung auf. Es betätigt auch ein Ereignis für Prozesse, welche an dieser Tatsache interessiert sind, aufgrund des Auslösemechanismus des Expertensystems. Unter erneuter Bezugnahme auf die Fig. 9 erkennt man, daß der Bekanntmachungs-Unterprozeß 116 zum Treffen 118 führt, wenn dem fertigen Pfeil 114 gefolgt wird. Somit würde beim Auftreten des Ereignisses 198, das Treffen 118 instantiiert, und die notwendigen Schritte und Aufgaben zur Vollendung des Treffens würden dann stattfinden.
Eine Symbolidentifikations-Beschreibung ist als Anhang A angehängt. Die Beschreibung definiert die grafischen Symbole, welche von dem Unterstützungssystem 8 verwendet werden, wie in den Fig. 8-15 veranschaulicht. Ebenfalls angehängt sind Anhänge B und C, welche ausführliche Programmausdrucke sind, zur Durchführung der Datenverarbeitungsschritte für einen anderen Prototypen, welcher gemäß der Lehren entwickelt wurden, welche in dieser Anmeldung beschrieben wurden. Insbesondere sind die Anhänge B und C Programmausdrücke, welche die Art und Weise veranschaulichen, in welcher Code in der ProKappa-Sprache durch die PDL-Grafiksprache erzeugt wird, zur Ausführung innerhalb eines Expertensystems 20 der Art, wie es in der vorliegenden Erfindung vollendet wurde. Während die Beispielsprozesse, welche durch die Programmausdrücke der Anhänge B und C definiert sind, vollkommen verschieden sind von dem Beispiel des in Fig. 8-15 gezeigten Sekretärsprozesses, sind die Ausdrücke lehrreich zur Veranschaulichung wie die PDL- Definition eines Prozesses auf ausführbaren Kode reduziert wird.
In den Fig. 8-15 wurde eine Anzahl verschiedener Aktivitäten gezeigt. Diese sind intern nicht-sequentiell, da die Bedingungen für jede von ihnen auf Validität bzw. Gültigkeit getestet sind, egal welche anderen Aktivitäten ausgeführt wurden. Auf diese Weise kann ein Maximum an Flexibilität für den Endbenutzer geschaffen werden. Durch die oben beschriebenen Mechanismen kann die Unterstützung für verschiedene Aufgaben erzeugt und modifiziert werden, ohne daß die verschiedenen Werkzeuge, welche verwendet werden, verändert werden müssen. Die formale Beschreibung dient als Kontrollprogramm über einer Anzahl von Komponenten, welches die Logik beschreibt, welche erforderlich ist, damit einzelne Werkzeuge auf integrierte Weise arbeiten.
Somit wurde hier ein Verfahren und eine Vorrichtung für die Systementwicklungs-Unterstützung beschrieben und veranschaulicht. Der Fachmann wird jedoch erkennen, daß viele Modifikationen und Variationen neben den bereits erwähnten in der hier beschriebenen Technik gemacht werden können, ohne sich wesentlich vom Konzept der vorliegenden Erfindung zu entfernen. Dementsprechend sollte klar verstanden werden, daß die Form der hier beschriebenen Erfindung nur ein Beispiel ist, und nicht als Beschränkung des Umfangs der Erfindung gedacht ist.

ANHANG A

1. Symbolidentifikations-Beschreibung
1.1 Aktivitäten
Ein zentrales Konzept in PDL ist die Aktivität. Eine Aktivität wird als Würfel dargestellt.
Bedingungen sind mit der Aktivität verbunden, um zu beschreiben» wann sie durchgeführt werden kann. Wirkungen sind mit der Aktivität verbunden, um zu beschreiben was erzielt wird (wie sie sich auf den Rest der Welt auswirkt).
1.2 Bedingungen
Eine allgemeine Bedingung wird dargestellt durch ein Dreieck, dessen Spitze nach unten zeigt. Eine Bedingung wird mit einer Aktivität durch einen Flußpfeil verbunden.
Mehr als eine Bedingung können mit einer Aktivität verbunden sein. Wenn eine Bedingung gültig sein muß, bevor die nächste getestet werden kann, wird dies ausgedrückt als:
Die am weitesten von der Aktivität entfernte Bedingung wird als erste getestet.
Um etwas Spezifischeres als eine allgemeine Bedingung auszudrücken, existieren eine Anzahl von Icons für spezifische Bedingungen:
Eingabe (ein allgemeines Objekt) muß existieren.
Eingabe (ein Dokument oder eine Datei) muß existieren in einem bestimmten Status (beschrieben durch Parameter), zum Beispiel eine bestimmte
Überarbeitung. Dies ist eine Spezialisierung des vorangegangenen Symbols.
Beschreibt einen Zustand, beispielsweise ein Attribut in einem Objekt, muß einen bestimmten Wert haben (proc. state = = validation oder obj.a1 > obj.a2).
Beschreibt einen Zeitausdruck, zum Beispiel das irgend etwas zu einer bestimmten Zeit geschehen soll (now.date > = 1999-10-15).
Beschreibt eine Aktivität, welche dem Benutzer in der Benutzerschnittstelle präsentiert werden sollte. Die entsprechende Aktivität wird ausgeführt, wenn der Benutzer die Aktivität in der Benutzerschnittstelle wählt. Diese Bedingung sollte als letzte in einer Kette von Bedingungen plaziert sein, um so sicherzustellen, daß der Rest der Bedingungen wirklich wahr ist, wenn die Aktivität ausgeführt wird.
Beschreibt eine Bedingung auf einem eingehenden Signal (Parameter können daran angehängt sein).
1.3 Wirkungen
Eine allgemeine Wirkung wird durch ein Dreieck mit der Basis nach unten dargestellt.
Eine Aktivität wird mit einer, Wirkung durch einen Flußpfeil verbunden.
Eine Aktivität kann mit vielen Wirkungen verbunden sein. Wenn eine Wirkung vor der anderen ausgeführt werden muß, wird dies ausgedrückt als:
Die der Aktivität am nächsten liegenden Wirkungen werden als erste ausgeführt. Auch können komplexere Wirkungen beschrieben werden:
Die Figur impliziert die folgenden Effekte:¹ (a oder (b und (d und e))) und c
Um etwas Spezifischeres als eine allgemeine Wirkung auszudrücken existieren eine Anzahl von spezifischen Wirkungssymbolen:
Ein allgemeines Objekt wird als Ausgabe erzeugt.
Ein Dokument oder eine Datei werden geschaffen als Ausgabe, oder empfangen einen neuen Status (zum Beispiel eine neue Überarbeitung). Dies ist eine Spezialisierung des vorangegangenen Symbols.
Beschreibt eine Zustandsveränderung (zum Beispiel proc. state = validation).
Beschriebt einen Zeitausdruck (zum Beispiel warten für eine bestimmte Zeit oder eine Auszeit auf einem gesendeten Asynchronsignal).
Beschreibt ein herausgehendes Signal. Das Signal kann entweder breit gestreut (broadcasted) sein oder an einen spezifischen Empfänger gerichtet sein.
Beschreibt die Erzeugung eines Schattenobjekts (könnte einen Prozeß oder ein Objekt darstellen, welches ein reales Objekt beschreibt, wie eine Datei).
Beschreibt die Entfernung eines Objekts (zu verwenden wenn ein Prozeß beendet wird).

2. Syntax

1 < Prozeßdiagramm> :: = < Prozeßfläche>
2 < generisches Bedingungssymbol> :: =
3 < spezifisches Bedingungssymbol> :: =
4 < generisches Wirkungssymbol> :: =
5 < spezifisches Wirkungssymbol> :: =
6 < Und-Zuordnungssymbol>
7 < Oder-Zuordnungssymbol>
8 < Nicht-Zuordnungssymbol>
9 < Steuer-Zuordnungssymbol>
10 < Erben-Zuordnungssymbol>
1 PDL hat eine Aussageform und Semantik, welche an Prolog erinnert, was bedeutet, daß jede Aussage (Wirkung) entweder Erfolg hat oder versagt. Dies kann auf die Flußbeziehungen der Wirkungen abgebildet werden. "Oder" wird in diesem Fall so interpretiert, daß alle Zweige getestet werden, bis einer Erfolg hat. Anhang B Anhang C

Claims

1. Verfahren zur Entwicklung eines Computerprogramms, wobei in einem interaktiven System eine Beschreibung eines Programmentwicklungsprozesses (350) bereitgestellt wird, welcher eine Vielzahl von Schritten enthält, die ausgeführt werden müssen bei der Entwicklung des Computerprogramms, wobei der Programmentwicklungsprozeß eine Vielzahl von Zuständen hat, für jeden von welchen die Beschreibung eine jeweilige Aktion spezifiziert, welche die Entwicklung des Computerprogramms voranbringt und ansprechend auf das Auftreten des jeweiligen Zustandes unternommen werden kann, wobei die Zustände keiner Sequenz unterworfen sind, und wobei das Verfahren ferner die Ausführung der Beschreibung des Programmentwicklungsprozesses (44) umfaßt, einschließlich der Erzeugung von Ereignissen, die das Ergreifen einer Aktion zum Voranbringen der Entwicklung des Computerprogramms (65) anzeigen, und der Aktualisierung des Programmentwicklungsprozesses auf einen aktualisierten Zustand, um ein erzeugtes Ereignis (67) zu berücksichtigen,

wobei der Bereitstellungsschritt das Beschreiben des Programmentwicklungsprozesses in einer grafischen Sprache enthält, wodurch die Beschreibung in eine grafisch veranschaulichende Form gebracht wird; und

der Ausführungsschritt das Vorschlagen beinhaltet, daß die für den von der Beschreibung für den aktualisierten Zustand spezifizierte Aktion, bei der Entwicklung des Computerprogramms (67) unternommen werde, während es einem Benutzer des interaktiven Systems immer noch gestattet ist, eine Aktion auszuwählen, welche die Entwicklung des Computerprogramms voranbringt, welche nicht von der Beschreibung (66) für den aktualisierten Zustand spezifiziert ist.

2. Verfahren nach Anspruch 1, welches einschließt, daß der Benutzer die vorgeschlagene Aktion (68) unternimmt.

3. Verfahren nach Anspruch 1, welches einschließt, daß der Benutzer eine Aktion unternimmt, welche von der Beschreibung (66) nicht für den aktualisierten Zustand spezifiziert ist.

4. Verfahren nach Anspruch 1, wobei die Beschreibung des Programmentwicklungsprozesses eine Vielzahl von Aktionen spezifiziert, welche die Entwicklung des Computerprogrammes voranbringen, und welche ansprechend auf das Auftreten des aktualisierten Zustandes unternommen werden können.

5. Verfahren nach Anspruch 4, wobei der Vorschlagschritt umfaßt, daß vorgeschlagen wird, daß irgend eine der Vielzahl von Aktionen, welche von der Beschreibung für den aktualisierten Zustand spezifiziert werden, unternommen werde, während dem Benutzer immer noch gestattet wird, eine andere Aktion als die von der Beschreibung für den aktualisierten Zustand spezifizierten Aktionen auszuwählen.

6. Verfahren nach einem der Ansprüche 1 bis 5, wobei eine der Aktionen das Aufrufen einer allgemeinen Programmentwicklungs-Werkzeugfunktion (69) umfaßt.

7. Verfahren nach Anspruch 1, wobei die Beschreibung des Programmentwicklungsprozesses für einen der Zustände, welcher verschieden ist von dem aktualisierten Zustand, eine Vielzahl von Aktionen spezifiziert, welche die Entwicklung des Computerprogramms voranbringen und ansprechend auf das Auftreten des einen Zustandes unternommen werden können.

8. Vorrichtung zur interaktiven Entwicklung eines Computerprogramms, welche ein interaktives System (8) enthält, das einen Assistenten (12) und eine Vielzahl von allgemeinen Programmentwicklungswerkzeugen (22) enthält, wobei der Assistent Mittel enthält zur Ausführung einer Beschreibung eines Programmentwicklungsprozesses (44), wobei der Programmentwicklungsprozeß eine Vielzahl von Schritten enthält, welche erforderlich sind, um das Computerprogramm zu entwickeln, und welche durch die Beschreibung ausgedrückt werden, wobei der Programmentwicklungsprozeß auch eine Vielzahl von Zuständen hat, für jeden von welchen die Beschreibung eine jeweilige Aktion spezifiziert, welche die Entwicklung des Computerprogramms voranbringt und unternommen werden kann, ansprechend auf das Auftreten des jeweiligen Zustandes, wobei die Zustände keiner Sequenz unterworfen sind, und wobei der Assistent weiterhin Mittel enthält zur Erkennung eines Ereignisses, welches das Unternehmen einer Aktion durch eines der Programmentwicklungwerkzeuge (65) anzeigt, und Mittel zur Aktualisierung des Programmentwicklungsprozesses auf einen aktualisierten Zustand, um das erkannte Ereignis (67) zu berücksichtigen,

wobei die Beschreibung den Programmentwicklungsprozeß in einer grafischen Sprache beschreibt, wodurch die Beschreibung in eine grafisch veranschaulichende Form gebracht wird; und

der Assistent Mittel enthält, welche ansprechen auf das Auftreten des aktualisierten Zustandes, um vorzuschlagen, daß die von der Beschreibung für den aktualisierten Zustand spezifizierte Aktion bei der Entwicklung des Computerprogramms (76) unternommen werde, während einem Benutzer der Vorrichtung immer noch gestattet wird eine Aktion auszuwählen, welche die Entwicklung des Computerprogramms voranbringt, die nicht von Beschreibung für den aktualisierten Zustand spezifiziert ist.

9. Vorrichtung nach Anspruch 8, wobei die Beschreibung des Programmentwicklungsprozesses für den aktualisierten Zustand eine Vielzahl von Aktionen spezifiziert, welche die Entwicklung des Computerprogramms voranbringen und ansprechend auf das Auftreten des aktualisierten Zustandes unternommen werden können, und wobei die Mittel zum Vorschlagen vorschlagen, daß irgend eine der Vielzahl der Aktionen, welche von der Beschreibung für den aktualisierten Zustand spezifiziert werden, unternommen werde, während es dem Benutzer immer noch gestattet wird, eine andere Aktion zu unternehmen, als die von der Beschreibung (66) für den aktualisierten Zustand spezifizierten Aktionen.

10. Vorrichtung nach Anspruch 8, wobei die Beschreibung des Programmentwicklungsprozesses für einen der Zustände, welcher verschieden von dem aktualisierten Zustand ist, eine Vielzahl von Aktionen spezifiziert, welche die Entwicklung des Computerprogramms voranbringen und ansprechend auf das Auftreten des einen Zustandes unternommen werden können.

11. Vorrichtung nach Anspruch 8, wobei der Assistent ein Modul enthält, in welchem die Beschreibung des Programmentwicklungsprozesses (42) gespeichert ist, wobei das Modul mit dem Ausführungsmittel gekoppelt ist.

12. Vorrichtung nach Anspruch 8, wobei das interaktive System einen Botschafts-Abwickler (46) enthält, welcher die Vielzahl von Werkzeugen mit dem Assistenten verbindet, wobei der Botschafts-Abwickler dazu dient, gewünschte Aktionen aus dem Assistenten der Vielzahl von Werkzeugen mitzuteilen, und Ereignisse, welche aus den Werkzeugen stammen, dem Erkennungsmittel mitzuteilen.