6.1 Entscheidungen

Um eine Software zu entwickeln, muss man sich für ein Vorgehensmodell (und Methode), eine Programmiersprache und ein Programmierparadigma entscheiden. Es sind zwar auch Mischungen möglich, diese sollten aber konzeptionell gut begründet sein. Beispielsweise könnte in der einen Komponente C benutzt und andere Komponenten in Java geschrieben werden. Diese sollte man dann aber als zwei verschiedene Projekte betrachten und hätte damit so auch keine Mischung mehr.

6.1.1 Programmierparadigma

Jeder Programmiersprache unterliegt ein bestimmtes Paradigma, auch wenn sie zum Teil mehrere Paradigmen unterstützen. So ist es möglich in Perl oder PHP Objekte zu programmieren, aber es bleibt vom Kern her eine prozedurale Programmiersprache. Die Nachteile der prozeduralen Entwicklung (und damit strukturierte Vorgehensmethode) entstehen durch die Trennung von Daten- und Funktionssicht. Das verlangt eine gewisse Erfahrung, da sehr sauber, detailiert und vorausschauend konzeptioniert werden muss, weshalb dieser Ansatz für Anfänger ungeschickt ist (vgl. ). PHP ist sehr verbreitet und für dynamische Webseiten durchaus eine sehr gute Wahl, doch aus oftmals kommt es vor, dass es sehr schwierig ist, mit PHP ohne viel Erfahrung eine saubere und später wartbare Lösung zu produzieren, da in der Syntax alles erlaubt ist.

Daher habe ich schon im Thema der Diplomarbeit die objektorientierte Programmierung (und damit eine objektorientierte Vorgehensmethode) gewählt, denn hier kann man mit UML durchgängig und konsistent die Applikation modellieren. Kommerzielle UML-Werkzeuge bieten auch die Möglichkeit, Klassen in verschiedenen Programmiersprachen aus den UML-Diagrammen zu erzeugen, so dass dadurch viel lästige Schreibarbeit entfällt. Zur Modellierung ist somit nur ein Werkzeug nötig, mit dem ich von Beginn an alles modellieren kann. Sowohl die dynamischen als auch das statischen Diagramme modellieren.

6.1.2 Architektur

Da das Produkt in der authentischen Situation eine Client/Server-Anwendung ist, gibt es zwei wichtige Konzepte. Da die Verbindung zwischen Client und Server eine Netzwerk-Verbindung ist, fällt es in den Bereich Distributed Systems(5.2.4.b), weshalb ich eine Service orientierte Architektur (SOA) verwende. Damit ist die Wahl des Clients frei und es wäre jeder Client in jeder Programmiersprache möglich, der SOAP (Simple Objekt Applikation Protokoll) unterstützt, da dies der WebService-Standard ist.

Die einzelnen Komponenten (Client und Server) sind dadurch gekennzeichnet, dass eine Mensch-Maschine-Kommunikation stattfindet, daher benutzte ich hier eine Interactive Systems-Architektur (5.2.4.c). Das MVC ist bei Web- und GUI-Anwendungen sehr beliebt. Die genannten Nachteile gegenüber PAC, dass das Modell die Art des Editor besser wissen muss, würde das Projekt durch Abstraktion der GUI erheblich verkomplizieren und damit dem einfachen Lerneffekt entgegen wirken. Daher habe ich mich für das durchaus taugliche und etablierte MVC entschieden und dies durchgängig umgesetzt.

6.1.3 Programmiersprache

Durch die Wahl der Objektorientierung kommt als Programmiersprache nur Java in Betracht, weil .Net-Lizenzen sehr viel Geld kostet und damit für viele Schulen ausscheidet. Damit die Schüler nicht noch eine zweite Programmiersprache lernen müssen, setze ich kein PHP für dynamische Webseiten ein, sondern JSP (Java Server Pages). Die Umstellung auf PHP fällt allerdings sehr leicht und durch die erlangte Methodenkompetenz wird jeder Schüler schnell die passende Dokumentation finden und auf den Standardkonfigurationen der Provider eigene Seiten programmieren.

Aufgrund der Tatsache, dass die Arbeit als Lehrmaterial verwendet wird habe ich darauf verzichtet den Client über ein Web-Framework (z.B. Struts) und JSP-Seiten zu realisieren, sondern ebenfalls eine Java-Applikation geschrieben. Die Administration ist jedoch als JSP umgesetzt, aus den gleichen Gründen ohne Framework. Hier können natürlich Erfahrungen mit Frameworks gemacht werden, wenn die Administration auf ein Framework umgestellt werden soll.

6.1.4 Modell

Da ich schon in der Projektarbeit im 7. Semester sehr schlechte Erfahrungen mit dem reinen Wasserfall-Modell gemacht habe, einerseits weil man erst sehr spät eine lauffähige Version hatte und dadurch die technischen Probleme erst beim Zusammenführen der Komponenten auftauchten, möchte ich dieses Modell nicht noch einmal einsetzen.

Das Spiralmodell ist in diesem Fall allerdings auch nicht besonders sinnvoll, denn durch die Spielbeschreibung (Kapitel 10) liegt schon eine ziemlich konkrete Spezifikation vor. Wie Prof. Dr. Zöller-Greer im Studienheft SEI01 bei der Diskussion des Spiralmodells vorschlägt möchte ich in der Analysephase nach dem Wasserfallmodell vorgehen und danach nach dem Spiralmodell, denn der Vorteil der frühen Prototypen ist in der Praxis sehr wichtig und technische Schwierigkeiten treten bei Zusammenführen der Prototypen der einzelnen Komponenten sehr früh auf.

Wasserfall/Spiralmodell-Adaption auf OO-Vorgehen
Wasserfall/Spiralmodell-Adaption auf OO-Vorgehen

Aufgrund der fehlenden Kunden, die immer wieder die Prototypen testen, kann ich auf eine agile Softwareentwicklung verzichten. Die Schüler hingegen sollten das Extreme Programming (5.2.3.e) insbesondere das Pair-Programming einsetzen, damit zwei Schüler von einander lernen können. So steigt die Lernkurve schneller an und durch wechselnde Paare können die Schüler Wissen schneller aneignen. Außerdem können Prototypen in kurzen Abständen fertig gestellt werden. Schnelle Ergebnisse erhöhen die Motivation und das fördert wiederum die Bereitschaft am Projekt aktiv mitzuwirken. Ein ungewollter positiver Nebeneffekt ist, dass durch das paarweise besetzen der Computer eine geringere Anzahl an Computern nötig ist, was den Schulen sehr entgegenkommt.