DE102005046996A1

DE102005046996A1 - Anwendungs-generischer Sequenzdiagrammerzeuger, getrieben durch eine nicht-proprietäre Sprache

Info

Publication number: DE102005046996A1
Application number: DE102005046996A
Authority: DE
Inventors: Kenneth M. Green
Original assignee: Agilent Technologies Inc
Current assignee: Agilent Technologies Inc
Priority date: 2005-01-19
Filing date: 2005-09-30
Publication date: 2006-07-27
Also published as: GB2423387A; US20060161890A1; US7849439B2; GB0601020D0; CN1808377A; JP2006202277A

Abstract

Ein anwendungsgenerischer Sequenzdiagrammerzeuger wird durch eine nicht-proprietäre Sprache getrieben. Gemäß einem Ausführungsbeispiel beschreibt eine Quelldatei in einer nicht-proprietären Sprache einen Fluss (z. B. einen Meldungsaustausch) einer Anwendung. Ein automatischer Sequenzdiagrammerzeuger ist wirksam, um als Eingabe die Quelldatei zu empfangen und, basierend auf einer solchen Quelldatei, ein Sequenzdiagramm zu erzeugen, das den Fluss darstellt, der durch die Quelldatei beschrieben wird. Bei einem exemplarischen Ausführungsbeispiel ist die nicht-proprietäre Sprache eine Markierungssprache, wie z. B. die erweiterbare Markierungssprache (XML). Der Sequenzdiagrammerzeuger ist eine Allzweck-Einrichtung (oder "anwendungsgenerisch"), da er ein Sequenzdiagramm erzeugen kann, das den Fluss jeglicher Anwendung darstellen kann, die in der Quelldatei beschrieben wird. Die Anwendung, für die die Quelldatei den Fluss beschreibt, kann jeglicher Typ einer Anwendung sein, einschließlich, ohne Einschränkung, eine computerausführbare Software-Anwendung, ein Kommunikationsprotokoll oder jeglicher Meldungsaustausch zwischen Aktoren.

Description

Sequenzdiagramme (auch bekannt als Sequenz-Tabellen, Zeitsequenzdiagramme/Tabellen, Meldungssequenzdiagramme/Tabellen, Strecken-Diagramme/Tabellen oder Leiter-Diagramme/Tabellen) werden üblicherweise verwendet, um eine graphische Darstellung eines Flusses einer Anwendung zu liefern. Genauer gesagt schaffen Sequenzdiagramme üblicherweise eine graphische Darstellung einer Reihe von Transaktionen, die als „Meldungen" bezeichnet werden, zwischen zwei oder mehr Entitäten, die als „Aktoren" bezeichnet werden. Bei Sequenzdiagrammen wird Zeit üblicherweise dargestellt durch den vertikalen Verlauf abwärts auf der Seite. Jeder Aktor ist in Sequenzdiagrammen typischerweise durch eine vertikale Zeile (oder Spalte) dargestellt. Meldungen sind typischerweise durch horizontale Zeilen dargestellt, die üblicherweise etikettiert sind und üblicherweise in einem Pfeilkopf enden, der die Richtung der Kommunikation anzeigt, zwischen den vertikalen Zeilen der Aktoren, die an dem Austausch beteiligt sind. Andere Dekorationen sind manchmal in einem Sequenzdiagramm umfasst, wie z. B. Transaktionsartikelnummern oder andere Beziehungen zwischen den Transaktionen, wie z. B. Zeitüberschreitungen.

