![]() |
Computerorientierte Mathematik |
![]() |
Inhalt ![]()
![]() |
- 7. Programmieraufgabe - Im Internet gibt es hunderte von Datenbanken, auf die wiederum tausende von Nutzern gleichzeitig zugreiffen. Diese Zugriffe k&oe;nnen dabei sowohl lesender als auch schreibender Natur sein. Stellt euch z.B. vor, ihr wollt einen Internet-Dienst einrichten, in dem sich Benutzer registrieren ("Einfügen"), anmelden ("Suchen") bzw. ihren Zugang auflösen ("Löschen") k&oennen. Zur Verwaltung dieser Benutzer-Accounts eignet sich ein AVL-Baum, da die Benutzer-Daten nach dem eindeutigen Schl&ue;ssel "Benutzerkennung" sortiert sind, und der Zugriff auf diese Daten schnell erfolgen soll. Das Problem dabei ist, dass nun ständig mehrere Nutzer gleichzeitig auf den AVL-Baum zugreifen, wobei einige lesen und andere schreiben wollen. Dies führt i.A. zu Konflikten, die dazuführen, dass die AVL-Baum-Eigenschaften nachhaltig zerstört werden, kann aber mit dem bereits vorgestellten Monitor-Konzept verhindert werden. Ihr sollt nun diesen multiplen Zugriff auf einen AVL-Baum
mittels Threads simulieren und den Umgang daraus resultierender
Schwierigkeiten üben.
Dazu wird jeder Nutzer wird durch einen eigenen
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 ein neuer 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. 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 (
Genauso wie ihr Wrapper-Iteratoren bereits kennengelernt habt,
kann man auch Container-Wrapper schreiben, die einen anderen
Container (hier: einen AVL-Baum) enthalten und den Zugriff auf die einzelnen Methoden
neu regeln. Eine geeignete Wrapper-Klasse sollte das Interface
public Iterator find( Object someData ) throws ContainerException { monitor.readLogOn(); Iterator it=null; try{ it = container.find(someData); } catch(ContainerException e){ throw e; } finally{ monitor.readLogOff(); } if (it==null) return null; return new SynchronizedIterator(it, monitor); } Zu beachten ist, dass auch das Anwenden von Iterator-Methoden ein (meist lesender) Zugriff auf den Baum ist, und deshalb ebenfalls synchronisiert werden muss!!! Deshalb ist es sinnvoll, eine Wrapper-Klasse auch für die Iteratoren zu schreiben, die dann wieder neben dem eigentlichen Iterator auch den Monitor kennt. 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 Euer Hauptprogramm soll alle Zugriffe auf den Baum protokollieren.
Die Ausgaben sollen mittels einer 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 | |||||||||||||||||||||||
![]() |
|