DOKUMENTNAME:

Design und Softwarearchitektur

Abgrenzung der Implementation der Komponente

Bewertung der OOP und SW-Struktur

 

Durch das Nachvollziehen der Vorgänge während des Ablaufs des XCTL-Steuerprogramms habe ich die für den Themenbereich wichtigen Klassen / Dateien ermittelt. Dabei hat die vollständig objektorientierte Vorgehensweise des ehemaligen Entwicklers und die meist gute Namenswahl der Klassen, Methoden, Attribute und der Dateinamen geholfen. Die hauptsächlich relevanten Dateien sind m_data.cpp und m_data.h sowie auszugsweise die Dateien m_arscan.cpp, m_scan.cpp und zugehörige Headerdatei m_xscan.h.

Tabelle: Übersicht über die das Aufgabengebiet betreffenden Klassen.

Der bearbeitete Quelltext beläuft sich in der aktuellen XCTL-Programmversion auf ca. 4500 LOC, wobei aber für das Verständnis des Codes noch einmal ca. 1500 - 2000 LOC gelesen wurden (wenn auch nicht im Detail). Es zeigt sich, das ca. 90 % des relevanten Codes (fast 100 % des Codes der grafischen Darstellung) in einer Datei gekapselt waren. Natürlich ist das bearbeitete Gebiet streng mit dem Gesamtvorgang der Diffraktometrie / Reflektometrie verzahnt und dies ist auch im Quelltext zu erkennen. Trotzdem ist das Gebiet bzgl. der Quellen gut abgegrenzt, auch wenn man sich oft eine strengere objektorientierte Kapselung von Daten gewünscht hätte. Allgemein kann man die Vermischung von Code bzgl. der Bedienungsoberfläche und der eigentlichen Funktion bemängeln (in den Quelldateien), wobei für die Oberflächenprogrammierung allerdings stets extra Klassen gewählt wurden.

Abbildung: UML-Klassendiagramm der relevanten Klassen im Problembereich "grafische Darstellung der Meßergebnisse".

Von Vererbung wurde bei der Implementation nur in geringem Umfang Gebrauch gemacht, viel stärker sind Aggregationen benutzt worden. Diese starken Zusammenhänge sind aber teilweise unschön, denn es wird z.B. von den Klassen TBitmapSource, TCurveShowParam, TCurveFreeScal und TCurveFreeScalColor direkt auf Attribute der Klasse TPlotData zugegriffen. Das erschwert die Lesbarkeit des Quelltexts und das Verständnis der Funktionalität. Besser wäre die Problematik über Funktionsaufrufe der Klasse TPlotData, die dann die eigenen Attribute setzen, zu lösen. Die Klassen für die Modaldialoge TAquisition, TCurveShowParam und TCurveFreeScal sind von der Klasse TModalDlg abgeleitet, diese Vererbung ist sinnvoll. Weiterhin sind die Klassen TPlotData und TCurveFreeScalColor von der Klasse TMDIWindow abgeleitet, welche die grundlegende Fensterfunktionalität bereit stellt. Die Klasse TPlotData stellt die Oberklasse der Klassen TAreascan und TScan (diese Klassen sind nicht in Abbildung 23 dargestellt) dar, diese Vererbungsstrategie ist gut gewählt.

In diversen Klassen wurden sich ungenügend Gedanken über den Zugriffschutz auf Attribute und Methoden gemacht (z.B. viele friend Deklarationen, public Attribute und Methoden), obwohl es sich hierbei um sensible Daten handelt. Des weiteren wurden kaum Funktionen zum Setzen und Lesen von Attributen implementiert und oftmals direkt auf Attribute zugegriffen. Dies erschwert die Lesbarkeit des Quelltextes erheblich und bildet eine potentielle Fehlerquelle. Der Programmierstil zeugt von einer grundsätzlich durchdachten Vorgehensweise, aber mein bearbeiteter Quelltextteil ist wohl unter Zeitdruck entstanden. Diverse Funktionen sind implementiert, aber noch fehlerbehaftet oder gar nicht funktionsfähig (Totcode) gewesen. Oben genannte Probleme zeugen auch von einer nicht ausgereiften Programmversion. Daß es auch besser geht, zeigt der ehemalige Entwickler in anderen Quelltextpassagen, so ist die Entwicklung der eigens generierten Dialogboxklassen als ausgereift zu bezeichnen. Zu bemängeln ist die Durchmischung von Oberfläche und Funktionalität. Die Klasse TAreaScan erbt von den Klassen TPlotData und TAreaScanParameters. Nun sollte die Klasse TPlotData aber meiner Meinung nach eher die Funktionalität der Oberfläche (Linescan-, Areascan-Fenster) bereitstellen und die Klasse TAreaScanParameters eher die relevanten Daten eines Experiments beinhalten (gleiches gilt auch für die Klassen TPlotData, TScanParameters und TScan). Durch die Mehrfachvererbung ist die genannte Durchmischung gegeben. Durch diese Tatsache wird das Verständnis des Quelltextes nur unnötig erschwert. Besser wäre eine abstrakte Klasse Diffr./Refl.experiment mit je einer Unterklasse zum Linescan und Areascan. Hier könnten alle sensiblen Experimentdaten gehandelt werden. Schwierigkeiten ergaben sich auch noch aus der Tatsache, das zu nachgeladenen archivierten Experimentdaten diverse sensible Werte in den Dialogboxen noch verändert werden konnten, die sich auf die bildnerische Darstellung auswirkten (z.B. der Meßdetektor). Besser wäre beim Nachladen eine stets neue Generierung eines Experimentobjektes, so könnten auch gleichzeitig mehrere archivierte Meßdateien nachgeladen werden. Im Allgemeinen ist die SW-Struktur aber gut durchdacht, nur hätten objektorientierte Konzepte wie Kapselung und Zugriffsschutz besser angewendet werden müssen.