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. |