Der Fluss von vielen Arten von Anwendungen kann durch Sequenzdiagramme dargestellt werden, was ohne Einschränkung solche Anwendungen umfasst wie Kommunikationsprotokolle, computerausführbare Software, Fertigungslinien oder andere Herstellungsprozesse. Tatsächlich können Sequenzdiagramme verwendet werden, um den Fluss von Meldungsaustauschvorgängen zwischen Aktoren für jegliche Anwendung darzustellen, wie z. B. den Fluss von Meldungen, die zwischen einem Obstverkäufer und einem Kunden ausgetauscht werden, der Obst von dem Verkäufer kaufen möchte. Sequenzdiagramme können verwendet werden, um klar den Meldungsaustausch (oder „Fluss") einer Anwendung darzustellen, anstelle von oder zusätzlich zu einer textmäßigen Beschreibung eines solchen Meldungsaustauschs. Zum Beispiel können in vielen Fällen solche Anwendungen wie Kommunikationsprotokolle viel schneller verstanden werden durch Betrachten eines Sequenzdiagramms, als durch Betrachten einer textmäßigen Beschreibung der Anwendung. Wie bei dem Sprichwort, dass ein Bild tausend Worte wert ist, helfen Sequenzdiagramme bedeutend beim Übermitteln des Meldungsaustauschs einer gegebenen Anwendung.

Dementsprechend werden Sequenzdiagramme üblicherweise in Spezifikationen, Entwürfen und anderen Unterlagen verwendet, um Implementierungen zu dokumentieren, und als Darstellungen von vorausgesagtem oder gemessenem Systemverhalten. Auf dem Gebiet der Telekommunikation werden Sequenzdiagramme z. B. verbreitet verwendet, um die erforderlichen, erwarteten oder tatsächlichen Protokollmeldungsaustausch-Vorgänge zu dokumentieren.

Während Sequenzdiagramme von großem Vorteil sind, ist es häufig belastend, dieselben zu erzeugen und beizubehalten. Üblicherweise wurden Sequenzdiagramme manuell erzeugt unter Verwendung von grundlegenden Bitmap-Editoren (z. B. Microsoft Paint), höherentwickelten Diagrammerzeugungswerkzeugen (z. B. Microsoft Visio) oder manchmal zweckgebundenen CASE-Tools (z. B. Rational Rose). Das Erzeugen von Sequenzdiagrammen auf diese Weise erfordert, dass sowohl der ursprüngliche Autor als auch der Unterstützer Zugriff auf entsprechend lizenzierte Versionen der kompatiblen Tools bzw. Werkzeuge hat. Ferner ist es erforderlich, dass der Sequenzdiagrammerzeuger Entscheidungen über Entwurf und Layout trifft, obwohl einige Tools Unterstützung in diesen Bereichen liefern. Dieser manuelle Ansatz verbraucht viel Zeit und Arbeit und entmutigt die Integration von Sequenz diagrammen in Unterlagen aufgrund der hohen Kosten zum Erzeugen und Beibehalten derselben.

Kürzlich wurden automatische Diagrammerzeugungs-Tools entwickelt, die Sequenzdiagramme aus einer Eingabe-Textdatei erzeugen können, die die Transaktionssequenzen einer Anwendung beschreibt. Somit verringern solche automatischen Diagrammerzeugungstools den Bedarf eines Benutzers, manuell Sequenzdiagramme zu erzeugen. Automatische Diagrammerzeugungs-Tools, die auf dem Stand der Technik erhältlich sind, umfassen folgende: EventStudio 2.5, erhältlich von EventHelix.com (siehe http://www.eventhelix.com/EventStudio/), Callflow Sequence Diagram Erzeuger, erhältlich von SourceForge.net (siehe http://sourceforge.net/projects/callflow), das Sequence Diagram Tool in WebSphere Studio Application Developer, erhältlich von International Business Machines (IBM) und J2u, erhältlich von NASRA (siehe http://www.nasra.fr/).

Bekannte automatische Diagrammerzeugungs-Tools erfordern üblicherweise die Verwendung einer proprietären Sprache zum Definieren einer textmäßigen Beschreibung in einer Quelldatei. Somit kann erforderlich sein, dass ein Benutzer eine proprietäre Sprache lernt, um die entsprechende textmäßige Beschreibung zu erzeugen, die durch das automatische Diagrammerzeugungs-Tool verwendet werden soll.

Ferner sind einige automatische Diagrammerzeugungs-Tools nicht anwendungs-generisch. Statt dessen sind bestimmte automatische Diagrammerzeugungs-Tools für die Verwendung beim Erzeugen von Sequenzdiagrammen ausschließlich für spezifische Typen von Anwendungen beschränkt und ihnen fehlt somit die Flexibilität, ein Sequenzdiagramm für jeglichen gewünschten Typ einer Anwendung zu erzeugen. Zum Beispiel ist das Sequence Diagram Tool (Sequenzdiagramm-Tool), vorgesehen in dem WebSphere Studio Application Developer (Websphere-Studio-Anwendungsentwickler), in der Lage, einen Java-Quellcode als eine Quelldatei zu empfangen und ist wirksam, ein Sequenzdiagramm zu erzeugen, das den Fluss des empfangenen Java-Quellcodes darstellt. Somit, während dieses Tool nicht erfordert, dass ein Benutzer eine proprietäre Sprache lernt, um eine Quelldatei zu erzeugen (sondern statt dessen der Java-Quellcode als die Quelldatei eingegeben werden kann), ist es insofern Anwendungsspezifisch, als es nur in der Lage ist, Sequenzdiagramme für den eingegebenen Java-Quellcode zu erzeugen. Somit ist dieses Tool z. B. nicht in der Lage, eine textmäßige Quelldatei zu empfangen, die z. B. den Meldungsaustausch zwischen einem Kunden und einem Obstverkäufer beschreibt, und ein Sequenzdiagramm für diese Anwendung zu erzeugen, sondern ist statt dessen auf das Erzeugen eines Sequenzdiagramms beschränkt, das den Fluss des Java-Quellcodes darstellt, der in dasselbe eingegeben wird. Somit sind bestimmte Sequenzdiagramm-Erzeugungstools keine Allzweck-Sequenzdiagrammerzeuger, sondern sind spezialisiert auf spezifische Anwendungen oder spezifische Aufgaben, wie z. B. eine Rückwärts-Konstruktion von bestehendem Quellcode oder das automatische Dokumentieren eines Software-Laufzeitverhaltens aus den Laufzeit-Spuren.

Zusätzlich dazu ermöglichen automatische Sequenzdiagramm-Erzeugungstools gemäß dem Stand der Technik allgemein keine Befehlszeilen-Operation und können somit nicht in einen Dokumentveröffentlichungs-Automatisierungsprozess eines Endbenutzers integriert werden. Somit besteht allgemein keine effiziente Möglichkeit für einen Benutzer, eine Gruppe von Diagrammen unter Verwendung von bekannten automatischen Sequenzdiagrammerzeugern zu erzeugen. Statt dessen ist es allgemein erforderlich, dass ein Benutzer vor dem Computer sitzt und Informationen eingibt (z. B. eine Quelldatei), um ein Diagramm nach dem anderen zu erzeugen.

Es ist die Aufgabe der vorliegenden Erfindung, ein System, ein Verfahren, einen computerausführbaren Code und einen anwendungs-generischen Sequenzdiagrammerzeuger mit verbesserten Charakteristika zu schaffen.

Diese Aufgabe wird durch ein System gemäß Anspruch 1, ein Verfahren gemäß Anspruch 13, einen computerausführbaren Code gemäß Anspruch 22 und einen anwendungs-generischen Sequenzdiagrammerzeuger gemäß Anspruch 30 gelöst.

Im Hinblick auf die obige Ausführung besteht ein Bedarf nach einem automatischen Sequenzdiagrammerzeuger, der in der Lage ist, eine Quelldatei zu empfangen, die einen Fluss (z. B. Meldungsaustausch) einer Anwendung in einer nicht-proprietären Sprache definiert. Ferner ist es wünschenswert, dass ein solcher automatischer Sequenzdiagrammerzeuger ein Allzweck- (oder „anwendungs-generischer") Diagrammerzeuger ist und nicht auf das Erzeugen von Sequenzdiagrammen für eine spezifische Anwendung beschränkt ist.

Die vorliegende Erfindung richtet sich auf ein System und ein Verfahren, die einen anwendungs-generischen Sequenzdiagrammerzeuger schaffen, der durch eine nicht-proprietäre Sprache getrieben wird. Gemäß einem Ausführungsbeispiel beschreibt eine Quelldatei in einer nicht-proprietären Sprache einen Fluss (z. B. einen Meldungsaustausch) einer Anwendung. Ein automatischer Sequenzdiagrammerzeuger ist wirksam, um als Eingabe die Quelldatei zu empfangen und basierend auf einer solchen Quelldatei ein Sequenzdiagramm zu erzeugen, das den Fluss darstellt, der durch die Quelldatei beschrieben wird.

Bei einem exemplarischen Ausführungsbeispiel ist die nicht-proprietäre Sprache eine Markierungssprache (markup language), wie z. B. die erweiterbare Markierungssprache (Extensible Markup Language (XML)). Somit ist nicht erforderlich, dass ein Benutzer eine proprietäre Sprache lernt, um eine Quelldatei zu erzeugen, die durch den Sequenzdiagrammerzeuger verwendet werden soll, sondern kann statt dessen den Fluss beschreiben, der in ein Diagramm integriert werden soll, z. B. XML. Ferner ist der Sequenzdiagrammerzeuger eine Allzweckeinrichtung (oder „anwendungs-generisch"), da er ein Sequenzdiagramm erzeugen kann, das den Fluss jeglicher Anwendung darstellt, die in der Quelldatei beschrieben ist. Die Anwendung, für die die Quelldatei den Fluss beschreibt, kann jeglicher Typ einer Anwendung sein, einschließlich ohne Einschränkung eine computerausführbare Softwareanwendung, ein Kommunikationsprotokoll oder ein Meldungsaustausch zwischen Aktoren (z. B. ein Meldungsaustausch zwischen einem Kunden und einem Obstverkäufer).

Gemäß einem Ausführungsbeispiel umfasst der Sequenzdiagrammerzeuger einen Quell-Parser, einen Diagramm-Parser und eine Aufbereitungsmaschine. Der Quell-Parser (bzw. Quell-Analysierer) empfängt die Text-Quelldatei und baut basierend auf der empfangenen Quelldatei ein Datenmodell für ein Diagramm des Flusses auf, der durch die Quelldatei beschrieben wird. Der Diagramm-Parser verarbeitet das Datenmodell, das durch den Quell-Parser aufgebaut wird, um entsprechende Zeichenbefehle zu erzeugen, die in die Aufbereitungsmaschine eingegeben werden. Ansprechend auf das Empfangen der Zeichenbefehle erzeugt die Aufbereitungsmaschine ein Sequenzdiagramm, das den Fluss darstellt, der durch die Text-Quelldatei beschrieben wird.

Bei verschiedenen hierin beschriebenen Ausführungsbeispielen ist die Text-Quelldatei unabhängig von der Anwendung, für die die Text-Quelldatei den Fluss definiert. Zum Beispiel beschreibt die Text-Quelldatei einen Fluss einer Anwendung (z. B. ein Kommunikationsprotokoll oder einen anderen Austausch von Meldungen zwischen Aktoren), für die ein Sequenzdiagramm erzeugt werden soll, wobei nicht die Quelldatei selbst die Anwendung ist, für die ein Sequenzdiagramm erzeugt werden soll. Als ein Beispiel kann die Text-Quelldatei eine XML-Datei sein, die den Fluss eines Java-Programms beschreibt. Somit ist die XML-Datei unabhängig von dem Java-Programm, im Gegensatz zu dem Quellcode des Java-Programms, der als Eingabe in dem Sequenzdiagrammerzeuger verwendet wird.

Das Vorangehende hat ziemlich umfassend die Merkmale und technischen Vorteile der vorliegenden Erfindung ausgeführt, so dass die detaillierte Beschreibung der Erfindung, die folgt, besser verständlich ist. Zusätzliche Merkmale und Vorteile der Erfindung werden hierin nachfolgend beschrieben, die den Gegenstand der Ansprüche der Erfindung bilden. Fachleute auf dem Gebiet sollten erkennen, dass das Konzept und das spezifische Ausführungsbeispiel, das offenbart ist, ohne weiteres als eine Basis zum Abändern oder Entwerfen anderer Strukturen verwendet werden können, zum Ausführen der selben Zwecke der vorliegenden Erfindung. Fachleute auf dem Gebiet sollten ebenfalls erkennen, dass solche äquivalenten Konstruktionen nicht von dem Wesen und dem Schutzbereich der Erfindung abweichen, wie sie in den beiliegenden Ansprüchen ausgeführt sind. Die neuen Merkmale, die als charakteristisch für die Erfindung betrachtet werden, sowohl im Hinblick auf Organisation als auch Operationsverfahren, zusammen mit weiteren Zielen und Vorteilen, sind aus der nachfolgenden Beschreibung besser verständlich, wenn sie in Verbindung mit den beiliegenden Figuren betrachtet wird. Es wird jedoch ausdrücklich darauf hingewiesen, dass jede der Figuren ausschließlich zum Zweck der Darstellung und Beschreibung vorgelegt wird und nicht als Definition der Grenzen der vorliegenden Erfindung gedacht ist.

Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf die beiliegenden Zeichnungen näher erläutert. Es zeigen:
1 ein exemplarisches System, das einen Sequenzdiagrammerzeuger gemäß einem Ausführungsbeispiel der vorliegenden Erfindung umfasst;
2 einen Sequenzdiagrammerzeuger gemäß bestimmten Ausführungsbeispielen der vorliegenden Erfindung;
3 detaillierter einen Sequenzdiagrammerzeuger gemäß einem exemplarischen Ausführungsbeispiel der vorliegenden Erfindung;
4 ein exemplarisches Sequenzdiagramm, das durch einen Sequenzdiagrammerzeuger gemäß einem Ausführungsbeispiel der vorliegenden Erfindung erzeugt werden kann;
5 ein Operations-Flussdiagramm eines Sequenzdiagrammerzeugers gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
6 ein exemplarisches System, bei dem ein Dokumenterzeuger und ein Sequenzdiagrammerzeuger als separate Komponenten implementiert sind, die parallel verwendet werden können, um ein Gesamtdokument (sowohl mit Text- als auch Sequenzdiagrammen) aus einer Quelldatei zu erzeugen; und
7 ein exemplarisches System, bei dem ein Sequenzdiagrammerzeuger in eine Dokumenterzeugeranwendung integriert ist.
Exemplarische Ausführungsbeispiele der vorliegenden Erfindung werden nun Bezug nehmend auf die obigen Figuren beschrieben, wobei gleiche Bezugszeichen gleiche Teile durchgehend in den verschiedenen Ansichten darstellen. Bezug nehmend auf 1 ist ein exemplarisches System 100 gezeigt, das einen Sequenzdiagrammerzeuger 102 umfasst, der wirksam ist, um als Eingabe eine Text-Quelldatei 101 zu empfangen und aus derselben ein Sequenzdiagramm 103 zu erzeugen. Das Sequenzdiagramm 103 kann in eine Datei und/oder Ausgabeeinrichtung (z. B. eine Anzeigevorrichtung) gespeichert werden. Gemäß verschiedenen hierin beschriebenen Ausführungsbeispielen beschreibt die Quelldatei 101 den Fluss (z. B. Meldungsaustausch) einer Anwendung, wie z. B. eines Kommunikationsprotokolls etc., in einer nicht- proprietären Sprache, wie z. B. XML. Der Sequenzdiagrammerzeuger 102 kann als ein Allzweck- oder anwendungs-generischer Sequenzdiagrammerzeuger bezeichnet werden, da er wirksam ist, um ein Sequenzdiagramm für jeglichen Typ einer Anwendung zu erzeugen, für den ein Fluss in der Quelldatei 101 beschrieben ist.
Zusätzlich dazu, wie hierin weiter beschrieben wird, ist die Text-Quelldatei 101 unabhängig von der Anwendung, für die sie einen Fluss definiert. Zum Beispiel beschreibt die Text-Quelldatei einen Fluss einer Anwendung (z. B. ein Kommunikationsprotokoll oder einen anderen Austausch von Meldungen zwischen Aktoren), für den ein Sequenzdiagramm erzeugt werden soll, wobei nicht die Quelldatei selbst die Anwendung ist, für die ein Sequenzdiagramm erzeugt werden soll. Als Beispiel kann die Text-Quelldatei 101 eine XML-Datei sein, die den Fluss eines Java-Programms beschreibt. Somit ist die XML-Datei unabhängig von dem Java-Programm, im Gegensatz zu dem Fall, in dem der Quellcode des Java-Programms als Eingabe in den Sequenzdiagrammerzeuger 102 verwendet wird. Dementsprechend ist der Sequenzdiagrammerzeuger 102 nicht auf das Erzeugen eines Sequenzdiagramms für den Fluss der Quelldatei eingeschränkt, die in denselben eingegeben wird, sondern ist statt dessen wirksam, um ein Sequenzdiagramm für den Fluss jeglicher Anwendung zu erzeugen, die durch die Quelldatei beschrieben wird, die in dieselbe eingegeben wird.
2 zeigt einen Diagrammerzeuger 102 gemäß bestimmten Ausführungsbeispielen der vorliegenden Erfindung. Wie gezeigt ist, umfasst der Diagrammerzeuger 102 eine Parser-Komponente 201 und eine Aufbereitungsmaschine 203. Die Parser-Komponente 201 ist wirksam, um, basierend auf der eingegebenen Text-Quelldatei 101, Zeichenbefehle 202 zu der Aufbereitungsmaschine 203 zu erzeugen, um zu verursachen, dass die Aufbereitungsmaschine 203 ein Sequenzdiagramm 103 erzeugt, das den Fluss darstellt, der in der Quelldatei 101 beschrieben ist.
Gemäß diesem exemplarischen Ausführungsbeispiel liefert die Quelldatei 101 in einer nicht-proprietären Sprache (z. B. XML) eine Sequenzdefinition für einen Fluss einer Anwendung. Die Quelldatei wird in den Sequenzdiagrammerzeuger 102 eingegeben, der die Daten der Quelldatei syntaktisch analysiert bzw. parst 101 und das Sequenzdiagramm 103 entweder auf einem Anzeigebildschirm oder in eine Datei in einem von mehreren Formaten aufbereitet (bmp, gif, jpg etc.). Der Parser 201 ist verantwortlich für das Lesen und Interpretieren der eingegebenen Daten (z. B. XML) der Quelldatei 101, um die Element-Definitionen zu extrahieren. Die Aufbereitungsmaschine 203 ist verantwortlich für das Aufbereiten der Zeichenelemente unter Verwendung ihrer internen Entwurfs- und Layout-Regeln. Die Aufbereitungsmaschinen-Anwendungsprogrammschnittstelle (API; API = application program interface) stellt eine Abstraktion dar, die geeignet zum Zeichnen von Sequenzdiagrammen ist, was unabhängig von jeglicher bereichs-spezifischen Anwendung der Diagramme ist. Der Parser 201 bildet zwischen einem bereichsspezifischen Codieren in der Quelldatei (z. B. der XML) und der Aufbereitungs-API ab. Dies ermöglicht eine schnelle Anpassung des Sequenzdiagrammerzeugers 102 an einen großen Bereich von Bereichen, ohne die Kernzeichenlogik ändern zu müssen, die Entwurf und Layout steuert.
Die Aufbereitungsmaschine 203 und ihre entsprechende API können jegliche sein, die bereits bekannt sind oder später entwickelt werden, um die Fähigkeit zum Empfangen von Zeichenbefehlen und Erzeugen eines Sequenzdiagramms gemäß solchen Zeichenbefehlen zu schaffen. Der Parser 201 (und insbesondere der Diagramm-Parser 303, der in dem exemplarischen Ausführungsbeispiel von 3 unten beschrieben ist), sollte die Aufbereitungsmaschinen-API derart kennen, dass er die entsprechenden Zeichenbefehle erzeugen kann, um zu verursachen, dass die Aufbereitungsmaschine die entsprechenden Aktionen beim Erzeugen des entsprechenden Sequenzdiagramms unternimmt. Bei bestimmten Ausführungsbeispielen kann die API einer Aufbereitungsmaschine entwickelt sein, um eine bestimmte Anwendbarkeit bei Zeichensequenzdiagrammen aufzuweisen (z. B. um in der Lage zu sein, Aktoren, Meldungssequenzen etc. zu empfangen und die entsprechenden Merkmale zu zeichnen, um die Meldungssequenzen zwischen den Aktoren darzustellen), aber dies ist keine Anforderung zum Implementieren der hierin beschriebenen Konzepte.
Der Sequenzdiagrammerzeuger 102 gemäß einem exemplarischen Ausführungsbeispiel ist detaillierter in 3 gezeigt. Bei diesem darstellenden Ausführungsbeispiel umfasst der Sequenzdiagrammerzeuger 102 einen Quell-Parser 301, einen Diagramm-Parser 303 und eine Aufbereitungsmaschine 203. Somit weist bei diesem darstellenden Ausführungsbeispiel die Parser-Komponente 201 aus 2 einen Quell-Parser 301 und einen Diagramm-Parser 303 auf. Der Quell-Parser 301 empfängt die Quelldatei 101 als Eingabe und baut ein internes Datenmodell 302 basierend auf einer solchen Quelldatei 101 auf. Genauer gesagt liest der Quell-Parser 301 den Text aus der Quelldatei 101, prüft dessen Syntax und baut ein internes Datenmodell 302 auf, das die gesamten Diagramm-Metadaten-Informationen darstellt, die aus der Quelldatei 101 gelesen werden. Das interne Datenmodell 302 bewahrt die Hierarchie und Beziehungen, die in der Quelldatei 101 ausgedrückt sind.
Bei einem exemplarischen Ausführungsbeispiel ist die Quelldatei in XML und der Quell-Parser 301 parst bzw. analysiert XML-Elemente, um die Daten aus der Quelldatei zu extrahieren, um ein Datenmodell 302 zu erzeugen. Genauer gesagt wird bei einer exemplarischen Implementierung die XML-Quelldatei 101 in ein DOM (Dokumentobjektmodell = Document Object Model) durch den Quell-Parser 301 geladen. Das DOM ist eine Baumstruktur, die alle Daten aus der XML erfasst, einschließlich ihrer Hierarchie. Das DOM wird durch den Quell-Parser 301 nach Diagramm-Metadaten durchsucht, die dann in einen Satz aus internen Datenstrukturen 302 extrahiert werden, die die Aktoren und alle Transaktionen und Dekorationen beschreiben. Die Transaktionsdaten werden weiter verarbeitet, um alle Quell- und Zielort-Informationen zu extrahieren. Diese Sammlung aus internen Daten 302 wird dann verwendet, um den Aufbereitungsprozess zu treiben. Diagramm-Metadaten werden erkannt durch den Quell-Parser 301 in der XML-Quelle durch den eindeutigen Satz von XML-Etiketten, wobei Beispiele derselben nachfolgend weiter beschrieben werden.
Der Diagramm-Parser 303 verarbeitet die Daten in dem internen Datenmodell 302, um die Merkmale zu extrahieren, die in dem Sequenzdiagramm dargestellt werden sollen, und basierend auf einem solchen internen Datenmodell 302 erzeugt der Diagramm-Parser 303 eine Sequenz aus abstrakten Diagramm-Zeichenbefehlen zu der Aufbereitungsmaschine 203. Die Aufbereitungsmaschine 203 empfängt die Zeichenbefehle und transformiert solche Befehle in graphische Betriebssystem-Operationen auf niedriger Ebene (wie z. B. das Zeichnen von Linien, Kreisen oder Text), um ein Sequenzdiagramm 103 zu erzeugen, das z. B. auf einer Anzeige 305 einer prozessorbasierten Vorrichtung (z. B. eines Personalcomputers) 304 ausgegeben und/oder in eine Datei gespeichert werden kann.
Um die Operation eines Ausführungsbeispiels darzustellen, wird ein einfacher Fall einer Konversation zwischen drei Aktoren A, B und C betrachtet, die in der Quelldatei 101 beschrieben ist, die dann durch einen Diagrammerzeuger 102 verwendet wird, um ein Sequenzdiagramm 103 zu erzeugen, das den Austausch von Meldungen zwischen den Aktoren in einer solchen Konversation darstellt. Somit wird in diesem Fall die Konversation zwischen den Aktoren als eine Anwendung betrachtet und der Fluss einer solchen Anwendung wird in der Quelldatei 101 beschrieben. Die Konversation wird wie folgt angenommen:

• A sagt „Hallo" zu B;
• B sagt „Hallo da" zu A und „Hi" zu C; und
• C sagt „Guten Tag" zu B und zu A.

Bei diesem exemplarischen Ausführungsbeispiel wird die Quelldatei 101 in XML ausgedrückt und die obige Konversation kann durch die nachfolgende XML-Quelldatei 101 dargestellt werden
Wie bekannt ist, ermöglicht XML, dass Elemente mit Etiketten definiert werden. XML ist eine „Markup- bzw. Markierungs"-Sprache, die Markierungs-Symbole enthalten kann, um den Inhalt einer Seite oder Datei zu beschreiben. XML beschreibt den Inhalt einer Datei im Hinblick darauf, welche Daten beschrieben werden. Zum Beispiel könnte das Wort „phonenum" (telefone number = Telefonnummer), platziert innerhalb von Markierungsetiketten, anzeigt, dass die Daten, die folgen, eine Telefonnummer sind. Somit ermöglicht XML, dass Elemente, wie z. B. das Element „phonenum" (Telefonnummer) bei diesem Beispiel definiert werden. Dies bedeutet, dass eine XML-Datei rein als Daten durch ein Programm verarbeitet werden kann, oder dass dieselbe mit ähnlichen Daten auf einem anderen Computer gespeichert werden kann, oder, wie eine HTML-Datei, dass dieselbe angezeigt werden kann. Zum Beispiel, abhängig davon, wie die Anwendung bei dem empfangenen Computer die Telefonnummer handhaben wollte, könnte sie gespeichert, angezeigt oder gewählt werden. XML ist „erweiterbar", da, im Gegensatz zu HTML, die Markierungssymbole nicht eingeschränkt und selbstdefinierend sind. Bei dem obigen exemplarischen XML-Code werden die Elemente SequenceDefinition, MessageSequence und Message definiert. Das Element SequenceDefinition in diesem Fall ist das äußerste Etikett, das eine vollständige Definition eines einzelnen Diagramms umschließt. Das Element SequenceDefinition umfasst ein Attribut „title", das verwendet werden kann, um einen Titel für das Diagramm zu liefern. Das Element MessageSequence umschließt den Satz aus Transaktionen zwischen Aktoren, und jedes Meldungselement definiert eine einzelne Transaktion zwischen den Aktoren „from" und „to" unter Verwendung der Anmerkung, die durch das Attribut „msg" gegeben wird. Ein Programm, das eine XML-Datei syntaktisch analysiert (z. B. Quell-Parser 301), kann bestimmen, dass die Datei eine Sequenzdefinition umfasst, durch Suchen nach dem Element SequenceDefinition. Der Parser kann dann annehmen, dass sich der gesamte Inhalt, der sich zwischen der Öffnungs- und Schließ-SequenceDefinition-Etikette befindet, auf die Definition bezieht und sollte der erwarteten Syntax einer solchen Definition entsprechen, was in diesem Fall zumindest ein Etikettensatz MessageSequence ist, der eine oder mehrere Meldungsetiketten enthält.
Der Quell-Parser 301 empfängt die obige XML der Quelldatei 101 und parst dieselbe in das interne Datenmodell 302. Das interne Datenmodell 302, hergeleitet aus dem obigen exemplarischen XML-Code, könnte folgendermaßen aussehen:
Der Quell-Parser 301 hat eine genaue Kenntnis des Quelldatei-Formats und der -Syntax, um in der Lage zu sein, die Informationen zu extrahieren, die zum Aufbauen eines Diagramms benötigt werden. Diese Kenntnis ist spezifisch für jeden bestimmten Quelldateityp und könnte sich in der Tat im Lauf der Zeit ändern oder für unterschiedliche Ausführungsbeispiele der Erfindung unterschiedlich sein. Ein Trennen des Quell-Parsers 301 von dem Diagramm-Parser 303 über das interne Datenmodell 302 auf diese Weise ermöglicht eine Implementierung, die sich schnell an unterschiedliche Quelldateiformate anpassen kann, ohne Änderungen an dem grundlegenden Diagrammerzeugungsprozess zu erfordern. Somit könnte eine einzelne Implementierung eine Anzahl von unterschiedlichen XML-Syntaxen unterstützen, oder tatsächlich völlig andere Dateiformate, vielleicht strukturierten Text ähnlich zu einer Windows".ini"-Datei, oder jegliches andere beliebige Eingabeformat. Eine solche Implementierung müsste eine Quell-Parser-301-Implementierung für jedes unterstützte Format aufweisen, aber nur eine einzelne Implementierung von jedem des internen Datenmodells 302, des Diagramm-Parsers 303 und der Aufbereitungsmaschine 203.
Zusätzlich dazu können bei bestimmten Ausführungsbeispielen einige der Informationen, die zum Erzeugen des Sequenzdiagramms 103 benötigt werden, nicht explizit in der Quelldatei 101 vorgesehen sein, sondern werden statt dessen aus den verfügbaren Daten hergeleitet, sobald alles analysiert wurde. In einem solchen Fall ist es nicht zwingend notwendig, direkt Aufbereitungsmaschinenbefehle aus einem einzelnen Durchlauf durch die Quelldatei 101 zu erzeugen, sondern statt dessen müssen Daten gespeichert werden, bis ein vollständiger Satz erzeugt werden kann. Bei dem Beispiel kann die vollständige Liste von Aktoren erst bestimmt werden, sobald alle Meldungselemente analysiert wurden. Die vollständige Liste von Aktoren muss jedoch bekannt sein, bevor das Diagramm erzeugt werden kann.
Sobald die obige XML der Quelldatei in ein internes Datenmodell 302 analysiert wurde, verarbeitet der Diagramm-Parser 303 ein solches internes Datenmodell 302 und erzeugt eine Sequenz aus Diagramm-Zeichenbefehlen. Für das obige Beispiel und eine exemplarische Aufbereitungsmaschinen-API, könnte der Satz aus Befehlen wie folgt sein:
Die Aufbereitungsmaschine 203 empfängt die obigen Zeichenbefehle und erzeugt das exemplarische Sequenzdiagramm 400 aus 4. Wie in 4 gezeigt ist, umfasst das Sequenzdiagramm 400 einen Titel 401 „Ein einfaches Diagramm", wie in der obigen exemplarischen XML-Quelldatei 101 spezifiziert ist. Ferner umfasst das Sequenzdiagramm 400 Aktoren A (402), B (403) und C (404), wie durch die obige exemplarische XML-Quelldatei definiert wird. Das Sequenzdiagramm 400 stellt über den Pfeil 405 dar, dass der Aktor A „Hallo" zu Aktor B sagt. Das Sequenzdiagramm 400 stellt dar, über die Pfeile 406 und 407, dass der Aktor B „Hallo da" zu Aktor A und „Hi" zu Aktor C sagt. Abschließend stellt das Sequenzdiagramm 400 über die Pfeile 408 und 409 dar, dass der Aktor C „Guten Tag" zu den Aktoren A und B sagt.
Es sollte aus der darstellenden Konversation erkannt werden, die bei dem obigen Beispiel verwendet wird, dass der Fluss jeglicher Anwendung (z. B. Kommunikationsprotokolle etc.) in einer XML-Quelldatei beschrieben sein kann, die durch den Sequenzdiagrammerzeuger 102 verwendet wird, um ein Sequenzdiagramm zu erzeugen, das den Fluss einer solchen Anwendung darstellt.
Bezug nehmend auf 5 ist ein Operationsflussdiagramm eines Sequenzdiagrammerzeugers gemäß einem Ausführungsbei spiel gezeigt. Bei Operationsblock 501 empfängt ein Quell-Parser 301 eine Textquelldatei 101, die in einer nicht-proprietären Sprache ist (z. B. XML) und einen Fluss für eine Anwendung definiert (z. B. eine Konversation zwischen zwei oder mehr Aktoren, ein Kommunikationsprotokoll etc.). Bei Operationsblock 502 baut der Quell-Parser 301 basierend auf der Textquelldatei 101 ein Datenmodell 302 für ein Diagramm des Flusses auf, das durch die Textquelldatei 101 definiert wird. Bei Operationsblock 503 erzeugt der Diagramm-Parser 303, basierend auf dem Datenmodell 302, entsprechende Zeichenbefehle. Bei Operationsblock 504, ansprechend auf das Empfangen der Zeichenbefehle, bereitet eine Aufbereitungsmaschine 203 ein Sequenzdiagramm 103 auf, das den Fluss darstellt, der durch die Textquelldatei 101 definiert wird.
Wie oben erwähnt wurde, wird bei bestimmten Ausführungsbeispielen XML in der Quelldatei verwendet zum Beschreiben der Sequenz (oder des „Flusses") einer Anwendung. Exemplarische XML-Elemente, die bei einem Ausführungsbeispiel verwendet werden, werden nachfolgend weiter beschrieben.
Wie oben erwähnt wurde, wird gemäß einem Ausführungsbeispiel eine Sequenz in der XML unter Verwendung eines SequenceDefinition-Elements definiert. Die verschiedenen XML-Elemente, die bei einem Ausführungsbeispiel eine Sequenz-Beschreibung bilden sind in Tabelle 1 unten enthalten.
Tabelle 1
Es sollte darauf hingewiesen werden, dass zum Unterstützen einer Operation von Seriell/Einzel-Durchlauf-XML-Parsern das Element GroupDefinition vor ActorRoleMap und ActorRoleMap vor jeglichen Elementen Heading, Link oder Message erscheinen sollte. Die Reihenfolge der Elemente ActorRole innerhalb von ActorRoleMap definiert die Links-Nach-Rechts-Ordnung der Actors in dem Diagramm. Die Elemente Heading, Link und Message können 0 oder mehr Male erscheinen und in jeglicher Reihenfolge sein. Ihre Reihenfolge definiert ihre Oben-Nach-Unten-Platzierung abwärts entlang der vertikalen Zeitachse in dem Diagramm.
Die SequenceDefinition-Element-Attributdefinitionen gemäß einem Ausführungsbeispiel sind in Tabelle 2 unten enthalten.
Tabelle 2
Die ActorRole-Element-Attributdefinitionen gemäß einem Ausführungsbeispiel sind in Tabelle 3 unten enthalten.
Tabelle 3
Die Group-Element-Attributdefinitionen gemäß einem Ausführungsbeispiel sind in Tabelle 4 unten vorgesehen.
Tabelle 4
Die Actor-Element-Attributdefinitionen gemäß einem Ausführungsbeispiel sind in Tabelle 5 unten enthalten.
Tabelle 5
Die Heading-Element-Attributdefinitionen gemäß einem Ausführungsbeispiel sind in Tabelle 6 unten enthalten.
Tabelle 6
Die Message-Element-Felddefinitionen gemäß einem Ausführungsbeispiel sind in Tabelle 7 unten enthalten.
Tabelle 7
Die LinkElement-Felddefinitionen gemäß einem Ausführungsbeispiel sind in Tabelle 8 unten enthalten.
Tabelle 8
Im Hinblick auf das oben Ausgeführte ermöglichen Ausführungsbeispiele der vorliegenden Erfindung eine automatische Erzeugung von Hochqualitäts-Sequenzdiagrammen für einfache Textbeschreibungen. Eine solche automatische Erzeugung von Sequenzdiagrammen adressiert Problempunkte betreffend Einheitlichkeit des Entwurfs, standardisiertes Layout, leichte Beibehaltung und die Fähigkeit, beliebig große Datensätze zu handhaben oder Diagramme schnell zu regenerieren, wenn sich Daten ändern, die bei der manuellen Erzeugung/Beibehaltung von Sequenzdiagrammen problematisch sind.
Wie beschrieben wurde, werden Ausführungsbeispiele geschaffen, die textmäßige Beschreibungen unterstützen, die in einer nicht-proprietären Sprache geschrieben sind (z. B. XML). In der Vergangenheit waren proprietäre Sprachen definiert, um die Meldungsaustauschvorgänge zu beschreiben (z. B. EventStudio, http://www.eventhelix.com/EventStudio/). Ein Ausführungsbeispiel der vorliegenden Erfindung ermöglicht die Verwendung von XML, einer nicht-proprietären Sprache, um die Eingabedaten in die Diagrammerzeugungsmaschine auszudrücken. Zahlreiche freie und kommerzielle Tools sind verbreitet erhältlich zum Schreiben und Editieren von XML-Dateien. Die Syntax und Struktur von XML ist verbreitet bekannt und ohne weiteres erlernbar. Die Verwendung von XML, einer standardmäßigen und gut unterstützten Sprache, macht es schneller und einfacher für Endbenutzer, ihre Ziele zu erreichen, ohne neue oder proprietäre Sprachen lernen zu müssen. Eine exemplarische Definition eines XML-Formats zum Spezifizieren von Sequenz-Transaktionen ist oben vorgesehen. Ein XML-Schema kann somit entwickelt werden, das explizit die Syntax der Transaktionsdateien definiert. Natürlich ist der Schutzbereich der vorliegenden Erfindung nicht auf die bestimmte hierin beschriebene Syntax beschränkt, sondern statt dessen kann jegliche geeignete Syntax, die entwickelt werden kann, gemäß den hierin beschriebenen Konzepten verwendet werden.
Bestimmte Ausführungsbeispiele der vorliegenden Erfindung ermöglichen ferner ein interaktives Editieren der Meldungsdefinitionsdaten. Das heißt, eine graphische Benutzerschnittstelle (GUI; GUI = graphical user interface) ist vorgesehen, die es einem Benutzer ermöglicht, die Eingabedaten (Quelldatei 101) auf dem Bildschirm zu editieren und dann ein Sequenzdiagramm nach Bedarf zu regenerieren, um die Folgen der Änderungen zu sehen, die an den Eingabedaten durchgeführt werden. Dies wird erreicht durch Laden der Quelldatei in ihrer Gesamtheit in eine Zwischenvariable. Der Inhalt dieser Variable wird auf der GUI als editierbarer Text angezeigt. Jedes Mal, wenn der Benutzer die Regeneration des Diagramms anfordert, wird der Inhalt dieser Variable in dem Quell-Parser zugeführt, als ob er von der Quelldatei selbst gekommen wäre. Dies beschleunigt die Entwicklung von gültigen Eingabedaten durch Liefern von direktem Feedback darüber, wie das erzeugte Diagramm erscheint.
Ferner schaffen bestimmte Ausführungsbeispiele der vorliegenden Erfindung eine Befehlszeilen-Maschine für die statische Diagramm-Erzeugung. Das heißt, eine Befehlszeilen-Maschine ist vorgesehen, die ermöglicht, dass Diagramme automatisch erzeugt und in Dateien gespeichert und/oder angezeigt werden. Dies ermöglicht, dass der Diagrammerzeugungsprozess in den Veröffentlichungs-Automatisierungspro zess des Endbenutzers integriert wird. Bei einem Beispiel eines solchen Ausführungsbeispiels hat die Befehlszeilen-Maschine als Eingabe einen Satz aus Befehlszeilen-Parametern, die die Liste aus Eingabedateien definieren („Source-Files" = Quelldateien), die verarbeitet werden sollen, das gewünschte Diagrammdateiformat und das Zielortverzeichnis, in das die erzeugten Dateien (d. h. die erzeugten Sequenzdiagramme) geschrieben werden sollten. empfangen. Nachfolgend erscheint ein Beispiel einer solchen Befehlszeile gemäß einem Ausführungsbeispiel:
Bei diesem Beispiel werden alle Dateien, die sich in dem Verzeichnis „c:/My xml" befinden, die mit der Struktur „*.xml" übereinstimmen, verarbeitet, eine nach der anderen, durch den Diagrammerzeuger. Für jede Eingabedatei erzeugt der Erzeuger eine Ausgabedatei im JPEG-Format in dem Verzeichnis „c:/My Pictures". Ein solches Ausführungsbeispiel ermöglicht die automatische Erzeugung von mehreren Zehn, Hundert oder sogar Tausenden von Sequenzdiagrammen, ohne dass eine Benutzer-Interaktion für jede Erzeugung erforderlich ist. Die Befehlszeilen-Maschine kann auch verwendet werden, um Diagramme nach Bedarf zu erzeugen. Ein Ausführungsbeispiel, bei dem dies Sinn macht, ist für eine Test-Manager-Anwendung, bei der jeder Testfall eine eindeutige Beschreibung aufweisen könnte, einschließlich der Definition einer Sequenz. Um die Wartungskosten dafür zu vermeiden, Diagramme in Online-Hilfe up-to-date mit dem Inhalt jedes Testfalls zu halten, könnte die Test-Manager-Anwendung über die Befehlszeilen-Maschine das Diagramm für jeden gegebenen Testfall nach Bedarf erzeugen, wenn der Benutzer die Hilfe-Seite für diesen bestimmten Testfall geöffnet hat.
Bestimmte Ausführungsbeispiele der vorliegenden Erfindung schaffen ferner eine Laufzeitmaschine für eine dynamische Diagrammerzeugung. Dies ermöglicht die Fähigkeit, eine Laufzeitmaschine zu schaffen, die in GUI-Anwendungen integriert werden kann und Diagramme nach Bedarf aus Daten erzeugen kann, die dynamisch durch die Einkapselungs-Anwendung geliefert werden. Ein Beispiel dieses Lösungsansatzes ist die automatische Erzeugung eines Sequenzdiagramms aus einer Sequenz von Paketen, erfasst durch einen Protocol Analyzer (Protokoll-Analysierer). Bei einer solchen Anwendung ist die Quelldatei die erfassten Datenpakete. Die Implementierung des Quell-Parsers bei dieser Anwendung extrahiert Informationen aus jedem erfassten Paket, um das Interne-Daten-Modell aufzubauen, aus dem die Diagramme, die den Fluss der Pakete zeigen, dann erzeugt werden können. Bei einer solchen Anwendung kann das Diagramm während des Betriebs erzeugt werden, wenn jedes Paket erfasst wird, oder nach Bedarf, wenn der Benutzer der Protocol-Analyzer-Anwendung ein Diagramm für den Paketsatz anfordert, der aktuell in dem Erfassungspuffer ist.
Bei bestimmten Ausführungsbeispielen kann der Sequenzdiagrammerzeuger als Teil eines Gesamtdokument-Erzeugungstools implementiert sein. Somit kann die automatische Erzeugung von Sequenzdiagrammen in umfassendere Dokumentautomatisierungsprozesse integriert werden, die dynamisch die Diagramme erzeugen, die in einschließenden Text integriert sind, entnommen aus gemeinsamen oder verschiedenen Quellen und kombiniert in ein abschließendes integriertes Dokument.
Ein Beispiel dieses Lösungsansatzes ist die automatisierte Erzeugung eines Spezifikations-Dokuments in HTML aus einer Originalspezifikation, geschrieben in XML. Die XML würde die vollständigen Spezifikationsdetails enthalten, einschließlich sowohl dem Spezifikationstext als auch der Sequenzdiagramm-Definition(en).
Der Vorteil dieses Lösungsansatzes ist, dass der Inhalt der Spezifikation in einer einzelnen Quelldatei erfasst und beibehalten werden kann, während die Veröffentlichungsqualitäts-Ausgabe, die Sequenzdiagramme umfasst, automatisch erzeugt werden kann. Das Erscheinungsbild der erzeugten Ausgabe kann relativ unabhängig von dem Inhalt verändert werden, der in der Original-XML-Quelldatei gespeichert ist.
Der Prozess kann ausgedehnt werden, um eine Stapel-Verarbeitung einer Anzahl von Eingabe-Spezifikationen zu liefern, eine nach der anderen. Zum Beispiel könnte eine Gruppe aus Spezifikationen zusammen in ein einzelnes Verzeichnis gruppiert werden oder über eine Anzahl von Verzeichnissen von einer gemeinsamen Wurzel verbreitet werden. In diesem Fall kann der Dokumenterzeuger entworfen sein, um über die Verzeichnisse zu iterieren und nach Eingabedatei des richtigen Formats zu suchen und jede abwechselnd zu verarbeiten. Eingabedateien könnten erkannt werden durch eine definierte Dateibenennungs-Übereinkunft, dadurch, dass sie in einem vordefinierten Verzeichnis oder Unterverzeichnis angeordnet sind, oder durch Untersuchen ihres Inhalts auf der Suche nach einer Übereinstimmung mit dem erwarteten XML-Format.
Bezug nehmend auf 6 ist ein exemplarisches System 600 gezeigt, bei dem ein Dokumenterzeuger 601 und ein Sequenzdiagrammerzeuger 102_A als separate Komponenten implementiert sind, die parallel verwendet werden können, um ein Gesamtdokument (sowohl mit Text- als auch Sequenzdiagrammen) aus einer Quelldatei 101_A zu erzeugen, die in diesem Fall eine XML-Quelldatei ist. In diesem Fall analysiert der Quell-Parser 301_A der primären Dokument-Erzeugungsanwendung 601 die Eingabe-Quelldatei 101_A , um ihr internes Datenmodell 302_A aufzubauen. Zum Beispiel identifiziert ein Datenmodell 302_A die Elemente in der Quelldatei 101_A , wie z. B. die Textelemente und Sequenzdiagrammelemente, die in der Quelldatei 101_A beschrieben sind. Für die Sequenzdiagrammelemente, die durch den Quell-Parser 301_A identifiziert werden, kann der Quell-Parser 301_A in einem Datenmodell 302_A Informationen wie z. B. einen Identifizierer umfassen, der anzeigt, dass der entsprechende Abschnitt der Quelldatei 101_A z. B. ein Sequenzdiagrammelement, den Quelldateinamen und/oder den Ausgabedateinamen beschreibt, der für das erzeugte Sequenzdiagramm verwendet werden soll (erzeugt auf die nachfolgend beschriebene Weise durch den Diagrammerzeuger 102_A ). Das interne Datenmodell 302_A , aufgebaut durch den Quell-Parser 301_A , behält die Beziehungen und Hierarchie der verschiedenen Elemente bei (z. B. Textelemente und Sequenzdiagrammelemente), die in der Quelldatei 101_A beschrieben sind. Somit kann das resultierende Ausgabedokument 605 erzeugt werden, um die relative Reihenfolge beizubehalten, in der die verschiedenen Text- und Sequenzdiagrammelemente in der Quelldatei 101_A auftreten.
Aus dem Datenmodell 302_A erzeugt der Dokumenterzeuger 601 die verschiedenen Abschnitte der Ausgabedokumente 605, bei diesem Beispiel in HTML. Genauer gesagt verwendet der Dokument-Parser 602 die Informationen in dem Datenmodell 302_A , um die Textabschnitte der Quelldatei 101_A zu identifizieren, die in das HTML-Ausgabedokument 605 geschrieben werden sollen, sowie die Sequenzdiagrammelemente identifizieren. Jede Instanz einer Sequenzdiagramm-Definition in der Quelldatei 101_A wird eine Referenz 604 in dem erzeugten HTML-Dokument 605 zu einer externen Bilddatei 103_A (z. B. ein Etikett <img src="xxx">tag).
Die Eingabequelldatei 101_A wird auch zu der Diagrammerzeuger-Anwendung 102_A zugeführt, die eine Ausgabediagrammdatei 103_A für jede Sequenzdiagrammdefinition in der Quelldatei 101_A auf die oben beschriebene Weise erzeugt. Bei diesem Beispiel, nachdem der Dokument-Parser 602 auf ein Sequenzdiagrammelement trifft, das in dem internen Datenmodell 302_A für die Quelldatei 101_A identifiziert ist, ruft ein solcher Dokument-Parser 602 den Diagrammerzeuger 102_A auf und verursacht, dass ein solcher Diagrammerzeuger das entsprechende Sequenzdiagramm erzeugt. Somit greift der Sequenzdiagrammerzeuger 102_A auf die Quelldatei 101_A zu, identifiziert das darin definierte entsprechende Sequenzdiagrammelement und erzeugt das entsprechende Sequenzdiagramm 103_A basierend auf der Beschreibung der Quelldatei auf die oben beschriebene Weise (z. B. mit dem Sequenzdiagrammerzeuger 102 aus 3). Das heißt, der Quell-Parser 301 analysiert die XML-Quelldatei 101_A und besetzt das interne Datenmodell 302 mit Informationen, die dem/den identifizierten Sequenzdiagramm/en entsprechen, die in einer solchen Quelldatei 101_A auf die oben beschriebene Weise in Verbindung mit 3 beschrieben sind. Der Diagramm-Parser 303 analysiert das interne Datenmodell 302 und erzeugt Zeichenbefehle zu der Aufbereitungsmaschine 203, um eine Sequenzdiagrammdatei 103_A auf die oben beschriebene Weise zu erzeugen.
Somit liest bei diesem exemplarischen Ausführungsbeispiel der Quell-Parser 301_A (des Dokumenterzeugers 601) den Quelltext 101_A , prüft die Syntax und baut ein internes Datenmodell 302_A auf, das alle Informationen darstellt, die aus der Quelle 101_A gelesen werden, die als Textinhalt in ein zu erzeugendes Dokument 605 integriert werden sollen, während der Quell-Parser 301 (des Sequenzdiagrammerzeugers 102_A ) den Quelltext 101_A liest, die Syntax prüft und ein internes Datenmodell 302 aufbaut, das alle Sequenzdiagramme darstellt, die in der Quelle 101_A beschrieben sind. Die Datenmodelle 302 und 302_A bewahren die Hierarchie und Beziehungen, die in der Quelle 101_A ausgedrückt sind (z. B. von dem Textinhalt und den Sequenzdiagrammen). Der Dokument-Parser 602 des Dokumenterzeugers 601 verarbeitet das Datenmodell 302_A , um die Abschnitte zu identifizieren, die in dem Dokument 605 erzeugt werden sollen, und den Inhalt aus jedem Abschnitt zu extrahieren. Der Dokument-Parser 602 erzeugt dann eine Sequenz aus Ausgabeformatierungsbefehlen zu dem HTML-Erzeuger 603. Der HTML-Erzeuger 603 transformiert die Formatierungsbefehle in gut gebildetes HTML und schreibt sie in die Ausgabedatei 605.
Somit verwendet der Dokumenterzeuger 601 die Quelldatei 101_A , um den Text für die Ausgabedatei 605 zu erzeugen und Referenzen (z. B. Hyperlinks) 604 zu den Sequenzdiagrammen zu erzeugen, die in der Quelldatei 101_A identifiziert sind, und der Diagrammerzeuger 102_A erzeugt die Sequenzdiagramme 103_A , die in der Quelldatei 101_A identifiziert sind. Dementsprechend kann bei bestimmten Ausführungsbeispielen die Referenz 604 eine Hyperlink innerhalb eines Dokuments 605 zu einem entsprechenden Sequenzdiagramm sein, derart, dass ein Benutzer auf die Hyperlink klicken kann, um auf das entsprechende Sequenzdiagramm 103_A zuzugreifen. Bei anderen Ausführungsbeispielen kann das Sequenzdiagramm 103_A innerhalb des Dokuments 605 an der entsprechenden Referenz 604 angezeigt sein.
Bezug nehmend auf 7 ist ein exemplarisches System 700 gezeigt, bei dem ein Sequenzdiagrammerzeuger in einer Dokumenterzeuger-Anwendung 601_A integriert ist. In diesem Fall sind die Merkmale des Diagrammerzeugers mit dem Dokumenterzeuger 601_A integriert. Die Eingabequelldatei 101_A wird einmal durch den Quell-Parser 301_A analysiert, und der Dokument-Parser 602 und der Diagramm-Parser 303_A teilen sich das gemeinsame interne Datenmodell 302_A . Somit analysiert der Quell-Parser 301_A bei diesem Beispiel die Textinhalt-Informationen und die Sequenzdiagramm-Informationen, die in der Quelldatei 101_A enthalten sind, während die Beziehungen und Hierarchie einer solchen Quelldatei 101_A beibehalten werden. Der Dokument-Parser 602 ruft den Diagramm-Parser 303_A für jede Sequenzdiagramm-Definition auf, die in der Eingabequelldatei 101_A enthalten ist.
In einer Hinsicht ist diese Dokumenterzeuger-Konfiguration aus 7 eine einfachere Lösung, da sie den Bedarf beseitigt, Informationen zwischen zwei separaten Anwendungen zu kommunizieren, um die Eingabedatei und den gewünschten Ausgabedatei-Namen und die -Position für jedes erzeugte Sequenzdiagramm zu identifizieren. Alle diese Informationen sind nun in einer Anwendung enthalten.
Der Sequenzdiagrammerzeuger und der Dokumenterzeuger sind bei einem Ausführungsbeispiel Softwarecode, der auf einem computerlesbaren Medium gespeichert und durch eine prozes sorbasierte Vorrichtung ausführbar ist, wie z. B. einen Personalcomputer (PC). Es sollte jedoch darauf hingewiesen werden, dass die Elemente des Sequenzdiagrammerzeugers und des Dokumenterzeugers, die oben beschrieben sind, in Software, Hardware und/oder einer Kombination derselben implementiert sein können.
Obwohl die vorliegende Erfindung und ihre Vorteile detailliert beschrieben wurden, sollte darauf hingewiesen werden, dass verschiedene Änderungen, Ersetzungen und Abänderungen hierin durchgeführt werden können, ohne von dem Schutzbereich und dem Wesen der Erfindung abzuweichen, wie sie durch die angehängten Ansprüche definiert ist. Ferner soll der Schutzbereich der vorliegenden Anmeldung nicht auf die bestimmten Ausführungsbeispiele von Prozess, Maschine, Herstellung, Materialzusammensetzung, Einrichtungen, Verfahren und Schritten eingeschränkt sein, die in der Beschreibung beschrieben sind. Wie ein Durchschnittsfachmann auf dem Gebiet ohne weiteres aus der Offenbarung der vorliegenden Erfindung erkennen wird, können Prozesse, Maschinen, Herstellung, Materialzusammensetzungen, Einrichtungen, Verfahren oder Schritte, die bereits existieren oder später entwickelt werden, die im Wesentlichen die selbe Funktion ausführen und im Wesentlichen das selbe Ergebnis erreichen wie die entsprechenden Ausführungsbeispiele, die hierin beschrieben sind, gemäß der vorliegenden Erfindung verwendet werden. Dementsprechend sollen die angehängten Ansprüche innerhalb ihres Schutzbereichs solche Prozesse, Maschinen, Herstellung, Materialzusammensetzungen, Einrichtungen, Verfahren oder Schritte umfassen.

Claims

System, das folgende Merkmale aufweist: eine Textquelldatei (101) in einer nicht-proprietären Sprache, wobei die Textquelldatei einen Fluss für eine Anwendung beschreibt; und einen anwendungs-generischen Sequenzdiagrammerzeuger (102), der wirksam ist, um als Eingabe die Quelldatei zu empfangen und ein Sequenzdiagramm (103) zu erzeugen, das den Fluss darstellt, der durch die Quelldatei beschrieben wird.
System gemäß Anspruch 1, bei dem die nicht-proprietäre Sprache eine Markierungssprache aufweist.
System gemäß Anspruch 1 oder 2, bei dem die nicht-proprietäre Sprache die erweiterbare Markierungssprache (XML) aufweist.
System gemäß einem der Ansprüche 1 bis 3, bei dem der Sequenzdiagrammerzeuger anwendungs-generisch ist, insofern, als der Sequenzdiagrammerzeuger wirksam ist, um das Sequenzdiagramm für den Fluss jeglicher Anwendung zu erzeugen, der durch die Textquelldatei beschrieben wird.
System gemäß einem der Ansprüche 1 bis 4, bei dem die Anwendung, für die der Fluss durch die Textquelldatei beschrieben wird, eines aufweist, ausgewählt aus der Gruppe, bestehend aus: einer computerausführbaren Software-Anwendung, einem Kommunikationsprotokoll und einem Meldungsaustausch zwischen Aktoren.
System gemäß einem der Ansprüche 1 bis 5, bei dem die Anwendung, für die der Fluss durch die Textquelldatei beschrieben wird, nicht die Textquelldatei ist.
System gemäß einem der Ansprüche 1 bis 6, bei dem der anwendungs-generische Sequenzdiagrammerzeuger folgendes Merkmal aufweist: einen Quell-Parser (301), der wirksam ist, um die Eingabequelldatei zu lesen und ein internes Datenmodell (302) aufzubauen, das die Diagramm-Metadaten darstellt.
System gemäß Anspruch 7, bei dem der Quell-Parser wirksam ist, um in der Eingabequelldatei beschriebene Aktoren und Meldungssequenzen zu identifizieren, die zwischen den Aktoren kommuniziert werden.
System gemäß Anspruch 8, bei dem dass interne Datenmodell die Diagramm-Metadaten umfasst, die den identifizierten Aktoren und Meldungssequenzen entsprechen.
System gemäß einem der Ansprüche 7 bis 9, bei dem der anwendungs-generische Sequenzdiagrammerzeuger ferner folgendes Merkmal aufweist: einen Diagramm-Parser (303), der wirksam ist, um das interne Datenmodell zu verarbeiten und entsprechende Zeichenbefehle zu erzeugen.
System gemäß Anspruch 10, bei dem der anwendungs-generische Sequenzdiagrammerzeuger ferner folgendes Merkmal aufweist: eine Aufbereitungsmaschine (203), die wirksam ist, um die Zeichenbefehle zu empfangen und das Sequenzdiagramm zu erzeugen, das den Fluss darstellt, der durch die Quelldatei beschrieben wird.
System gemäß einem der Ansprüche 1 bis 11, bei dem der anwendungs-generische Diagrammerzeuger ein Befehlszeilen-Hilfsprogramm umfasst, das wirksam ist, um zumindest ein Sequenzdiagramm aus zumindest einer Quelldatei zu erzeugen, ansprechend auf einen empfangenen Befehlszeilen-Befehl.
Verfahren, das folgende Schritte aufweist: Empfangen (501), in einen Quell-Parser (301), einer Textquelldatei (101), die in einer nicht-proprietären Sprache ist und einen Fluss für eine Anwendung beschreibt; Aufbauen (502), durch den Quell-Parser und basierend auf der Textquelldatei, eines Datenmodells (302) für ein Diagramm des Flusses, der durch die Textquelldatei beschrieben wird; Erzeugen (503), durch einen Diagramm-Parser (303) und basierend auf dem Datenmodell, entsprechender Zeichenbefehle; und Aufbereiten (504) eines Sequenzdiagramms (103) durch eine Aufbereitungsmaschine (203), das den Fluss darstellt, der durch die Textquelldatei beschrieben wird, ansprechend auf die Zeichenbefehle.
Verfahren gemäß Anspruch 13, bei dem die nicht-proprietäre Sprache eine Markierungssprache aufweist.
Verfahren gemäß Anspruch 13 oder 14, bei dem die nicht-proprietäre Sprache die erweiterbare Markierungssprache (XML) aufweist.
Verfahren gemäß einem der Ansprüche 13 bis 15, bei dem die Textquelldatei unabhängig von der Anwendung ist, für die die Textquelldatei den Fluss beschreibt.
Verfahren gemäß einem der Ansprüche 13 bis 16, bei dem das Aufbauen des Datenmodells durch den Quell-Parser folgenden Schritt aufweist: Identifizieren, in der Textquelldatei, von beschriebenen Aktoren und Meldungs-Sequenzen, die zwischen den Aktoren kommuniziert werden.
Verfahren gemäß Anspruch 17, bei dem das Aufbauen des Datenmodells durch den Quell-Parser ferner folgenden Schritt aufweist: Integrieren von Informationen in das Datenmodell, die den identifizierten Aktoren und Meldungs-Sequenzen entsprechen.
Verfahren gemäß einem der Ansprüche 13 bis 18, bei dem der Quell-Parser, der Diagramm-Parser und die Aufbereitungsmaschine wirksam sind, um das Sequenzdiagramm zu erzeugen, das den Fluss jeglicher Anwendung darstellt, die in der Textquelldatei beschrieben ist.
Verfahren gemäß einem der Ansprüche 13 bis 19, bei dem die Anwendung, für die der Fluss durch die Textquelldatei beschrieben wird, jegliches aufweist, ausgewählt aus der Gruppe, bestehend aus: einer computerausführbaren Software-Anwendung, einem Kommunikationsprotokoll und einem Meldungsaustausch zwischen Aktoren.
Verfahren gemäß einem der Ansprüche 13 bis 20, bei dem das Empfangen, in dem Quell-Parser, der Textquelldatei, folgenden Schritt aufweist: Empfangen von zumindest einer Textquelldatei in dem Quell-Parser ansprechend auf einen Befehlszeilen-Befehl.
Computerausführbarer Code, der auf einem computerlesbaren Medium gespeichert ist, wobei der computerausführbare Code folgende Merkmale aufweist: einen Code zum Empfangen einer Textquelldatei, die einen Fluss für eine Anwendung beschreibt, wobei die Textquelldatei in einer nicht-proprietären Sprache ist und unabhängig von der Anwendung ist; und einen Code zum Erzeugen von Zeichenbefehlen zum Aufbereiten eines Sequenzdiagramms, das den Fluss darstellt, der durch die Textquelldatei beschrieben wird.
Computerausführbarer Code gemäß Anspruch 22, bei dem der Code zum Erzeugen von Zeichenbefehlen folgendes Merkmal aufweist: einen Code zum Identifizieren, in der Textquelldatei, von beschriebenen Aktoren und Meldungs-Sequenzen, die zwischen den Aktoren kommuniziert werden.
Computerausführbarer Code gemäß Anspruch 23, der ferner folgendes Merkmal aufweist: einen Code zum Aufbauen eines Datenmodells, das Informationen umfasst, die den identifizierten Aktoren und Meldungs-Sequenzen entsprechen.
Computerausführbarer Code gemäß Anspruch 23 oder 24, bei dem der Code zum Erzeugen von Zeichenbefehlen ferner folgendes Merkmal aufweist: einen Code zum Erzeugen, basierend auf den identifizierten Aktoren und Meldungs-Sequenzen, der Zeichenbefehle.
Computerausführbarer Code gemäß einem der Ansprüche 22 bis 25, der ferner folgendes Merkmal aufweist: einen Code, ansprechend auf die erzeugten Zeichenbefehle, zum Aufbereiten des Sequenzdiagramms, das den Fluss darstellt, der durch die Textquelldatei beschrieben wird.
Computerausführbarer Code gemäß einem der Ansprüche 22 bis 26, bei dem die nicht-proprietäre Sprache eine Markierungssprache aufweist.
Computerausführbarer Code gemäß einem der Ansprüche 22 bis 27, bei dem die nicht-proprietäre Sprache die erweiterbare Markierungssprache (XML) aufweist.
Computerausführbarer Code gemäß einem der Ansprüche 22 bis 28, bei dem die Anwendung, für die der Fluss durch die Textquelldatei beschrieben wird, jegliches aufweist, ausgewählt aus der Gruppe, bestehend aus: einer computerausführbaren Software-Anwendung, einem Kommunikationsprotokoll und einem Meldungsaustausch zwischen Aktoren.
Anwendungs-generischer Sequenzdiagrammerzeuger, der wirksam ist, um ein Sequenzdiagramm zu erzeugen, das einen Fluss jeglicher Anwendung darstellt, der in einer Textquelldatei beschrieben ist, wobei der anwendungsgenerische Sequenzdiagrammerzeuger folgende Merkmale aufweist: eine Einrichtung zum Empfangen der Textquelldatei, wobei die Textquelldatei in einer nicht-proprietären Sprache ist und einen Fluss für eine Anwendung beschreibt; eine Einrichtung zum Erzeugen eines Sequenzdiagramms, das den Fluss darstellt, der durch die Quelldatei beschrieben wird.
Anwendungs-generischer Sequenzdiagrammerzeuger gemäß Anspruch 30, bei dem die nicht-proprietäre Sprache die erweiterbare Markierungssprache (XML) aufweist.