BVA-System

Ich habe mit fast jedem Blogeintrag hier eine neue Version vom BVASystem veröffentlicht. Heute möchte ich den Blog allerdings nutzen, um aufzuzeigen was für ein immenser Aufwand an einer Kleinigkeit hängen kann. Diese Kleinigkeit ist die Sortierung der Bildliste.

Ist-Zustand

Aktuell können 4 unterschiedliche Sortierungsreihenfolgen ausgewählt werden: Bildtitel aufsteigend und absteigend und Aufnahmedatum aufsteigend und absteigend. Bei Bildlisten aus der Datenbank funktionieren diese auch so wie gewünscht. Wird dagegen die Bildliste durch die Auswahl eines Verzeichnisses erstellt, so funktioniert die Sortierung nach dem Aufnahmedatum nicht. Der Grund dafür liegt in den nebenläufigen Prozessen des BVASystems.

Die Bildlisten werden generell losgelöst von der Programmoberfläche eingelesen, damit die Oberfläche  während des Einlesevorgangs weiterhin bedienbar bleibt. Bei der Auswahl eines Verzeichnisses dauert dieser Einlesevorgang recht lange, da jedes Bild geöffnet werden muss, um das Thumbnail und die Metadaten auszulesen. Daher habe ich den Einleseprozess in mehrere Stufen geteilt. Im ersten Schritt wird nur bestimmt, welche Dateien sich im gewählten Verzeichnis befinden. Im zweiten Schritt werden die Metainformationen ausgelesen und im dritten Schritt wird das notwendige Thumbnail erstellt. Nun ist es so, das die Sortierung bereits nach dem ersten Schritt durchgeführt wird, da die Bildliste nach diesem Schritt bereits in der Oberfläche angezeigt wird. Allerdings ist hier das Aufnahmedatum der Fotos noch nicht bekannt. Diese wird erst zusammen mit den Metadaten im zweiten Schritt ausgelesen.

Ausweg

Prinzipiell bieten sich 2 Lösungswege an. Der einfachere Weg ist es sicher, die Bildliste erst anzuzeigen nachdem die Metadaten aller Fotos ausgelesen wurden. Dies würde allerdings dazu führen, das das Programm deutlich langsamer wird. Also werde ich den komplizierteren Weg wählen müssen und einen Mechanismus schaffen, der die Sortierung sofort aktualisiert, sofern sich ein Aufnahmedatum geändert hat.

Was muss dafür alles angepasst werden?

Der wichtigste Punkt ist sicherlich, das die Bildliste nun unabhängig von der gewählten Sortierung gespeichert wird. Zusätzlich muss eine Indexliste erstellen werden, die die gewählte Sortierung repräsentiert. Alle Funktionen, über die Zugriff auf ein Listenelement erfolgt, müssen folglich angepasst werden. Wenn beispielsweise das dritte Element der Liste benötigt wird, muss in der Indexliste nachgeschaut werden, an welcher Position in der unsortierten Bildliste sich die gewünschten Daten befinden.

Damit die Indexliste bei einer Änderung des Aufnahmedatums oder Bildtitels angepasst werden kann, muss das Listenelement die Bildliste über Änderungen informieren. Sofern sich dadurch Positionen innerhalb der Bildliste verschieben, muss diese wiederum die Komponenten zur Anzeige informieren. Diese müssen nämlich ebenfalls aktualisiert werden. Zu guter letzt muss ebenfalls der Cache angepasst werden, der die Thumbnails verwaltet.

Insgesamt müssen für die geänderte Sortierung fast alle Kern-Komponenten des BVASystems modifiziert werden. Das folgende Bild soll die Zusammenhänge verdeutlichen.

Schaubild zur Listensortierung

Ausblick

Ich habe für die Änderungen die jetzt bevorstehen, keine weiteren Zwischenversionen der Bildverwaltung geplant. Eine halbfertige Umsetzung, wo Teile der Bildlistenanzeige nicht funktionieren, würde euch nichts bringen. Aktuell bin ich gerade dabei, die Lösung des Sortierungsdilemmas vorzubereiten. Wenn diese Vorbereitung abgeschlossen ist, werde ich nochmals eine  Programmversion veröffentlichen. Anschließend werde ich einige Zeit brauchen um alle Änderungen umzusetzen. Damit die ganze Frickelei nicht ohne neue Funktion bleibt, werde ich im Zuge dessen als drittes Sortierungskriterium die Filterungsübereinstimmung einführen. Dazu später allerdings mehr …

