OOD-Klassendiagramm

Um das Klassendiagramm zu verfeinern und genauer implementierbar zu machen, wird der objektorientierte Entwurf (OOD) angefertigt. Im OOD-Klassendiagramm werden sämtliche zu implementierenden Klassen, sowie deren Methoden und Variablen aufgeführt. Zusätzlich wird noch die Sichtbarkeit (private,public,protected) zu jeder Variable und Methode hinzugefügt. Im folgenden OOD-Klassendiagramm sind einige Änderungen zur Projektarbeit erkennbar:

Die statische Klasse Mathe, die alle benötigten mathematischen Methoden enthält, ist zusätzlich hinzugekommen.
Die Klassen Streckenzug und Controller, die diese Mathe Klasse in Anspruch nehmen, sind durch die Rolle "verwendet" an deren Assoziation gekennzeichnet.
Im GUI-Bereich ist der „set-Background“-Dialog hinzugekommen. Dieser Dialog bearbeitet das Einfügen einer Hintergrund-Grafik, und realisiert die hierfür benötigten Methoden.
Die wichtigste Änderung ist allerdings die Kardinalität an der Klasse Streckenzug. Hier wurde wie eben schon angedeutet, die Kardinalität von 1 auf 1..2 erhöht, um zwei Streckenzüge zu verwalten. Dies ist dadurch begründet, dass mit dem Abrunden der Kontur zwei verschiedene Streckenzüge benötigt werden. Zum einen bleibt die „normale“ Kontur, also die Lineare-Verbindung der Punkte bestehen, um zum Beispiel beim Export verwendet zu werden. Zum anderen wird die abgerundete Kontur benötigt um bei Bedarf erzeugt und angezeigt zu werden. Ist die abgerundete Kontur ausgeschaltet, wird natürlich nur die „normale“ Kontur verwendet, was durch die Kardinalität 1..2 erkennbar dargestellt ist.

Im OOD-Klassendiagramm wurde eine Drei-Schichten-Architektur eingehalten. Hierbei handelt es sich um ein Entwurfsmodell, bei dem die Klassen in drei Schichten aufgeteilt werden.

IM OOD-Klassendiagramm befinden sich auf der linken Seite die GUI-Klassen, welche für die Benutzeroberfläche verantwortlich sind. In der Mitte des Klassendiagramms ist das Fachkonzept dargestellt, dass bereits bei der Objektorientierten-Analyse entstanden ist und hierbei lediglich noch verfeinert wurde. Die dritte Schicht, die Datenhaltungsschicht, ist auf der rechten Seite dargestellt und realisiert das dauerhafte Speichern des Fachkonzeptes. Außerdem wurde die Klasse Export, welche das erzeugte Objekt in andere Formate speichert, in diese Schicht gelegt.

Da im Diagramm lediglich zwischen nebeneinander liegenden Klassen Assoziationen bestehen, spricht man hier von einer strengen Drei-Schichten-Architektur. Dabei darf lediglich die GUI-Schicht mit dem Fachkonzept und das Fachkonzept mit der Datenhaltungsschicht kommunizieren. Erkennbar ist dies im Diagramm, durch Assoziationen, die lediglich eine gestrichelte Linie, die die Schichten trennen, überschreiten. Durch diese strenge Architektur ist es möglich mit wenig Aufwand zum Beispiel eine andere Datenhaltung, vielleicht eine Datenbank, zu implementieren. Auch eine andere Benutzeroberfläche ist dadurch implementierbar.

Um das Konzept dieser Drei-Schichten-Architektur einzuhalten, wurde das Model-View-Controller Konzept umgesetzt. Der Controller wird dabei als Schnittstelle zwischen den Klassen genutzt. Außerdem ist dem Controller bekannt, welche View`s, also welche anderen Klassen, auf bestimmte Aktionen des Models (Fachkonzeptes), reagieren müssen.

Der Controller beinhaltet zu allen Ereignissen, die ausgelöst werden können, entsprechende Methoden. Mit Hilfe dieser Methoden wird der Controller angewiesen, was dieser bei einem Ereignis „erledigen“ soll. Beispielsweise findet man folgende Methode im Controller wieder: