Universität Essen
Institut für Experimentelle Mathematik
Thomas Dreibholz

Design-Modell

Unser Design-Modell

Dokumentation des Design-Models

• Teil 1: Schnittstelle Client/Server
  Der Benutzer wird mit einer Anzahl von Masken konfrontiert. Diese werden als HTML-Forms implementiert sein. Wir unterscheiden zwischen statischen und dynamischen Masken. Der Inhalt statischer Masken bleibt unabhängig von der Benuterinteraktion immer derselbe.Statisch sind z.B. Such- oder Login-Masken. Im Unterschied dazu werden dynamische Masken online generiert. Sie können Suchergebnisse präsentieren, aber auch einfach Status- oder Fehlermeldungen (InfoMaske) an den Benutzer liefern.
  Die Schnittstelle zwischen Client und Server bildet das Servlet (Details dazu folgen noch zu späterem Zeitpunkt).
  Das Servlet empfängt die Anfragen des Benutzers, leitet diese an das System weiter  und sorgt dafür, daß die vom System generierte Antwort zurückgeliefert wird: Die Anfrage (request) wird in einem InputDataManager-Objekt gekapselt, das an das System, welches von diesem Objekt später alle Informationen bzgl. der Benutzeranfrage erhält, weitergegeben wird (s.u.). Die Antwort (dynamisches HTML-Dokument) wird von einem HTMLCreator-Objekt generiert. Dieses Objekt wird ebenfalls vom Servlet erstellt, mit einem Writer "gefüttert" (dieser enthält später den HTML-Code) und an das System weitergegeben, welches später das Erzeugen einer Antwort veranlaßt.
  Das Servlet verwaltet also insbesondere eine Sitzung für (jeden) Client, der einen Request an das System stellt. Auf der Servlet-Ebene wird daher ebenfalls die (zentrale) Prüfung der Zugriffsrechte für eine angeforderte Operation vorgenommen und nur im Erfolgsfalle weiter verzweigt.

  InputDataManager, HTMLCreator und das Servlet selbst implementieren jeweils ein Interface InType, OutType bzw. ServerApplication. Damit wird eine vollständige Unabhängigkeit von den dem Servlet unterlagerten Klassen (die Kontrollobjekte, die in ihrer Gesamtheit das "System" bilden, welches quasi zwischen dem Benutzerrequest und der Datenbank steht) erreicht: Bei einer Abkehr vom Servlet-Konzept müßten lediglich die diese Interfaces implementierenden Klassen angepaßt bzw. neu erstellt werden!
  Eine weitere Design-Entscheidung bzgl. des Wartbarkeitsaspekts ist die Kapselung von request und response in InputDataManager bzw. HTML-Creator. So können z.B. Änderungen des HTML-Layouts an zentraler Stelle vorgenommen werden!

• Teil 2: Verarbeitungsteil
  Wie wird nun von der Servlet-Ebene in das System hinein verzweigt? Unter Nutzung des Command-Patterns wird eine gleichförmige Zugriffsstruktur für alle Operationen aufgebaut: Für jede Operation existiert eine von der abstrakten Oberklasse FormButton abgeleitete "Button"-Klasse. Anhand der Bezeichnung der angeforderten Operation instanziiert das Servlet (via Class.forName(Operation).newInstance() ) dynamisch ein Objekt dieser Klasse. Jedem FormButton ist ("fest verdrahtet") in der nächsten Ebene ein Command zugeordnet (diese Abbildung ist nicht bijektiv, was die Trennung von FormButton und Command rechtfertigt!). Command definiert dabei wiederum eine abstrakte Oberklasse, von der entsprechende Unterklassen für konkrete Commands abgeleitet werden. Die Instanzen dieser Unterklassen instanziieren bei Ausführung (execute() ) des Commands die jeweiligen Kontrollobjekte (für die Operation). Dort erfolgt insbesondere der Zugriff auf den DatenbankKern. Via InputDataReader-Objekt können die benötigten Informationen abgerufen werden. Schließlich werden die Ergebnisse an den HTMLCreator weitergegeben, der den Output generiert.

  Was sind die Vorteile dieser Struktur? Die dynamisch erzeugten FormButtons ersetzen "if"-Kaskaden. Insbesondere wird dadurch leichte Erweiterbarkeit unterstützt. Eine neue Operation erfordert direkt lediglich eine neue von FormButton abgeleitete Klasse sowie ggf. einen neuen Command-Typ und/oder Kontrollobjekt (sofern nicht solche Elemente bereits wiederverwendbar zur Verfügung stehen). Im Servlet selber müssen keine Änderungen vorgenommen werden (Verfügbarkeit). (Ein zusätzlicher Aufwand kann hier noch in der Definition neuer Zugriffsrechte sowie zusätzlicher Methoden für InType und OutType entstehen).

• Teil 3: Datenbank-Interface und Kern
  

Verantwortlich: Kristof Süwer