ExamMgr Projektseite

Zwischenbericht

Da es eher mühsam ist die Änderungen im CVS zu beobachten und zu verstehen, möchte ich an dieser Stelle eine kurze Übersicht über die bisherige Entwicklung und die Ziele des ExamMgrs präsentieren.

Motivation und Anforderungen

Die Motivationen der Entwicklungen seit Version 0.6 sind vielfältig und haben mit der Veröffentlichung und mit den Anforderungen zu tun, die sich durch die Integration der Applikation in andere Services (wie dem Hochschul Informationssystem, HIS) ergeben haben. Hierzu gehören:

1. Um Fremdentwickler zur Mitarbeit an dem Programm zu motivieren, müssen Erweiterungen einfach und ohne großes Verständnis der Gesamtarchitektur möglich sein. Dies führt zwangsläufig zu einer Plugin- oder Komponentenarchitektur, bei der ein Entwickler nur noch die Funktionalität einer mehr oder weniger einfachen API zu implementieren muss, um das Programm funktional zu erweitern.
2. Verschiedene Nutzer haben verschiedene Vorlieben und Anforderungen. Dies verlangt ein hohes Maß an Rekofigurierbarkeit der Applikation. Vor allem die Funktionalität der Notenberechnung mit seinen Statistiken muss dynamisch und flexibel sein. Auch dies führt zu einer Komponentenarchitektur.
3. Bei den Gesprächen mit HIS ist aufgefallen, dass neben den erweiterten Import- und Exportfunktionen ebenfalls die Forderung relevant ist, dass eventuell der Speicherort der Projektdaten auf zentralen Servern gewünscht ist, anstatt die sensiblen Daten lokal als Datei abzulegen. Dies verlangt die kompette Abstrahierung der Projektzugriffsmechanismen um den Speicherort für die Applikation irrelevant zu machen (siehe ProjectAccess unten).
4. Die Programmstruktur des Hauptprogramms wurde zunehmend komplexer und hatte zu viele ähnliche Methoden, die sich nur in Details unterschieden. Dies erhöhte die Fehleranfälligkeit, da die Zusammenhänge zunehmend verschleiert wurden. Komplexität kann zwar nicht in Luft aufgelöst werden, aber sie kann verteilt werden. Der Datenfluss in der Hauptapplikation wird somit wieder klarer.

Im folgenden sollen die entsprechenden Bereiche der Applikation kurz beleuchtet werden, die auf diese Anforderungen eingehen

Plugin Framework

Das Plugin Framework wurde schon in der Version 0.7 integriert und ermöglicht den plattform und compilerunabhängigen Zugriff auf Plugins, indem es die Methoden für das Laden und Instanzieren der enthaltenen Klassen ermöglicht. Dieses Framework stellt das Fundament fast aller folgenden Erweiterungen dar.

In der aktuellen Version wurde es dahingehend erweitert, dass es die Möglichkeit bietet, auch grafische Objekte (hier als Komponenten bezeichnet) zu erzeugen. Weiterhin bestitzt es jetzt einen Mechanismus, der die in C++ oftmals auftretenden binärinkompatibilität von Plugins und der somit resultierenden Gefahr von Instabilitäten des Gesamtprogramms zu vermeiden. Hierzu gibt es ein Validierungsmechanismus, der momentan sehr stark eingestellt ist und schon bei der Verwendung verschiedener Kompilerversionen das Laden eines Plugins ablehnen wird. In Zukunft wird dies wahrscheinlich deutlich abgeschwächt werden.

Eine weitere Eigenschaft dieses Frameworks ist, dass es alle Plattformeinflüsse komplett vom Entwickler abschirmt und somit das schreiben von Plugins kinderleicht macht.

ProjectAccess

Wie schon erwähnt, ist es notwendig, dass die Art der Speicherung von Projektdaten unabhängig von der Programmlogik wird (Punkt 3 oben). Und somit wurde die Klasse "ProjectAccess" geschrieben, welches genau die hierzu benötigten Abstrahierungen und Services zur Verfügung stellt. Die eigentliche Art der Speicherung (Binär als File oder in einer Datenbank, usw.) wird über ein Backend-Plugin realisiert, welches mittels des Plugin Frameworks verwaltet wird. Diese Plugins defnieren evenfalls, was für Informationen für den Zugriff auf die Projektdaten nötig sind. Dies ist natürlich höchst unterschiedlich, je nachdem ob es sich um einen einfachen Dateizugriff handelt oder um einen Datenbank-Zugriff bei der IP-Adresse, Username und Passwort usw. verlangt werden. Der ExamMgr erkennt diese Unterschiede vollautomatisch und stellt entweder ein einfaches FileDialog für den Zugriff dar, oder ein komplexes Dialogfenster mit einer editierbaren Parameter-Tabelle. Das Backend-Plugin muss hierzu lediglich die benötigten Parameter bekannt machen, alles Weitere geschieht automatisch.

Import/Export

Hier kommen wird zu einem sehr wichtigen Teil der Applikation. Über die Import- und Exportfunktionen wird die Verbindung zur Aussenwelt ermöglicht.

