Das ATOS-Magazin 2/99
ATOS Programmierpraxis
Moderne Zeiten
Eingangs wurde erklärt, daß man die Komponenten eines Systems einzeln wieder als Systeme auffassen und durch Hineingucken feststellen kann, welche anderen Komponenten wie miteinander verschaltet wurden, um die größeren Komponenten zu realisieren.
Dies wollen wir an dieser Stelle mit dem groben Aufbaubild der Fußballmanager-Simulation einmal tun. Man spricht dabei von einer Änderung der Auflösung des Aufbauplanes, beim Hineinblicken also von einer Auflösungsvergrößerung, und beim distanzierteren Blick dementsprechend von einer Auflösungsverkleinerung:
Dieses zweite Aufbaubild zeigt die gleiche Situation wie Aufbaubild 1. Allerdings wurde hier in die Benutzerschnittstelle hineingeblickt, und nun sieht man neue Komponenten wie etwa Bildschirm, Maus und Tastatur. Es gab demnach eine Auflösungsvergrößerung. Nicht mehr dargestellt ist allerdings der Spielstandspeicher. Er befindet sich hier innerhalb des Simulators. An dieser Stelle gab es also eine Auflösungsverkleinerung, die gemacht wurde, weil der Spielstandspeicher für die Sachverhalte, die mit diesem Aufbaubild verdeutlicht werden sollen, nicht von Bedeutung ist.
In dem Bild ging es vielmehr um die Frage, welche Teile des Fußballmanagers wir selbst entwickeln müssen, und wo wir auf bereits existierende Teile zurückgreifen können.
Vorgabe war, daß letztlich eine Software für TOS-kompatible Rechner entsteht, und in diesem Fall muß die Benutzerschnittstelle gar nicht vollständig von uns gebaut werden. Als Ein- und Ausgabegeräte dienen Bildschirm, Tastatur und Maus, die zudem vom Betriebssystem dieser Rechner bereits angesteuert werden. Unser Fußballmanager muß also nur noch mit dem Betriebssystem kommunizieren, das in diesem Fall bereits viele hilfreiche Funktionen zur Realisierung grafischer Benutzerschnittstellen (engl. GUI: graphical user-interface) zur Verfügung stellt.
Den verbleibenden Aufwand, damit der Simulator sich mit dem Spieler unterhalten kann, übertragen wir einem GUI-Verwalter. Auch hier greift man normalerweise auf bereits fertige Bibliotheken, Rahmenprogramme (engl. Frameworks) und Application-Builder zurück. Beim Einsatz von faceVALUE, einem Application-Builder für GFA-Basic, sähe der sich ergebende Aufbau des GUI-Verwalters wie folgt aus:
Hier blicken wir nun in den GUI-Verwalter aus dem zweiten Aufbaubild hinein, während die Komponenten Bildschirm, Maus, Tastatur und Betriebssystem, die im Kanal zum Spieler verschwunden sind, nicht mehr explizit dargestellt sind.
Wer faceVALUE kennt, weiß, wie damit erstellte Programme aufgebaut sind. Die Steuerung als Hauptprogramm, die Verwaltung von Menüs und Dialogfenstern und - soweit möglich - auch die von anderen Fenstern werden von der faceVALUE-Engine automatisiert übernommen. Als Programmierer muß man sich noch um die RSC-Datei, in der das konkrete Aussehen der Menüs und Dialoge des Programmes beschrieben ist, um eine hier als UI-Verwalter bezeichnete Komponente und natürlich um die eigentliche Verarbeitung kümmern.
Aufgabe des UI-Verwalters ist es, recht abstrakte Eingaben für die Verarbeitungsinstanz (hier also für den Simulator) anzunehmen und ebenso recht abstrakte Ausgaben für diese Instanz zu tätigen. UI-Verwalter und Simulator unterhalten sich in unserem Fall nicht mehr über Mauskoordinaten und Bildschirmpixel, sondern über Mannschaftsaufstellungen und Tabellensituationen. Der UI-Verwalter ist allein dafür zuständig, daß der Benutzer die Tabellensituation übermittelt bekommt und eine Mannschaftsaufstellung wählen kann. Im Normalfall wird er dazu Fenster öffnen, dem Benutzer die relevanten Informationen anzeigen und ihm die Möglichkeit geben, seine Eingaben komfortabel zu tätigen.
Der UI-Verwalter trennt den Simulator also endgültig von dem konkreten Kanal, der als Benutzerschnittstelle dient. So kann man den gleichen Simulator bei Verwendung eines kompatiblen UI-Verwalters jederzeit erneut einsetzen - eine Portierung des Spiels auf andere Trägersysteme (vielleicht Rechner mit den Betriebssystemen MacOS, Windows oder UNiX) wird dadurch erst möglich. Viel wichtiger ist aber noch, daß man beim Entwurf des Simulators nicht mehr über die konkrete Benutzerschnittstelle nachdenken muß, sondern nur noch über das "Wie sag ich's meinem UI-Verwalter?".