„Keep it simple, stupid“ ist ein Satz, an den ich in den letzten Tagen häufiger denken musste. Er beschreibt ein Designkonzept, bei dem nach der einfachsten und am leichtesten zu verstehenden Lösung gestrebt wird. Auf den Weg dorthin verzettelt man sich aber meistens anständig, indem man Workaround für Workaround programmiert um das Problem vollständig zu lösen. Spätestens wenn man seinen eigenen Quelltext nach recht kurzer Zeit nicht mehr versteht, sollte man über einen alternativen Lösungsweg nachdenken.

Vor einigen Wochen ärgerte ich mich damit herum, das ich es nicht geschafft habe, die Nachbarschaftsbeziehungen der einzelnen Bildinformationspanels korrekt zu halten, wenn der Anwender einzelne Panel ausblendet. Immer wieder gab es einen Sonderfall, bei dem die Nachbarschaftsbeziehungen zerstört wurden. Normalerweise ist es nicht meine Art, aber nach einigen Tagen gab ich entnervt auf und beschloss einen Neuanfang. Ziel ist/war es einen Weg zu finden, der einfach ist, immer funktioniert und wenn möglich frei von Sonderfällen ist. „Keep it simple, stupid“ eben.

Bisher hatte ich versucht, die Nachbarschaftsbeziehungen mit jeder Aktualisierung zu prüfen und gegebenenfalls zu korrigieren. Wenn zwischen dem Panel „A“ und „B“, ein Panel „C“ eingeblendet wurde, so musste „B“ aus den Nachbarschaftsbeziehungen von „A“ entfernt und „C“ hinzugefügt werden. Bei „B“ musste der Nachbar „A“ entfernt und der Nachbar „C“ hinzugefügt werden. Bei „C“ ist es am einfachsten, denn da musste nur „A“und „B“ als Nachbar hinzugefügt werden. Hört sich einfach an, aber leider ist dies auch der einfachste Fall. Zum Beispiel habe ich die Nachbarn, die ober- und unterhalb von „A“ und „B“ liegen könnten in dem Beispiel gar nicht berücksichtigt. 

Debugdialog der Bildinformationspanel

In der neuen Version des BVASystems bin ich meinem Ziel, eine einfache Lösung zu implementieren, nun einen großen Schritt nähergekommen. Den neuen Ansatz habe ich zum Testen in der Debug-Ansicht der Bildinformationspanels integriert. Ihr könnt diese Debug-Ansicht öffnen, in dem ihr auf das BVASystem-Icon in der Überschrift eines Bildinformationpanels klickt. Dort können  alle Nachbarschaftsbeziehungen neu bestimmt werden. Insgesamt gesehen ist der Aufwand natürlich größer, aber da im BVASystem aktuell nur 8 Panel benutzt werden können, hält sich der zeitliche Verlust in Grenzen. Auf meinem Entwicklungsrechner dauerte eine komplette Neubestimmung nur 0,03 ms. In den nächsten Tagen habe ich nun vor, die bestehende Lösung zu ersetzen, damit ich überprüfen kann, ob die neue Lösung wirklich immer funktioniert.

Nach der Installation der letzten Entwicklerversion ist euch vielleicht aufgefallen, das sich ein drittes Programm namens „BVATest.exe“ in dem Setup befunden hat. Mit dem Programm möchte ich immer wiederkehrende Tests des BVASystems automatisieren und mir damit langfristig eine Menge Arbeit ersparen. Außerdem hoffe ich, das durch die systematische Herangehensweise eventuelle Fehler nicht so häufig übersehen werden. Damit ihr die durchgeführten Tests nachvollziehen und eventuell eigene Tests durchführen könnt, habe ich mich entschlossen die Testanwendung in die Entwicklerversionen zu integrieren. Stabile Softwareversionen werden die Testanwendung dagegen nicht enthalten.

