6.3 Objektorientiertes Design (OOD)

6.3.1Statischer Entwurf

Applikationsserver

Um die Klassen für die Implementierung zu modellieren muss ich wissen, wie das Software-System aufgebaut sein wird. Denn dadurch entscheidet sich, welche Komponenten und Features ich benutzen kann. Beispielsweise kann ich im Applikationsserver JBoss SessionBeans benutzen, im Tomcat kann ich dies nicht. Das Systems modelliere ich in UML mit einem Deployment-Diagramm. Dort wird gezeigt, welche Komponenten in welcher Umgebung installiert und ausgeführt werden. Die Restriktionen waren in der Phase nur bei den Kosten zu finden. Um die Anforderungen an die Hardware möglichst gering zu halten, wähle ich den Tomcat-Applikationsserver und nicht den JBoss, obwohl dieser im Gegensatz zu kommerziellen Applikationsservern wie z.B. Websphere, noch sehr moderate Anforderungen hat. Tomcat läuft schon gut mit 128 MB Arbeitsspeicher, JBoss benötigt bereits für gute Ergebnisse mindestens 256 MB (besser mehr) Arbeitsspeicher, aber Websphere sollte man ohne modernsten Prozessor und 2 GB RAM gar nicht starten.

Persistenz

Als Datenbank habe ich mich für Postgres entschieden, da die Alternative MySQL in den vergangenen Jahren 2004 und 2005 sich immer stärker in die kommerzielle Richtung entwickelt hat und ich eine komplett freie Alternative bevorzuge. Andere kommerzielle Lösungen von Oracle oder Microsoft habe ich auf Grund der Lizenzkosten erst gar nicht in die engere Auswahl genommen. Von den Leistungsmerkmalen her hätte man aber auch genauso gut MySQL können und es ist auch ohne Probleme (und ohne Quellcodeänderungen) möglich, jede andere Datenbank (für die es JDBC-Treiber gibt) zu benutzen, da ich auf die Persistenz Hibernate setze. Die Persistenz-Alternativen des EJB 2.1 Standards CMP (Container Managed Persistenz) bzw. BMP (Bean Managed Persistenz) sowie IBATIS standen zur Auswahl. CMP/BMP werden im nächsten EJB-Standard 3.0 durch einen neuen Standard ersetzt, den Hibernate schon unterstützt und fielen somit weg. Bei IBATIS ist das Problem, dass man durch viele Layer die Applikation für diese Zwecke verkompliziert. Bei Hibernate habe ich nur eine POJO-Schicht (Plain Old Java Object) die über ein automatisch erzeugtes Mapping auf die Datenbank zugreifen. Somit ist die Persistenz-Schicht sehr einfach zu benutzen bzw. zu verstehen, weil der Programmierer mit dem Bruch vom relationalen Bereich (Datenbank) zum objektorientierten Bereich (Software) nichts zu tun hat. Da Hibernate modern, schnell, verbreitet und den zukünftigen EJB-Standard unterstützt habe ich diese Persistenz ausgewählt.

Das Klassendiagramm aus der Analysephase teile ich auf in Persistenz und Anwendung. In der Persistenz erweitere ich die Klassen um Attribute, als Methoden kommen hier nur die Getter und Setter-Methoden zum Einsatz (daher nicht dargestellt), da die Persistenz-Objekte reine Datenobjekte sind. Die Ausnahme sind die Command-Objekte, die das Interface ICommandExecutable implementieren. Jedes Objekt hat genau einen Primärschlüssel, über den es identifiziert werden kann. Die Primärschlüssel-Klassen der zusammengesetzten Primärschlüssel werden als Komposition dargestellt. Bei den Primärschlüsseln sieht man deutlich einen Unterschied zwischen der Objektorientierung und der relationalen Datenbank, denn in der Persistenz muss jedes Objekt einen eindeutigen Schlüssel haben, bei zusammengesetzten durch eine extra Klasse, jedoch bedeutet dies nicht eine extra Tabelle in der Datenbank.

Da die Gebäude (Building) und Einheiten (Unit) sehr ähnlich sind, kann ich diese in einem Objekt (Unit) unterbringen. Es wird in der Applikation über den Unittype identifiziert, ob es sich um ein Gebäude oder eine Einheit handelt. Das Ergebnis ist das Persistenz-Klassendiagramm.

Schnittstellen Auch die Dienste und deren Schnittstellen werden hier schon ausgearbeitet und als Komponenten-Diagramm (nicht abgebildet, vgl. Kapitel 6.4.2). Dazu gehören die Methoden, mit denen der Client auf den Server zugreifen kann. Diese zurückgegebenen Objekte werden über SOAP serialisiert und übertragen.

Client

In dieser ersten Entwurfsphase wird für den Prototypen im Hinblick auf die Gesamtanwendung modelliert. Daher modelliere ich jetzt noch nicht den Client, da dieser auf die Schnittstellen zugreift und damit eine eigene erste Entwurfsphase bekommt. Diese Phase fällt zeitlich mit der zweiten Entwurfsphase des Servers zusammen, damit die erkannten Probleme aus der Risikoanalyse nach dem ersten Prototyptest dort mit einfließen können. Zum Testen des Prototyps wird speziell eine Testapplikation erstellt, die sehr einfach aufgebaut ist.

6.3.2 Dynamischer Entwurf

Um die Rundenberechnung zu modellieren, habe ich die Spielbeschreibung nochmals analysiert und darauf aufbauend die einzelnen Schritte pro Berechnungsdurchlauf herausgearbeitet und in ein Aktivitätsdiagramm umgesetzt. Die Schritte sind Bewegungen, Kampfhandlungen, Bauen/Ressourcen, die jeweils dreimal abgearbeitet werden. Im Aktivitätsdiagramm kann man den kompletten Ablauf im Detail sehen.

Um die Lebenszyklen der Objekte zu entwerfen, habe ich ein Sequenzdiagramm modelliert (nicht abgebildet, vgl. 6.4.2), das diese im Tomcat-Applikationsserver zeigt. Für den ersten Prototypen habe ich den Client noch nicht geplant, um mögliche Doppelarbeit zu vermeiden.

Der Client wird zeitversetzt zum Server entwickelt. Die erste Entwurfsphase des Clients fällt mit der zweiten Phase des Servers zusammen. So ist die Server-Implementierung schon relativ weit fortgeschritten und für den Client kann zügig ein Prototyp erstellt werden.