Bisher waren die Funktionen monolithisch im Hauptprogramm integriert. Logischerweise waren die hierzu zuständigen Routinen zum Aufruf der Funktionen zueinander sehr ähnlich, aber nicht so ähnlich, dass eine Funktion für alle Aufrufe ausreichte. Sie unterschieden sich meist in der Anforderung unterschiedlicher Parameter/Dateien. Dies führte zu unnötigen Komplexitäten und somit zur Verschleierung der Programmstruktur.

Dieses Problem wurde ebenfalls über die Verwendung von einer Plugin-API gelöst. Aus Sicht des Hauptprogramms gibt es nur noch die Unterscheidung zwischen Import- oder Export-Plugin. Die Plugins müssen anschliessend selbst über entsprechende Dialoge die notwendigen Parameter anfordern. Somit wird dieser Teil von Komplexität aus dem Hauptprogramm ausgegliedert.

ConfigAccess

Überall im Hauptprogramm und in den Plugins und Komponenten ist die Sicherung von Parametern notwendig. Um dies einfach zu ermöglichen wurde ein generischen Konfigurations-Framework integriert, welches das Abspeichern und Anfordern von Daten ermöglicht, ohne dass der Nutzer sich Gedanken über das "wie" und "wann" der Speicherung machen muss. Diese Daten werden als Qt-Kontainerobjekte übergeben (QString, QMap, QStringList) und über numerische ID's identifiziert. Diese Daten sind Programmübergreifend verfügbar (also auch für die Plugins) und werden vollautomatisch bei der Beendigung der Applikation gespeichert.

Der Zugriff erfolgt über ein Singleton-Pattern. Somit ist sicher gestelllt, dass das die Konfigurationsdaten für alle gleichzeitig sichtbar und aktuell sind.

Sonstiges (Interessante Erweiterungen)

Auch wenn die meisten Veränderungen eher "unter der Haube" erfolgten und dem Benutzer nicht sichtbar sind, so sind doch einige Erweiterungen und Verbesserungen zu verzeichnen:

1. Darstellung der Studentendaten: Während bei der Version 0.6 lediglich die Attribute einsehbar und veränderbar waren, die von dem ExamMgr "verstanden" werden (non-costum data), so können jetzt alle Attribute eingesehen und verändert werden. Diese zusätzlichen Attribute entstehen dann, wenn bei einem Import Attribute existieren, die für die eigentliche Arbeit des Programms gar nicht benötigt werden. Diese Attribute werden trotzdem gespeichert und können beim Export weider ausgegeben werden (z.B. über <CUSTOM="key"> im Template-Export).
   Diese Attribute sind nun im Programm auch sichtbar und können verändert werden.
2. Die Konfigurationen wurden in ein zentrales Fenster zusammengefasst. Dies machte es übersichtlicher und ermöglicht die Integration in das MacOS-X Look-And-Feel (aufruf durch Menü "Programmname->Preferences"). Das Konfigurationsfenster ermöglicht auch die Einsicht in die gespeicherten Einstellungen der ProjectAccess Backends (nur für Backends, die komplexere Parametersätze verwenden), die automatisch angelegt werden. Auch die Veränderung ist dort möglich.

Zukunft und noch einmal ProjectAccess

Das Notenberechungs-Modul ist noch monolithisch. Geplant ist, dass die grafischen Elemente (Tabellen, Statistiken, ...) als Komponenten aus einer Library ausgewählt werden können und der User sich somit seinem eigenen Geschmack oder den eigenen Bedürfnissen folgen kann.

Auch, wenn diese Funktionalität noch nicht in der nächsten Version verwirklicht wird (jetzigen Änderungen sollen bis März stabilisiert und abgeschlossen werden), so sind wenigstens schon einmal die Grundvorraussetzungen getroffen worden:

• Das existierende Plugin-Framework ist bereit, grafische Komponenten zu unterstützen

• Projektaccess ist so implementiert, so dass eine Kopie des Objekts nicht zu einer Verdopplung der internen Strukturen führt (Qt nennt das Shallow Copy). Somit erlaubt eine Kopie eines Projekts immer noch den Zugriff auf das gleiche Projekt.

  Dies ermöglicht eine einfache Art des Kommunikation: Werden von einer Komponente Daten gespeichert, so muss die Änderung über die Funktion "commit()" abgeschlossen werden. Erfolgt dieses, so wird in Zukunft über das Signal "projectChanged()" alle angeschlossenen Komponenten über die Änderungen informiert und können die eigene Visualisierung aktualisieren.

  Alle grafischen Komponenten haben somit die Infrasturktur zur Verfügung, um immer den aktuellen Datensatz darzustellen und sich somit zu synchronisieren.

Da Stabilität der Applikation über neue Funktionen geht, wird diese Erweiterung erst in der übernächsten Version integriert werden.

Abschließend noch ein kleiner Hinweis auf die geplante Integration in das Hochschul Informationssystem:

HIS plant die Verfügbarkeit einer Schnittstelle, an die Applikationen andocken können. Dies wird aber noch auf sich warten lassen, so wird es erstmal bei der Excelbasierten Import/Export Lösung bleiben. Sobald sich hier etwas verbessert, wird es in die folgende Version des ExamMgr's integriert!