Was sind automatisierte Tests?

Beim Testen einer Software überprüft man, ob das Programm den Anforderungen entspricht. Dabei ist es notwendig, das die komplette Prüfung mit jedem Versionssprung erneut durchgeführt wird. Es ist nämlich möglich, das eine einzige geänderte Codezeile Auswirkungen auf längst abgeschlossene Funktionen hat. Durch eine automatisierte Testung erreicht man, das der Aufwand zur Testung stark reduziert wird. Außerdem wird verhindert, das man durch eine unsystematische Herangehensweise Testfälle vergisst.

Auch kann durch eine automatisierte Testung die Qualität einer Software beurteilt werden.  Je mehr Anforderungen erfolgreich erfüllt werden, desto qualitativ hochwertiger ist die Software. Mit Hilfe einer automatisierten Testung kann also festgestellt werden, ob die alte Version X oder die neue Version Y besser zu den Anforderungen passt.

Der größte Vorteil einer automatisierten Testung ist ganz klar der Geschwindigkeitsvorteil der sich bei der Entwicklung ergibt. Außerdem ist es für den Entwickler einfacher, Änderungen am Programmcode vorzunehmen, da die Auswirkungen jederzeit schnell überprüft werden können.

Nachteil einer automatisierten Testung ist natürlich, das die Tests selber wiederum Fehler enthalten können. Zum Beispiel kann bei der Definition der Tests eine wichtige Anforderung übersehen werden. Wird allerdings so ein Fehler gefunden, so kann durch die Anpassung der automatisierten Testung sichergestellt werden, das dieser Fehler kein zweites mal übersehen wird.

Geplante Funktionsweise

Das Testprogramm „BVATest“ soll mit XML basierten Projektdateien arbeiten. In diesen Projektdateien können beliebig viele Testaufgaben definiert werden. Bei der Definition einer Aufgabe müssen alle zu nutzenden Parameter festgelegt werden. Außerdem sollen Abhängigkeiten definiert werden können. Zum Beispiel muss zum Test der Funktion „Datenbankbild löschen“ zuerst ein Bild in der Datenbank gespeichert werden.

Alle definierten Tests werden nach dem Start der Testung nacheinander abgearbeitet. Rückgabewerte werden in einem gesonderten Teil der Oberfläche dargestellt und außerdem werden sie mit erwarteten Rückgabewerten verglichen. Treten Unterschiede auf, so werden diese deutlich hervorgehoben.

Vorläufiges Entwicklungsziel

Mein vorläufiges Entwicklungsziel ist es, das durch das Testprogramm alle Worker-Aufgaben automatisiert getestet werden können. Dadurch, das die Aufgaben komplett von der Oberfläche losgelöst sind, bieten sie sich regelrecht zur automatisierten Testung an. Außerdem bilden sie einen wichtigen Bestandteil der Bilddatenbank. Was nützt es, wenn ich viele tolle Funktionen habe, aber gerade beim Hinzufügen eines neuen Fotos einen Fehler übersehe.

Mit der letzten Programmveröffentlichung hatte ich es bereits angemerkt, das ich wohl zu einer neueren Version meiner Entwicklungsumgebung umsteigen werde. Vor Weihnachten habe ich mir dann ein großes Geschenk gemacht und das neue Embarcadero Rad Studio XE2 bestellt. Vorgestern wurde es dann geliefert und ich habe es natürlich sogleich installiert. Nach einer problemlosen Installation war meine Neugier groß, wie die Konvertierung des BVASystem Projektes zur neuen Entwicklungsumgebung verlaufen wird.

Mittlerweile kann ich einen groben Überblick geben, was mich/euch erwartet. Die gute Nachricht: Das Programm lässt sich wieder übersetzen und es ist auf dem ersten Blick auch voll lauffähig. Die Schlechte Nachricht: Es gibt auch einige Baustellen (meist optischer Natur), die wohl relativ schnell abgearbeitet werden müssen.

Was wird sich in naher Zukunft ändern?

