Verfeinerung des bisherigen Modells

Im bisherigen Ansatz sind noch keinerlei Vererbungshierarchien enthalten und die Klassenaufteilung weist auch noch einige grobe Mängel auf. Diese Punkte sollen in einem zweiten Schritt verbessert werden.

Die Klasse Document spiegelt in der bisherigen Form die Sichtweise eines Dokuments als Datei nicht realitätsgemäß wieder. Tatsache ist, daß ein Dokument einen Spezialfall einer Datei darstellt, denn es gibt ja auch Dateien, die keine Dokumente sind. Demnach sollte diese Klasse auch von einer entsprechenden Superklasse abstammen, die die zu Dateien gehörenden Bestandteile der bisherigen Klasse enthält, wie etwa den Dateinamen, oder das Erstellungdatum.

Da die Methoden zum Betrachten und Editieren eines Dokuments, sowie das Testen von Links durch eigene Programme realisiert wird, setzten sie erst auf der Subklasse Document auf, während das Löschen durch das Entfernen einer Datei realisiert wird und daher von File abstammen muß. Die Funktionalität für move kann durch das Erzeugen einer neuen Datei und Löschen der alten erreicht werden. Beim Löschen und Verschieben von Dokumenten, muß die Konsistenz der Link aufrecht erhalten werden, dazu ist es nötig, die in linksFromOthers angegebenen Dokumente zu aktualisieren, oder wenigstens den Verantwortlichen davon in Kenntnis zu setzen, welche Dokumente dies sind.

Ein weiterer Schwachpunkt im bisherigen Entwurf ist der Eintrag von type. In objektorientierten Modellen werden solche Kategorien durch weitere Subklassen wiedergegeben. Dabei kann auch der Titel, der nur bei statischen Dokumenten vorkommt, in die entsprechende Subklasse mitgenommen werden.

Insgesamt ergibt sich damit die Darstellung aus Abbildung :

  

Abbildung: Aufteilung der Dokumentklasse in eine Vererbungshierarchie

23#23

Die meisten Attribute der Serverklasse stammen wie in Kapitel gesehen aus den Konfigurationsdateien. Daher ist es sinnvoll, für diese Dateien eine eigene Klasse, mit genau den von daher stammenden Attributen einzuführen.

Auch weitere der geforderten Angaben stammen aus den Konfigurationsdateien und können ebenfalls in dieser Klasse eingebracht werden (z.B. Lebensdauer eines Prozesses als maxNumber Requests).

  

Abbildung: Auslagerung der Konfigurationsdaten

24#24

Nicht in der Abbildung wiedergegeben ist, daß sich diese Klasse KonfigurationFiles von File abstammt, da es sich ja hier, wie der Name andeutet, ebenfalls um Dateien handelt.

Bei den Clients ist es gewünscht, die autorisierten Benutzer eigens zu Erfassen. Zu diesem Zweck diente in dieser Klasse der authname. Im objektorientierten Sinne ist es wesentlich besserer Stil, dafür eine eigene Subklasse einzuführen, mit eben diesem Namen als Attribut Ebenso wäre, wie in abgebildet, eine zweite Subklasse für nicht autorisierte Benutzer sinnvoll.

  

Abbildung: Die Vererbungshierarchie von ``Client`` zur Klassifizierung autorisierter Clients

25#25

Ähnliches gilt auch für die Fehlerklasse. Hier wird mit einem Attribut errorType zwischen verschiedenen Fehlertypen unterschieden. Eine Vererbungshierarchie ist an dieser Stelle wohl eher angebracht.

Wie bei den Realisierungsmöglichkeiten erläutert, besitzen die genauer kategorisierten Fehler die Gemeinsamkeit, daß dabei ein Dokument nicht korrekt, oder überhauptnicht übertragen wurde. Hier kann man eine weitere Zwischenklasse einführen, die als Attribut genau diesen Namen enthält. Die weiteren Fehler fügen sich anschließend als Subklassen an.

Damit wird aus der vormals primitiven Klasse folgende wesentlich verbesserte Struktur aus Abbildung :

  

Abbildung: Die Klassen der ``Error``-Hierarchie

26#26