Heiner KückerASCII Art Flow Diagram Parser |
|
|
Home Java-Seite Bit Packed Array ASM Improved heterogene Map, HMap Constraint Code Generator JSP WorkFlow PageFlow FlowControl Page Flow Engine Web Flow Engine Control_and_Command JSP_Spreadsheet Code-Generator für Option-Either-Stil in Java verbesserter Comparator Fluent-Interface Code-Generator auf Basis einer Grammatik Visitor mit Multidispatch for-Schleife mit yield-return Kognitions-Maschine semantisches Netz Domain Parser Codegenerator_für hierarchische Datenstrukturen Expression_Engine Formula_Parser Thread Preprocessor State Transition Engine AspectJ Java_Explorer DBF_Library Kalender_Applet SetGetGen BeanSetGet CheckPackage LineNumbers GradDms Excel-Export StringTokenizer JspDoc JspCheck JSP-Schulung Java Server Pages Struts Ascii-Tabellen- Layouter Ascii-Baum- Layouter Ascii-Art-Fluss- Diagramm- Parser AsciiArt AssignmentMatrix Layouter StringSerial Silbentrennung JDBC_Schlüssel- Generierung bidirektional/ unidirektional gelinkte Liste Java_Sitemap Generator XmlBuilder RangeMap StringFormatter VersionSafe XCopy JTextField CommandLine- ParamReader Bitmap-Grafik MultiMarkable- Buffered- InputStream JavaCache JdomUtil CollectionUtil XML Really Pull Parser Log-Filter Remote-Protokoll Sudoku-Generator Delegation statt Mehrfachvererbung Disjunct Interval Set WebCam_Demo Weiterentwicklung_Java Alaska-XBase++-Seite Projekte Philosophien Techniken Konzepte Sudoku Kontakt / Impressum Links SiteMap Letzte Aktualisierung: 15.04.2007 |
Java Parser für Fluss-Diagramme in ASCII-Art
ASCII-Art-Diagramme können leicht im Quell-Code oder in Konfigurationsdateien
untergebracht werden und erlauben die übersichtliche Darstellung von Zusammenhängen
ohne grafisches Tool.
Zum Editieren der Fluss-Diagramme benutzt am besten den Java Ascii Versatile Editor (JavE) oder UltraEdit mit dem Spaltenmodus (Alt-C). Download der Quelldateien ASCII_ART_FLOW_PARSER.zip
Suchworte: ASCII, Art, Fluss, Fluß, Diagramm, Flussdiagramm, Flußdiagramm, Flowdiagram, Flow, Diagram, Parser
Allgemeines
-----------
ASCII-Art-Diagramme können leicht im Quell-Code oder in Konfigurationsdateien
untergebracht werden und erlauben die übersichtliche Darstellung von komplexen
Zusammenhängen ohne grafisches Tool.
Dabei sind diese Diagramme natürlich den Einschränkungen des Textes/Zeichencodes
unterworfen, reichen aber für viele Fälle aus, da die Lesbarkeit wesentlich
höher als bei XML-Format, JSON-Format oder Dot-Format ist.
Der Zeitaufwand zum Erstellen eines ASCII-Art-Diagrammes ist meist höher als
bei alternativen Notationen, aber dafür ist der Zeitaufwand zum Lesen wesentlich
kleiner als bei alternativen Notationen. Demzufolge ist der Gesamt-Zeitaufwand
bei der ASCII-Art-Notation geringer.
Lesbarkeit sollte sowieso ein wichtiges Kriterium beim Codieren sein, obwohl
ich bei dem Code von einigen Kollegen den Eindruck habe, dass Obfuskierung
das vorrangige Implementierungsziel war.
Die eingeparste Datenstruktur kann in XML umgewandelt, zur Codegenerierung oder
Konfiguration (Vergleiche Struts/JSF-Navigation, Zustandautomat) verwendet werden.
Anleitung ASCII-Art Fluss-Diagramm-Parser (FlowDiagramParser)
=============================================================
Parser für Fluss-Diagramme in ASCII-Art.
Home-Page: http://www.heinerkuecker.de/AsciiArtFlowDiagramParser.html
Es werden die Knoten (Node) und die von den
Knoten abgehenden Verbindungen (Connections)
eingeparst.
Die entstandene Netz-Struktur (FlowNet) kann
dann für Code-Generierung oder als Konfiguration
(Vergleiche Struts/JSF Navigation, Zustandsautomat)
verwendet werden.
Als Parameter wird ein String-Array übergeben.
Zum Einlesen einer Text-Datei in das String-Array
kann die Methode StringUtil#fileToStrArr()
verwendet werden.
Test's und Beispiele finden sich in der Klasse
TestFlowParser, die mit den Dateien aus dem
Ordner 'test_data' zusammen arbeitet.
Mit der Boolean-Konstanten 'TestFlowParser#isTestForSpaceAndNoSpace'
in der Methode 'testParse' im TestFlowParser kann gesteuert werden,
ob der Test mit oder ohne weiten (Spaces) oder engen (trim) Rand erfolgen soll.
Durch den Test mit engen und weitem Rand werden Fehler,
die nur am Rand auftreten (wie ArrayIndexOutOfBounds), gefunden.
Aufruf des Fluss-Diagramm-Parsers aus Java
------------------------------------------
Der Pfad zur Diagramm-Datei muss wie üblich über ClassLoader-Resource
oder Servlet-Config (Ordner WEB-INF) besorgt werden.
try
{
// Einlesen der Diagramm-Datei in ein String-Array
String[] flowStrArr =
StringUtil.fileToStrArr(
diagramFileNameWithPathString );
// das eigentliche Parsen
FlowNet flowNet = FlowNet.parse( flowStrArr );
}
catch (FlowNetParseException t)
{
...Fehlerbehandlung...
Das zurückgegebene FlowNet-Objekt repräsentiert die
eingeparste Diagramm-Struktur. Mit dem FlowNet-Objekt können
weitere Operationen wie Prüfungen, Codegenerierung oder
Applikations-Konfiguration erfolgen.
Die Schnittstelle des ASCII-Art Fluss-Diagramm-Parsers
habe ich möglichst klein gehalten. Die Klassen des Parsers
sind möglichst Immutables und der Member- und Methoden-Scope
soweit wie möglich auf Java-default gesetzt.
Falls weitere Informationen benötigt werden, bitte die
Scopes selbst im Code auf public setzen.
Einbindung eines Fluss-Diagrammes in Quellcode
----------------------------------------------
Zur nahtosen Einbindung in den Quellcode kann das Fluss-Diagramm
als String-Array-Konstante in einer Java-Klasse deklariert
werden.
Dadurch ist es nicht nötig, aus dem Quellcode in eine andere Datei
zu wechseln, um den Fluss zu bearbeiten oder bei der Code-Analyse
zu verstehen.
/**
*
*/
public static final StateTransitionEngine WEB_FLOW_STATE_ENGINE =
parseWebFlowAsciiDiagram( new String[] {
" +-------+ ",
" | Start | ",
" +-------+ ",
" | ",
" | +---------+ +------+ ",
" +----------->| Process |--+-- ready --->| Stop | ",
" ^ +---------+ | +------+ ",
" | | ",
" +----- repeat -----+ ",
} );
/**
*
*/
public static StateTransitionEngine parseWebFlowAsciiDiagram(
final String[] pAsciiFlowStrArr )
{
TODO
return engine;
}
Einbindung eines Fluss-Diagrammes in Javadoc
--------------------------------------------
Mit Hilfe des DomainParsers (TODO: Link) kann Java-Quellcode
(bis 1.4) eingelesen werden (TODO: Beispielcode).
Damit die ASCII-Art-Diagramme nach dem Generieren der javadoc
bei der Anzeige im javadoc-HTML nicht verfälscht werden,
müssen sie in <pre> ... </pre> - Tags eingeschlossen werden.
Ein Problem dabei ist das Auftreten der Sequenz '-->'.
Diese wird als Ende eines HTML-Kommentares interpretiert.
Deshalb müssen diese Stellen als '-->' (HTML-Entität & g t ;)
notiert werden (TODO: Konvertierungstool).
Erzeugen eines Fluss-Diagrammes in ASCII-Art
--------------------------------------------
Zum effektiven Erzeugen eines Fluss-Diagrammes in ASCII-Art
eignet sich der Editor Ultraedit mit seiner Bertiebsart
Spaltenmode
http://www.ultraedit.com/
sowie der Java Ascii Versatile Editor JavE
http://www.jave.de/
Fehlerbehandlung
----------------
Wie mit nicht interpretierbaren Zeichen umgegangen werden soll,
ist noch offen.
Mir schwebt eine strikte und eine tolerante Betriebsart vor.
Verbotene weisse Zeichen
------------------------
Als weisses Zeichen ist nur das Leerzeichen erlaubt.
Bitte keine Tab's, Carriage Return oder andere weisse
Zeichen im Parameter-String-Array benutzen.
Prüfung auf Eindeutigkeit der Bezeichner aller Knoten (FlowNode)
----------------------------------------------------------------
Durch Aufruf der Methode
FlowNet#checkNodeIdentifierUniqueness()
kann abgesichert werden, dass jeder Knoten-Name (Zustands-Name)
nur ein einziges Mal auftritt.
Bei Verletzung der Eindeutigkeit wirft diese Methode
eine Exception, da dies einem Compiler-/Konfigurations-Fehler
entspricht und die entsprechende Applikation nicht starten kann.
Prüfung auf nicht geparste Zeichen im übergebenen String-Array
--------------------------------------------------------------
Durch Aufruf der Methode
FlowNet#checkForUnparsedCharacters()
kann abgesichert werden, dass alle Zeichen auf der Diagramm-Fläche
eingeparst wurden und somit gültig zum Diagramm gehören.
Das heisst, es sind keine Zeichen, die nicht zum Diagramm gehören erlaubt.
Bei Auftreten nicht geparster Zeichen wirft diese Methode
eine Exception, da dies einem Compiler-/Konfigurations-Fehler
entspricht und die entsprechende Applikation nicht starten kann.
Prüfung auf nicht verbundene Knoten im Fluss-Diagramm
-----------------------------------------------------
Durch Aufruf der Methode
FlowNet#checkForUnconnectedNodes()
kann abgesichert werden, dass alle Knoten auf der Diagramm-Fläche
mindestens eine eingehende oder ausgehende Verbindung besitzen
und somit gültig zum Diagramm gehören.
Das heisst, es sind keine nicht verbundenen Knoten erlaubt.
Bei Auftreten nicht verbundener Knoten wirft diese Methode
eine Exception, da dies einem Compiler-/Konfigurations-Fehler
entspricht und die entsprechende Applikation nicht starten kann.
Prüfung auf Verbindungen, die nicht die geforderte Anzahl Texte besitzen
------------------------------------------------------------------------
Durch Aufruf der Methoden
FlowNet#checkForExactlyOneTextPerConnection()
FlowNet#checkMinMaxTextCountPerConnection(min,max)
kann abgesichert werden, dass alle Verbindungen auf der Diagramm-Fläche
mindestens und maximal die die geforderte Anzahl Texte besitzen und
somit gültig sind.
So müssen zum Beispiel Zustandsübergangsdiagramme (State Transition Diagram)
genau einen Text je Verbindung (Zustandsübergang) besitzen, der den
Zustandsübergang beschreibt oder eine Bedingung für den Übergang
enthält.
Alternativ kann bei fehlendem Text ein Standard(default)-Wert angenommen
werden ( siehe JSF-Navigation-Beispiel (Example) ).
Bei Auftreten nicht erlaubter Anzahl Texte werfen diese Methoden
eine Exception, da dies einem Compiler-/Konfigurations-Fehler
entspricht und die entsprechende Applikation nicht starten kann.
Prüfung auf Verbindungen, die nicht eindeutig sind
--------------------------------------------------
Durch Aufruf der Methode
FlowNet#checkConnectionUniqueness() // TODO String pDefaultText
kann abgesichert werden, dass alle Verbindungen eindeutig
sind und somit das Diagramm gültig ist.
Das heisst, es sind keine uneindeutigen gleichen Verbindungen
erlaubt.
Es wird verglichen auf die Kombination
Anfangsknoten -- Verbindungs-Text(e) --> End-Knoten
Bei Auftreten von gleichen
Anfangsknoten-Verbindungs-Text(e)-End-Knoten-Kombinationen,
wirft diese Methode eine Exception, da dies einem
Compiler-/Konfigurations-Fehler entspricht und die entsprechende
Applikation nicht starten kann.
Prüfung auf Zustandsübergänge, die nicht eindeutig sind
-------------------------------------------------------
Durch Aufruf der Methode
FlowNet#checkTransitionUniqueness(String pDefaultText)
kann abgesichert werden, dass alle Verbindungen eindeutig
sind und somit das Diagramm gültig ist.
Der Parameter pDefaultText legt einen zu verwendenen Text
beim Fehlen des Verbindungstextes fest und ist damit auch
ein Schalter, ob Verbindungstexte fehlen dürfen.
Eine eindeutige Verbindung ist dadurch gekennzeichnet, dass
für eine Start-Knoten-Verbindungs-Text-Kombination nur ein
einziger End-Kntoen existiert.
Die Verbindung darf nach dem Verbindungstext nicht mehr
gesplittet werden.
Demzufolge darf nur ein Endknoten durch eine
Start-Knoten-Verbindungs-Text-Kombination erreichbar sein.
Voraussetzung ist die Prüfung der geforderten Anzahl
Verbindungstexte (genau 1 ohne Deafult-Text, sonst 0..1).
Umwandlung des geparsten Diagrammes in XML oder ein anderes Format
------------------------------------------------------------------
Die interne Struktur des FlowNet ist durch das mögliche Splitten
und Joinen der Verbindungen relativ kompliziert.
Deshalb werden an der Schnittstelle Value-Objekte herausgegeben,
welche eine einfachere Struktur wiedergeben.
Es ist nicht möglich, über diese Value-Objekte die innere
Struktur des FlowNet zu verändern.
Die Beispiel-Methode TestFlowParser#createJsfNavigationXml kann als
Vorlage für beliebige Format-Umwandlungen dienen.
Hier eine kurze Erläuterung des bereitgestellten API's:
// Value-Objekt-Array mit allen Knoten und den jeweils abgehenden Verbindungen
FlowNodeAndConnectionsValueObj[] flowNodeAndConnectionsValObjArr = flowNet.getFlowNodeValueObjArr();
// Schleife über alle Knoten
for (int i = 0; i < flowNodeAndConnectionsValObjArr.length; i++)
{
// Abarbeiten eines Knoten
FlowNodeAndConnectionsValueObj flowNodeAndConnectionsValueObj = flowNodeAndConnectionsValObjArr[ i ];
// Array mit Verbindungs-Texten und den dazugehörenden End-Knoten der vom aktuell bearbeiteten Knoten abgehenden Verbindungen
FlowConnectionTextArrAndEndNodeValueObj[] flowConnectionTextArrAndEndNodeValueObjArr = flowNodeAndConnectionsValueObj.connectionValueObjArr;
// Prüfen auf abgehende Verbindungen vom aktuell bearbeiteten Knoten
if ( flowConnectionTextArrAndEndNodeValueObjArr != null //--
flowConnectionTextArrAndEndNodeValueObjArr.length > 0 )
// es gibt abgehende Connections
{
//Abfragen des Textes des aktuell bearbeiteten Start-Knotens
String startNodeTextTrimmed = flowNodeAndConnectionsValueObj.startNode.getNodeTextTrimmed();
// Schleife über alle vom aktuell bearbeiteten Knoten abgehenden Verbindungen
for (int j = 0; j < flowConnectionTextArrAndEndNodeValueObjArr.length; j++)
{
// Abarbeiten einer Verbindung
FlowConnectionTextArrAndEndNodeValueObj flowConnectionTextArrAndEndNodeValueObj = flowConnectionTextArrAndEndNodeValueObjArr[ j ];
// Ermitteln des Verbindungs-Textes
String connectionText = flowConnectionTextArrAndEndNodeValueObj.flowConnectionTextArr[ 0 ].getTextTrimmed();
//Abfragen des Textes des End-Knotens der aktuell bearbeiteten Verbindung
String endNodeTextTrimmed = flowConnectionTextArrAndEndNodeValueObj.endNode.getNodeTextTrimmed();
}
}
}
Besonderheiten der JSF-Navigation, wie 'redirect' und Pattern
werden noch nicht unterstützt.
'redirect' könnte folgendermassen realisiert werden: Jede 'redirect'-
Connection erhält im Text den Postfix (Anhang) ' redirect', im
Konvertierungsprogramm wird nach diesem String (connectionText.endsWith)
gesucht und dieser abgeschnitten. Beim Auftreten von ' redirect'
wird das redirect-Element zur Navigations-Regel hinzugefügt.
'redirect' wird zum Beispiel für das Rücksetzen von Maskenfeldern
bei Navigation auf die gleiche Seite benötigt (was für ein Sch...).
Für die Pattern habe ich noch keine Lösung. Diese sind im Grunde auch
Notbehelfe für die allgemeinen Probleme in der Navigation des JSF-Frameworks,
wie fehlende zentrale Lösungen für Fehlerseiten oder die Behandlung
fehlgeleiter Benutzer.
Knoten (FlowNode)
-----------------
Rechteckiger Kasten mit Text:
+-----------------+
| A |
| |
| |
+-----------------+
Oben Bindestriche '-'
An der Seite '|'-Zeichen (Vertical Line | Dezimal 124).
An den Ecken Plus-Zeichen
Plus-Zeichen im vertikalen oder horizontalen Rand für Verbindungen
werden noch nicht unterstützt.
In Zukunft könnten weitere Knoten-Arten wie Rhombus,
abgeschrägte Ecke, mit Gleichheitszeichen oben und unten
und so weiter dazukommen.
Verbindung (FlowConnection)
---------------------------
Eine Verbindung kann aus Bindestrichen, '|'-Zeichen,
Plus-Zeichen bei Richtungswechsel, Plus-Zeichen beim
Auftrennen (Split) und Pfeilen am Ende bestehen.
Demzufolge können Verbindungen nur horizontal oder
vertikal verlaufen. Diagonale Verbindungen (Slash/
BackSlash) werden noch nicht unterstützt.
Eine FlowConnection besitzt immer einen Anfangs- und
einen End-Konten und genau einem Richtungspfeil.
Richtungslose (keine Pfeile) und bidirektionale (zwei Pfeile)
verbindungen werde noch nicht unterstützt.
Alle Teile der FlowConnection-Struktur implementieren
die abstrakte Klasse FlowConnectionPart.
Am Ende einer Verbindung muss eines von folgenden Pfeil-Zeichen
stehen:
Links eintretend: '>' grösser als
Rechts eintretend: '<' kleiner als
Oben eintretend: 'V' oder 'v' kleines oder grosses V
Unten eintretend: 'A' oder '^' grosses A oder Dach (Potenz/Power)-Zeichen
Richtungswechsel (FlowConnectionBend)
-------------------------------------
Ein Richtungswechsel besteht aus einer ankommenden
Linie (FlowConnectionLinePart) einem Plus-Zeichen
und einer abgehenden Linie.
---+
|
|
Kreuzung (FlowConnectionCrossing)
---------------------------------
Eine Kreuzung tritt beim Überschneiden
zweier Verbindungen (FlowConnection) auf.
Es gibt horizontale Kreuzungen
|
-|-
|
und vertikale Kreuzungen
|
---
|
Die Kreuzung bezieht sich immer auf die
unterbrochene Linie, während die nicht
unterbrochene, gekreuzte Linie kein
FlowConnectionCrossing-Objekt enthält.
Auftrennen einer Verbindung (FlowConnectionSplit)
-------------------------------------------------
Aus einer Verbindung kann eine zweite Verbindung
abzweigen.
Beispiel:
-------+-------->
|
+-------->
Es ist auch möglich eine Abzweigung und einen
Richtungswechsel zu kombinieren. Welche abgehende
Linie als Abzweig und welche als Fortsetzung gilt,
ergibt sich zufällig:
+-------->
|
-------+
|
+-------->
Eventuell können auch zwei Verbindungen aus einer
Verbindung abzweigen:
+-------->
|
-------+-------->
|
+-------->
Eine gesplitte Verbindung hat einen Anfangs-Knoten,
aber mehrere End-Knoten.
Deshalb gibt eine FlowConnection ein Array von
End-Knoten zurück.
Gesplittete Verbindungen dienen wie vereinigte
Verbindungen zum Einsparen von Platz auf den
Diagrammen.
Vereinigung zweier Verbindungen (FlowConnectionJoin)
----------------------------------------------------
Eine Linie kann mit einer Pfeilspitze in eine andere
Linie eintreten.
|
--->| --->+---
| |
Das Eintreten kann auf einem geraden Linien-Teil oder
einer Krümmung oder einem beliebigen anderen Teil der
Eintritt-Linie erfolgen.
Dadurch bekommt die eintretende Linie den End-Knoten
(oder die End-Knoten bei einem nachfolgenden Split)
zugeordnet.
Das Eintreten ohne Pfeilspitze kann der Parser
nicht erkennen.
---------+---------------->
|
| VERBOTEN !!!
---------+
-------------------------->
^
| ERLAUBT !!!
---------+
Durch die Vereinigung von Verbindungen kann es zu
zirkulären Referenzen kommen:
+----------------+
| | VERBOTEN !!!
v |
--------------------+----->
Beim Wiedereintreten in der gleichen Richung tritt
keine zirkuläre Referenz auf:
+----------------+
| | ERLAUBT !!!
| V
---+---------------------->
Dies ist zum Beispiel sinnvoll, wenn an den
verzweigten Linien-Teilen unterschiedliche
Texte stehen (verschiedene Events erlauben
die Umschaltung zum gleichen Status).
Text einer Verbindung (FlowConnectionText)
------------------------------------------
Die Texte einer Verbindung müssen auf der
Verbindung liegen.
Texte neben einer Verbindung/Linie können
nicht verarbeitet werden.
Es gibt horizontale Texte
---horizontal---
--- horizontal_mit_Leerzeichen ---
und vertikale Texte
|
|
vertikal
|
|
|
|
vertikal_mit_Leerzeichen
|
|
Es ist nicht möglich, in einem Text die Richtung der Verbindungs-
Linie zu wechseln.
In einem Text darf höchstens ein Leerzeichen hintereinander
auftreten. Zwei oder mehrere Leerzeichen hintereinander gelten
als Ende des Textes.
Demzufolge sollten benachbarte Texte durch mindestens zwei
Leerzeiche abgetrennt sein.
Zur Zeit sind nur einzeilige Texte möglich (mehrzeilige Texte nicht).
In vertikalen Texten darf an der Position der Linie kein |-Zeichen
stehen, weil der Text sonst nicht erkannt wird.
In vertikalen Texten abwärts darf an der Position der Linie kein
kleines oder grosses 'V' stehen, weil sonst ein Pfeil erkannt wird.
In vertikalen Texten aufwärts darf an der Position der Linie kein
'^'-Zeichen oder grosses 'A' stehen, weil sonst ein Pfeil erkannt wird.
Abhilfe schafft das Einfügen einer Leerzeile:
falsch richtig
| |
| |
EDV-Anlage
| EDV-Anlage
|
|
|
In horizontalen Texten sollte nur ein einzelner Bindestrich ohne
ein zusammenhängendes Plus-Zeichen (Erkennung Kurve) oder Pfeil-
Zeichen (Erkennung Join oder Node) verwendet werden.
falsch richtig
--A-+B- -- A- +B -
-->max-- -- >max --
Achtung: Im Stand vom 30.09.2006 klappt obere verbotene Schreibweise
doch, könnte aber mit der Unterstützung mehrzeiliger Texte
wegfallen.
Eventuell stelle ich später eine Option bereit, die nach einem
horizontalen Text mindestens eine bestimmte Anzahl Bindestriche
erfordert.
Nach dem Parsen werden alle FlowConnectionCrossing der gekreuzten
Verbindung zugeordnet, als Schutz gegen evtl. wie eine Kreuzung
aussehende Texte (-|-).
Nicht zugeordnete Kreuzungen werden noch mal als Texte
geparst.
Das Eintreten eines Join-Pfeiles in einen horizontalen Text klappt
mit der aktuellen Version (16.09.2006), kann aber mit der Einführung
mehrzeiliger Texte nicht mehr möglich sein. Deshalb sollte diese
Möglichkeit lieber nicht benutzt werden.
Noch nicht fertig:
------------------
flow_err_15.txt: unconnected node FlowNode nodeText: A rowLeftTop: 0 colLeftTop: 1 rowRightBottom: 4 colRightBottom: 19
müsste eigentlich so sein: rowLeftTop: 0 colLeftTop: 0 rowRightBottom: 4 colRightBottom: 20
Knoten-Art Rhombus, Circle, Oval, Gleichheitszeichen oben und unten
| +---+ +---------------------------+
/ \ / \ / \
/ \ / \ / \
/ \ / \ + +
/ \ + Circle + | Oval |
+ Rhombus +<-----+ \ / | |
\ / | \ / + +
\ / | \ / \ /
\ / | +---+ \ /
\ / | +---------------------------+
| |
| |
+-----------+
/-\
|*|
\-/
.-.
|*|
'-'
unterschiedliche Connectoren (ER-Diagramm, Klassen-Diagramm, Sequenz-Diagramm)
Balken für Process(Thread) Split-Join
Eintreten in einen Text mit Pfeil
Richtungspfeil auf einer Verbindungslinie
Normalisieren des Knoten-Text analog zu HTML (alle weissen Zeichen in Space umwandeln, alle mehrfachen Spaces zu einem zusammenfassen)
Code-Beispiel mit String-Array-Konstante
erledigt: Bei Negativ-Test den Fehlertext in check-Files hinterlegen und prüfen, dass auch wirklich der richtige Fehler aufgetreten ist
erledigt: getrennter Negativ-Test nicht geparstes Zeichen und nicht verbundener Knoten
erledigt: Test mit Luft (Leerzeichen/-zeilen davor/dahinter) und eng getrimmt (ohne Leerräume)
erledigt: Doku
Mit der Boolean-Konstanten 'isTestForSpaceAndNoSpace' in der Methode 'testParse' im TestFlowParser kann gesteuert werden, ob der Test mit oder ohne weiten (Spaces) oder engen (trim) Rand erfolgen soll.
Durch den Test mit engen und weitem Rand werden Fehler die nur am Rand auftreten (wie ArrayIndexOutOfBounds) gefunden.
erledigt: Anbindung State-Transition-Engine
erledigt: Erzeugen JSF navigation.xml
erledigt: Aufteilen in Packages de.heinerkuecker.asciiflowparser
Ausgabe Diagramm aus FlowNet, evtl. mit Markierung aktueller State (Sternchen als Rand)
schräge Linien (Slash/Backslash)
Mergen von Diagrammen aus mehreren Seiten, Page-Name zu jeder Positionsangabe dazu (Name ist besser als Nummer), Prüfen auf mehrfache Page-Namen, Angabe der Connectoren
Prüfungen (optional)
-erledigt: Jede Verbindung muss mindestens einen Text haben
-erledigt: Jede Verbindung darf höchstens einen Text haben
-Bezeichner dürfen keine Spaces enthalten
-Bezeichner dürfen keine Punkte enthalten
-Bezeichner müssen als Java-Bezeichner geeignet sein
-erledigt: jeder Knoten muss mindestens eine Verbindung haben
-Anzahl abgehender Verbindungen je Knoten mindestens 1 (ausser End/Stop), höchstens 1, genau 1
-erledigt: Prüfung auf Einmaligkeit (Unique) der Verbindung ( Anfangsknoten -- Verbindungs-Text --> End-Knoten )
-erledigt: Prüfung auf Eindeutigkeit des Zustands-Überganges Anfangsknoten - Verbindungstext - Endknoten (kein Split nach Text an Verbindung erlaubt)
Lies bitte hierzu auch den Thread auf Newsgroup de.comp.lang.java zu diesem Thema. Download der Quelldateien ASCII_ART_FLOW_PARSER.zip
Achtung: Erweiterungen und Fixes stelle ich ohne Historie
und ohne Ankündigung hier bereit. Lizenzbedingungen:
Die Programme, Quelltexte und Dokumentationen können ohne
irgendwelche Bedingungen kostenlos verwendet werden. |