Im alten Delphi 2005 waren alle Steuerelemente nicht Unicode fähig. Spezielle Sonderzeichen, die nicht darstellbar waren, wurden einfach durch ein Fragezeichen ersetzt. Im Alltag ist dies sicher nicht weiter dramatisch gewesen, da man sich meist mit Alternativen behelfen konnte. Ich war dieses Jahr beispielsweise in Årgab im Urlaub und dieser Name konnte bisher nicht im BVASystem verwendet werden. Stattdessen hab ich einfach Argab beim Verwalten meiner Bilder genutzt, um dem Problem aus dem Weg zu gehen. Das Rad Studio XE2 arbeit nun komplett mit Unicode Zeichenketten.

In diesem Zusammenhang  zerbrech ich mir gerade ein wenig den Kopf, ob alle anderen Zeichenketten im Programm nun noch korrekt sind. Ich weiß gerade nichteinmal, ob die MYSQL-Datenbank so erzeugt wurde, das sie Unicode unterstützt. Ich werde die nächsten Tage wohl testen müssen, ob ein Fotoalbum „Årgab“ nun möglich ist oder ob Korrekturbedarf besteht. Gestern abend stolperte ich jedenfalls gleich in eine Unicode-Falle. Bisher habe ich recht gerne Zeichenketten bzw Stringstreams genutzt um binäre Daten zu verändern. Nun geht das nicht mehr so einfach, da ein falsch eingestelltes Encoding die Binärdaten zerstört.

Eine wunderschöne Neuerung sind die VCL-Styles. Sie ermöglichen es, das das Aussehen der Programmoberfläche komplett selbst gestaltet werden kann. Bisher habe ich mich damit herrumgequält, das die Anwendung meinen optischen Wünschen genügt. Bisher konnte ich kein XPManifest benutzen, da meine dezent braune Oberfläche durch blaue Scrollbars zerstört wurde. Daher sahen die Scrollbars im BVASystem bisher noch so aus, wie sie zur guten alten Windows95 Zeit ausgesehen haben. Im Rad Studio XE2 ist nun standardmäßig ein moderner Look aktiv. Er kann aber mit einem selbsterstellten VCL-Style überschrieben werden. Da ich immernoch keine blauen Scrollbars möchte, werde ich dies wohl auch tun müssen. Erste Versuche brachten folgendes:

Oberflächenentwurf mit eigenem VCL-Stil

Neu ist auch der 64bit Compiler. Kleinere Testanwendungen habe ich bereits als 32bit und als 64bit Variante übersetzen können. Ob ich das BVASystem ebendso einfach auf 64bit bringen kann, weiß ich noch nicht. Die Datenbankverbindung, die zur Zeit über die „libmySQL50.dll“ realisiert wird, muss ja ebendso durch eine 64bit Variante ersetzt werden. Ich würde es jedenfalls schön finden, wenn ich irgendwann einmal eine 64bit Version vom BVASystem anbieten kann. Aktuell ist dies allerdings noch nicht so wichtig.

Fazit

Im großen und ganzen bin ich mit dem Umstieg zufrieden. Die Entwicklungsumgebung wirkt vertraut, die Eingewöhnung wird also nicht all zuviel Zeit benötigen. Das BVASystem ist übersetzbar und läuft bis auf ein paar optische Unschönheiten auch. Insgesamt verspreche ich mir durch das modernere Erscheinungsbild der Software deutliche Vorteile. Allerdings muss ich dafür erst einmal die Konvertierung des Projektes abschließen.

Im Ausblick bei der letzten Programmaktualisierung habe ich beschrieben, das ich auf der Suche nach einer sinnvollen Datenstruktur bin, um die Zuordnungen zwischen Fotos und Fotoalben effizient erstellen zu können. Entschieden habe ich mich für einen Entscheidungsbaum. Bevor ich in 1 bis 2 Wochen die Version 2.0.0.24 veröffentliche, die eine Implementierung eines Entscheidungsbaumes enthält, möchte ich kurz erklären, was ein Entscheidungsbaum ist und worin ich die Vor- bzw. Nachteile sehe.

Was ist ein Entscheidungsbaum?

