Computerorientierte Mathematik

In Vorbereitung auf die Socket Implementation eines einfachen Servers sollt Ihr zunächst den Umgang mit Threads und den daraus resultierenden Schwierigkeiten üben. Dazu wollen wir die Benutzung einer gemeinsamen Datenstruktur von verschiedenen Nutzern simulieren. Jeder Nutzer wird durch einen Thread repräsentiert.

Eine Beschreiung von Threads findet Ihr auch nochmal im Java Tutorial von Sun.

Oberfläche

Das Hauptprogramm soll auf Anforderung einen neuen Nutzer erstellen können, das heißt einen neuen Thread. Um die Aktivitäten des imaginären Nutzers simulieren zu können soll er auch ein Fenster (Frame) zugeordnet bekommen, in welches die Aktivitäten eingetragen werden. Alle Nutzer (Threads), die das Hauptprogramm erzeugt, und nur diese, sollen in einer gemeinsamen ThreadGroup enthalten sein. Durch diese Gruppe hat das Hauptprogramm immer einen Überblick über alle aktiven Nutzer, diese sollen auch regelmäßig aktualisiert vom Hauptprogramm angezeigt werden. Dazu eignet sich idealerweise ein Thread.

Das Hauptprogramm soll sich nicht um die Einzelheiten der Threadorganisation eines Nutzers kümmern. Das muss alles in gekapselter Form Aufgabe einer eigenen Klasse sein. Ähnliche Datenstrukturen sollen in der folgenden Aufgabe zu Sockets ebenfalls verwendet werden.

Ein Nutzer, also insbesondere sein Thread, soll sowohl vom Hauptprogramm als auch über sein Fenster ordentlich beendet werden können. Beachtet dazu die Hinweise in der Dokumentation zum Beenden von Threads.

Funktionalität

Das Hauptprogramm soll einen AVL-Baum besitzen, auf den die verschiedenen Nutzer (Threads) Zugriff haben. Es soll sowohl nur lesender als auch schreibender/löschender Zugriff möglich sein. Ihr müsst also ein Konzept entsprechend der Übung entwickeln, mit dem die Zugriffe auf den Baum konsistent organisiert werden. Dazu sollt Ihr Eure AVL-Baum Klasse aus der letzten Programmieraufgabe verwenden. Diese Klasse darf nicht mehr verändert werden! Alle Veränderungen daran müsst Ihr über Vererbung oder andere Konzepte realisieren. Alle öffentlich sichtbaren Methoden und Attribute müssen bezüglich parallelen Zugriffs in Eurer neuen Klasse sicher sein. Einzige Ausnahme ist die Korrektur der Sichtbarkeiten von internen Methoden der alten AVL-Baum Klasse, falls Ihr vergessen habt, diese als private zu deklarieren.

Parallelität

Da die unterschiedlichen Nutzer nur über verschiedene Fenster und somit nur durch einen Nutzer (Euch) realisiert sind, würden direkte Anfragen nicht parallel sondern nur seriell erfolgen. Um Euren neuen AVL-Baum trotzdem testen zu können, soll für jeden Nutzer über sein Fenster eine Liste von Aktionen eingeben werden können (zum Beispiel in einer TextArea), die zu einem vorgegebenen Zeitpunkt abgearbeitet wird. Die Abwicklung der Abarbeitung dieser Aufgaben muss dann der zum Nutzer gehörende Thread übernehmen. Der Startzeitpunkt soll natürlich für alle Nutzer (Threads) der gleiche sein. So beginnen doch alle Nutzer gleichzeitig, Anfragen zu stellen.

Euer Hauptprogramm soll alle Zugriffe auf den Baum protokollieren. Die Ausgaben sollen mittels einer Debug-Option in Eurer neuen AVL-Baum Klasse erzeugt und dann vom Hauptprogramm an entsprechender Stelle ausgegeben werden. Dazu läßt sich sicher eine Pipe und Stream Konstruktion finden, so dass alle println-Befehle nicht auf System.err schreiben, sondern in einen anderen angegebenen Strom, der dann in einer TextArea im Hauptprogramm dargestellt wird. Wir empfehlen aber einen einfacheren Weg über eine Schnittstelle. Statt System.err.println benutzt Ihr eine Methode, nennen wir sie debugPrintln, die von einem Objekt das die Schnittstelle DebugPrinter implementiert bereitgestellt wird. Wurde kein explizites Objekt angegeben, so nehmt Ihr einfach die Klasse selbst (this), die demzufolge auch diese Schnittstelle implementieren muss und vermutlich einfach auf System.err schreibt. Die Schnittstelle DebugPrinter sieht sehr einfach aus:

/** A method for printing out a debug infomation string. 
    @param s string to be printed out
*/
public interface DebugPrinter {
  public void debugPrintln(String s);
}
    

Die Fenster zu den Nutzern sollen natürlich ebenfalls Protokoll über die erfolgreichen oder nicht erfolgreichen Anfragen führen.

Zur Erinnerung

Überlegt Euch wieder als erstes eine saubere Zerlegung des Problems in Klassen und ordnet diesen Aufgaben und die notwendigen Informationen zu. Dazu eignet sich bekanntlich UML (ein white paper dazu). Beim Programmieren überprüft immer wieder an Hand Eures Bildes ob Euer Konzept noch richtig ist oder verändert werden muss. Verändert immer erst dass Konzept, bevor Ihr das Programm dazu schreibt.

Bekanntlich kann man in einem kurzen Programm (Methode) weniger Fehler machen als in einem langen. Ersetzt nicht einen Fehler durch ständiges hinzufügen von weiten Zeilen durch zehn Fehler.

Vergesst die javadoc-Dokumentierung nicht!