Grapheneditor - Allgemeine Fragen zum Logikdesign

[Semox]

Liebe Community

Ich habe eine Aufgabe aus meinem Informatikstudium, einen Grapheneditor programmiert, der schon die wichtigsten rudimentären Fähigkeiten hat. Man kann ihn im Anhang laden und ausprobieren. Mich hat dieses Projekt schon nur auf Grund des Zeitaufwands, den ich bereits betrieben habe nun ein bißchen gekitzelt, daß Progrämmchen mit mehr Fähigkeiten auszustatten.

Kurze Beschreibung des Programms:
Auf einer graphischen Oberfläche kann man Knotenpunkte setzen, verschieben oder löschen. Dazu gibt ein ein Menü, mit der man die unterschiedlichen Aktionen Aufrufen kann. Außerdem vefügt das Programm die Fähigkeit die im Speicher abgelegten Daten in einer Datei abzulegen. Ziel ist es e-NFA bzw. DFA zu erstellen. Einschließlich der Möglichkeit ECLOSURE Hüllen (ACHTUNG: DOC Datei) zu berechnen bzw. selbst festzulegen. Somit kann man dann am Ende einen NFA in einen DFA umwandeln und den Automaten optimieren.

Nun sieht die Speicherung der Daten so aus, daß die Knotenpunkte in eine ArrayList gespeichert, die wiederum in eine Datei abgelegt wird. Jetzt stellt sich mir die Frage, ob es nicht vielleicht besser ist die Daten in eine Datenbank zu packen. Möglicherweise könnte man dann interessante Operationen damit anstellen.

Eine Operation wäre es zu jedem Knotenpunkt ein bestimmtes Set an Informationen mitzugeben. Beispielsweise müssen Übergänge bei der Umsetzung eines Automaten grafisch dargestellt werden können, inklusive eines Labels mit der Info, was den Übergang auslöst, z.B. wenn eine 1 oder 0 auftritt.

Da schließen sich noch ein Haufen anderer Fragen mit an. Wenn ich die Daten in einer DB ablege, gibt es da etwas was so schön klein und fein ist, wie eine stand-alone MS-Access DB, die man wie in .NET mit an die Software anhängen kann, jedoch das Office Paket nicht als Installationsgrundlage anfordert? Hat man da für Java auch solche Möglichkeiten? Was ich gern vermeiden möchte ist, daß der User dann gefordert ist, MySQL Datenbanken zu erstellen und zu installieren. Die DB soll ja nur für den Betrieb der Software ausgelegt sein. Vielleicht kennt einer von Euch so etwas? Etwas Einfaches und Erpobtes wäre wünschenswert.

Das ist denke ich für den Anfang schon eine Menge an Infos. Ich freue mich auf eine rege Diskussion.

Viele Grüße,
Semo

 

[hartzie]

Also es gibt in Java auch eingebettete Datenbanken wie Derby, H2, SQLite und noch andere. Die erfordern keine extra Installation sondern laufen eingebettet im Programm. Die sind alle relativ klein und fein.
Da ganz du gleich mit Hibernate oder noch einfacher JPA rangehen und ohne SQL-Gefuchtel auskommen. Es erfordert nur ein bisschen einarbeiten.

 

[Ziegenpeter]

Nicht direkt zu deiner Frage, aber ich hätte noch eine Anmerkung für das interne Automatendesign.
Du solltest darüber nachdenken lediglich ein symbolisches Modell des Automaten abzuspeichern und ihn nicht über Klassen zu modellieren. D.h. du kodierst die Zustände und Transitionen in Zahlen und instanziierst dafür nicht immer wieder Klassen. Gerade wenn die Automaten größer werden wird sich das als Vorteil herausstellen. Mein Model-Checker hat damals nämlich schnell schlapp gemacht als ich deinen Ansatz gewählt hab'.

 

[Semox]

@hartzie
Danke. Die Beispiele sind gut und werde ich definitiv ausprobieren. Die Mini-DBs sind prima für ein paar Ideen, die ich umsetzen möchte...

@Ziegenpeter
Warum würde der Model-Checker schlapp machen? Ich verstehe nicht ganz. Die JVM dürfte doch eigentlich ganz gut mit einer sehr großen Anzahl Objekte klar kommen, oder nicht? Millionen Knoten werde ich wohl nicht haben, aber selbst wenn - kann das problematisch sein?

Ich habe mir den Ansatz mit den Instanzen gewählt, weil ich da beliebig viele Informationen anhängen kann und die voneinander getrennt beliebig "benutzen" kann. Aber wenn es einen besseren Ansatz gibt, dann sollte man den wohl auch besser wählen. Ich möchte ja nicht das Rad neu erfinden...

Inwiefern kann ich die Zustände und Übergänge in Zahlen kodieren, ohne dabei den einzelnen Knoten als eine -- wie soll man das sagen... als zusammenhängende Entität zu verlieren? Dann dürften künftige Operationen wie neue Übergänge schaffen, doch viel schwieriger werden? Ich würde gern mehr dazu wissen...

Viele Grüße,
Semo

EDIT: Mir fällt noch ein, wenn man keine Objekte hat, wie kann man die zusammenhängenden Speicherinhalte jemals strukturiert persistieren?