In der Informatik stellen Entscheidungsbäume eine Möglichkeit dar, mit der automatische Klassifizierungen vorgenommen werden können. Um eine Klassifizierung vornehmen zu können, wird der Entscheidungsprozess durch mehrere formale Regeln beschrieben. Diese formalen Regeln werden hierarchisch angeordnet. Ein simpler Entscheidungsbaum könnte wie folgt aussehen:

Ein einfacher Entscheidungsbaum

Zur Klassifizierung wird beim Wurzelelement begonnen, die formale Regel zu beantworten. Anschließend wird beim passenden Kindknoten des Baumes fortgefahren. Es wird wieder die formale Regel abgearbeitet und anschließend wieder der Kindknoten untersucht. Der Prozess endet, sobald der Baum keine weiteren Kindknoten enthält.

Möchte ich, nach dem obigen Beispiel, einen roten runden Ball in eines der Fächer einordnen, dann gehe ich wie folgt vor: Als erstes schaue ich, ob der Ball rot oder gelb ist. Da der Ball rot ist, muss ich auf der linken Hälfte des Baumes weitersuchen. Der rechte Teil des Baumes muss nicht weiter betrachtet werden. Anschließend schaue ich mir die Form des Balls an: Er ist rund und somit ist wieder der linke Teil des Baumes der gesuchte Teil. Da die unterste Ebene des Baumes erreicht wurde, ist nun bekannt, das der Ball in das Fach1 gehört.

Welche Vorteile hat ein Entscheidungsbaum?

Der größte Vorteil eines Entscheidungsbaumes ist, das der Anwender durch die formalen Regeln  relativ gut nachvollziehen kann, warum eine Entscheidung so getroffen wurde, wie sie getroffen wurde. Treten falsche Klassifizierungen auf, so kann der Anwender problemlos durch Anpassung der formalen Regeln, korrigierend eingreifen. Bei alternativen Ansätzen, zum Beispiel neuralen Netzen, ist es für den Anwender absolut unmöglich eine Klassifizierung nachzuvollziehen.

Auch der Aufwand, der zur Klassifikation eines Elementes benötigt wird, wird reduziert. Ohne Entscheidungsbaum würde man für jedes mögliche Klassifikationsergebnis testen, ob die Bedingungen erfüllt sind. Schauen wir wieder auf das Beispiel, so müssten für die Fächer 1 bis 4 jeweils 2 Vergleiche, insgesamt also 8, durchgeführt werden. Mit Entscheidungsbaum fallen mit jeder Hierarchiestufe eine Anzahl nicht möglicher Klassifikationsergebnisse weg. Beim Beispiel bleiben somit nur 2 Vergleiche übrig um das richige Fach zu finden. 

Welche Nachteile hat ein Entscheidungsbaum?

Ein Nachteil eines Entscheidungsbaumes ist, das er nur für abzählbare Datentypen anwendbar ist. Wählt man beispielsweise die Länge eines Objektes als Kriterium, so kann es vorkommen, das für jedes Objekt ein neuer Knoten eingefügt wird. Der Grund dafür ist, das jedes Objekt eine leicht andere Länge aufweisen kann: Eines ist 2,5cm lang, das nächste, 2,49cm und das übernächste 2,495, usw. Entgegen wirken kann man dem, indem die Länge nur gerundet in die Bewertung eingeht. Durch die Rundung kann sich allerdings das Klassifikationsergebnis leicht verschlechtern, da möglicherweise Elemente einem falschen Knoten zugeordnet werden.

Ein weiterer Nachteil ist, das der Baum sehr schnell in die Breite wachsen kann, wenn eine Eigenschaft sehr viele verschiedene Ausprägungen besitzt. Je breiter der Entscheidungsbaum wird, desto mehr büßt man von dem eingesparten Aufwand zur Entscheidungsfindung ein. Tritt so ein Fall ein, so ist es ratsam, den Baum so umzuformen, das eine weitere Ebene entsteht.

Fazit

Für mich scheinen Entscheidungsbäume genau der richtige Weg zu sein, um die Zuordnungen zwischen Foto und Fotoalbum effizient treffen zu können. Allerdings sehe ich schon noch Schwierigkeiten darin, wie er sinnvoll aufgebaut werden sollte. Bereits bei dem Metadatentyp „Aufnahmedatum“ habe ich die Befürchtung, das der Baum zu sehr in die Breite wächst. Vorteilhaft ist aber, das der Entscheidungsbaum nur temporär entstellt wird. Daher kann ich die Struktur des Baumes ohne Probleme aktualisieren, wenn die alte Struktur sich als ineffizent herrausstellen sollte.

Heute möchte ich die Gelegenheit nutzen, um die Frage zu beantworten, warum ich beim BVASystem auf ein Client-Server-Datenbankmodell gesetzt habe. Bevor ich jetzt aber groß in die Vor- und Nachteile einer Client-Server-Architektur einsteige, möchte ich kurz erklären, was das eigentlich ist.

Was ist ein Client-Server-System?

Wie der Name es sagt, besteht ein Client-Server-System aus 2 Komponenten, dem Client und dem Server. Bei beiden handelt es sich um eigenständige Programme, die in der Regel auf unterschiedlichen Rechnern in einem Netzwerk laufen. Es ist aber auch möglich, das Server und Client auf nur einem Rechner laufen. Der Server hat in der Regel keine eigene Oberfläche. Seine Aufgabe ist es, dem Client bestimmte Funktionen zur Verfügung zu stellen. Der Client ist das Programm, welches der Anwender gut kennen sollte. Der Client nutzt die Funktionen, die der Server zur Verfügung stellt und zeigt die Resultate dieser Funktionen dem Anwender an.

Beim BVASystem ist der Server ein Datenbankmanagementsystem, wie zum Beispiel das während der Entwicklung genutzte  MySQL.  Der Server hat hier die Aufgabe, die Fotos, die der Client dem Server übermittelt, zu speichern und zu einem späteren Zeitpunkt dem Nutzer wieder anzuzeigen. Eigentlich sollte es jetzt bereits klar sein, der Client ist in dem System das Programm, welches ich gerade programmiere.

Welche Vorteile und Nachteile hat ein Client-Server-System?

Für mich ist der größte Vorteil, das ich meine Fotos nur auf einem Server speichern muss. Ich bin im Besitz von mehreren Computern, die ich hier in einem Heimnetzwerk miteinander verbunden habe. Zum einen habe ich einen Standrechner, auf dem ich hier gerade diesen Text schreibe und zum zweiten habe ich einen Notebook, der mich begleitet, wenn ich mal unterwegs bin. Auf dem Standrechner habe ich den MySQL-Server installiert. Sowohl auf Standrechner, als auch auf dem Notebook habe das BVASystem installiert und so eingerichtet, das beide Rechner auf das Serverprogramm des Standrechners zugreifen können.

Ein Nachteil ist es, das auch, wenn man nur von einem Rechner aus seine Fotos verwalten will, man den Datenbankserver installieren muss. Gerade für Nutzer, die nicht so technikaffin sind, könnte es zu Schwierigkeiten in der Administration des Servers kommen. Auch ich hatte schon so meine Schwierigkeiten mit dem MySQL-Server: Server has gone away Weiterhin kann es von Nachteil sein, wenn man mit mehreren Clients auf die Fotos zugreifen will und dafür extra einen Rechner bereitstellen muss auf dem nur der Server läuft.

Ein weiterer Vorteil, für mich als Entwickler ist, das ich mit dem Client-Server-Modell auf standardisierte Server-Komponenten zurückgreifen kann. Damit lässt sich wunderbar, das von mir bereits beschriebene Schichtenmodell umsetzten. Ich muss also weniger Aufwand in die Entwicklung des Systems stecken. Aber auch für den Anwender hat dies einen Vorteil. Wenn ich morgen, aus welchem Grund auch immer, das BVASystem nicht mehr weiterentwickeln würde, dann könnte der Anwender weiterhin mit Service-Programmen, die mit dem Server ausgeliefert werden, auf seine Daten zugreifen und sie in eine Struktur überführen, die andere Programme lesen können.

Als nachteilig empfinde ich es, das die Bilder, die ich in der Datenbank gespeichert habe, nicht so ohne weiteres Bearbeiten kann. Wenn ich von mehreren Rechnern auf die Bilder zugreifen will, so muss ich diese direkt in der Datenbank abspeichern. Zur Bearbeitung muss ich die Bilder also erst aus der Datenbank extrahieren und anschließend wieder neu abspeichern. Um diesen Nachteil auszugleichen, hatte ich damals vor, das BVASystem mit Bildbearbeitungsfunktionen auszustatten. Mittlerweile bin ich davon aber weg gekommen, da dies den Rahmen eines Hobbyprojektes bei weitem sprengen würde.

Seit nun knapp einen Monat bin ich am werkeln, damit die nötigen Baumstrukturen für die Verzeichnisse bzw. für die Datenbankrubriken aus einer extra Datenschicht kommen. Aber warum betreibe ich den Aufwand? Warum habe ich den bereits fertigen Baum mit den Verzeichnissen nicht einfach behalten? Und warum habe ich nicht einfach schnell einen zweiten Baum, nach gleichem Vorbild, für die Datenbankfunktionalität geschrieben?

Die Struktur, die ich für die Bilddatenbank BVASystem gewählt habe, ist in der Informatik als 3-Schichten-Achitektur bzw. als 3-Schichten-Modell bekannt. Sie hat den entscheidenden Vorteil, das durch die Aufteilung in Schichten, die Komplexität des Gesamtprogrammes abnimmt. Zum einen wird es damit einfacher das System zu erweitern und ebenfalls wird es dadurch für mich einfacher, wenn ich zu einem späteren Zeitpunkt auf den Quelltext der Bildverwaltung schauen muss, um einen Fehler zu beheben. Außerdem kann ich relativ einfach eine veränderte oder komplett neue Oberfläche für die Datenbank designen, da ich dafür nur die Anwendungsschicht neu gestalten muss.

3-Schichten-Modell des BVASystems

Eine Besonderheit beim BVASystem ist, das die Datenschicht aus einer abstrakten Datenschicht und 2 Präzisierungen besteht. Dadurch kann ich die Oberfläche, sowohl für die Dateiansicht, als auch für die Datenbankansicht verwenden. Das Ergebnis ist, das sich die Komplexität der Oberfläche bzw. die der Datenschicht-Präzisierungen wiederrum reduziert.

Fazit: Es lohnt sich also sehr wohl, etwas mehr Zeit in saubere Strukturen zu investieren.

Vor knapp einen Monat hat sich ein Freund von mir bereit erklärt meine Bilddatenbank zu testen. Für mich eine sehr schöne Sache, da so frühzeitig Fehler entdeckt und behoben werden können. Seine Bedingung dafür war allerdings, das ich ein Bugtracker System einrichte. Da er Mantis bereits für eigenen Projekte nutzt, sprach er da seine Empfehlung aus.

Anfangs war ich nicht so recht begeistert. Bisher war ich eher der Typ der versucht, alles durch ein organisiertes Chaos zu erledigen. Ich scheute den Aufwand, den der Betrieb des Systems mit sich bringen würde. Ich ließ mich trotzdem dazu überreden :-D

Nach nun knapp einem Monat später möchte ich nun ein Zwischenfazit ziehen. Anfangs habe ich das System eher zögerlich verwendet. Nachdem ich allerdings verstand, wie man in dem Bugtracker unterschiedliche Programmversionen definiert und wie man Fehler/Featurewünsche den Versionen zuweist, änderte sich mein Verhalten grundlegend. Ich sah die automatisch generierte Änderungsliste und die ebenfalls automatisch erstellte Roadmap. Ersteres erspart mir eine Menge Zeit, da ich meinem Freund nicht erklären brauchte was ich geänderte habe. Und die Roadmap hilft mir, mein weiteres Vorgehen zu planen.  Während der Entwicklung des ersten BVASystems hatte ich so eine Roadmap nicht. Und es kam wie es kommen musste: Ich verrannte mich oft in Sachen, die niemals fertig gestellt wurden. Ich hoffe das dies durch Mantis nun nicht passiert.

Danke Fake.