Applikationsfassade

Aus THM-Wiki
Wechseln zu: Navigation, Suche

Die Applikationsfassade (oder engl. Application Facade) oder w:de:Anwendungsfassade ist ein zentrales w:de:Analysemuster der Softwaretechnik. Es wurde in Grundzügen bereits unter der Bezeichnung "w:de:Fassade" von der w:de:GoF als w:de:Entwurfsmuster eingeführt und von w:de:Martin Fowler weiterentwickelt.

Zweck der Applikationsfassade ist es, ein komplexes, koheräntes w:de:System über eine Reihe einfacher w:de:Schnittstellen (oder w:de:Methoden) modellhaft darzustellen (und damit die Problemanalyse zu erleichtern) und gleichzeitig eine arbeitsteilige Entwicklung von der Anwendungspräsentation und -logik zu ermöglichen.

Problemstellung

Beim Design komplexer Anwendungssysteme versuchen Anwender und Entwickler von Programmen gemeinsam Modelle der zu entwickelnden Applikation zu entwerfen. Da reale Problemstellungen in der Regel nicht 1:1 in technische Problemstellungen (und damit Lösungen) überführt werden können, wird das Problemfeld meist auf einer abstrakten Ebene analysiert. Doch auch dieser Schritt kann aus der Perspektive des Anwenders und des Entwicklers zu jeweils unterschiedlichen Ergebnissen führen. Der Grund dafür ist, dass Entwickler eine technische Sicht des Problems entwerfen, während Anwender den Zweck des Programms (z.B. Schreiben von Angeboten) als Problemstellung sehen. Die Applikationsfassade nimmt sich dieses Konflikts an und bietet dem Programmanwender eine logische Sicht auf seine Objekte und Methoden. Der Entwickler wiederum kann die technischen Probleme innerhalb der Domäne lösen, ohne die Sicht des Anwenders zu vernachlässigen.

Die Fassade der GoF

Die Fassade der GoF dient als Vorlage für die Implementierung. Sie ist daher der Kategorie Entwurfsmuster zuzuordnen. Sie kommt eher dem technischen Verständnis eines Entwicklers entgegen, was wohl die Motivation für Fowler war, das Muster weiterzuentwickeln.

Eine gute Beschreibung des Fassademusters bietet die englischsprachige Wikipedia im Artikel Facade. Die Fassade vereinfacht oder "verdeckt" für eine zugreifende Schicht (genannt "Client") die Vorgänge in den einzelnen Paketen. Eine Anwendung, die mit einer Fassade maskiert wurde, erscheint durch diese für ihre Nutzer koheränter als die einzelnen Pakete dies getan hätten und reduziert somit die Komplexität der Anwendung.

Die Fassade erreicht dies durch eine Superklasse, deren Methoden die Funktionalitäten der zu verdeckenden Pakete für die zugreifende Schicht zweckgebunden zusammenfasst. Für den Client ist dabei die Funktionsweise der einzelnen Pakete nicht von Bedeutung. Er greift auf die Methoden der Superklasse zu und übergibt oder erhält von ihr Objekte. Die Applikationslogik zwischen den Paketen bleibt ihm jedoch verborgen.

Zur Anwendung kommt das Entwurfsmuster zum Beispiel beim Maskieren von Libraries. Die Fassade verbessert die Lesbarkeit des Codes und dessen Wiederverwendbarkeit. Eine Beispielanwendung ist das Erstellen eines Datums. In der Fassade ruft der Client lediglich die Funktion "erstelleDatum()" auf. Wie genau nun das Datumspaket ein Datum generiert, bleibt dem Client verborgen.

Die Fassade von Martin Fowler

Mit dem Analysemuster "Applikationsfassade" führt Martin Fowler das Modell der GoF auf eine neue Ebene. Die einzelnen Pakete des Entwurfsmusters werden nun als Domäne betrachtet, also als in sich geschlossenes Problemfeld. Die Applikationsfassade bietet ihrem Anwender einen vereinfachten Zugriff auf die Inhalte der Domäne.

Die Objekte der Domäne werden auf einer abstrakten Ebene logisch zu neuen Objekten zusammengefasst. Dieser Schritt nennt sich "denormalisieren". Ein Beispiel ist das Zusammenführen von Tages-, Monats- und Jahreszahlen zu einem Datumsobjekt. Eine View im Anwendungsbereich der Datenbanken stellt eine zur Applikationsfassade analoge Struktur dar.

Zur Darstellung der Applikationsfassade bedient sich Fowler einer Architektur aus 4 Schichten (siehe Abbildung):

  • Das UI framework ist die Präsentationsschicht für den Anwender einer Applikation. Der Anwender kann hier Knöpfe und Eingabefelder bedienen, z.B. über eine Weboberfläche. Dabei handelt es sich um eine reine Darstellungsschicht, die weder Anwendungslogik noch Wissen über Anwendungsobjekte enthält.
  • Die Schicht Presentation ist ein Vermittler zwischen den Schichten Application Facade und UI framework. Sie enthält kein Wissen der Domäne (das erledigt die Application Facade), sondern führt lediglich die Aufbereitung für die Bedienoberfläche durch. Aus Sicht des UI framework ist die Presentation-Schicht ebenfalls eine Fassade, insbesondere, wenn diese auf mehrere Applikationsfassaden zugreift.
  • Die Application Facade hingegen verfügt nicht über das Wissen, die Daten der Domäne für eine bestimmte Bedienoberfläche aufzubereiten und darzustellen. Stattdessen verfügt die Applikationsfassade über domänenspezifisches Wissen, also über die Objekte und Abläufe innerhalb der Domäne.
  • Die Domäne ist das Problemfeld der Anwendung. Sie enthält die gesamte Applikationslogik.

Zusätzlich zur Presentation- Schicht greift das Paket Testing ebenfalls auf die Applikationsfassade zu. Das Testpaket stellt dabei keine separate Schicht dar, sondern ist ebenfalls ein Anwender der Applikationsfassade. Damit kann die Fassade testgetrieben entwickelt werden.

Implementierung

Analog zur Fassade der GoF ist die Konstruktion einer "Superklasse" das zentrale Element der Applikationsfassade. Dabei können (und werden) praktischerweise alle logische zusammengehörigen Fassadenelement in einem Paket zusammengefasst. Die Fassadenklasse enthält Attribute und Methoden, die sich aus Attributen und Methoden der Domäne zu logischen Objekten komponieren.

Ein Beispiel könnte ein Superklassenobjekt namens "Auto" für einen Fahrzeugkonfigurator sein. In der Domäne ist ein Auto aus Reifen, Schrauben, Motoren, etc. aufgebaut. Die Domänenlogik enthält Regeln, z.B. welche Motoren zu welchem Fahrzeugtyp angeboten werden können. Die logische Aggregation aller Komponenten zu einem konfigurierbaren Wagen führt die Applikationsfassade durch. Das Objekt "Auto" wird dann von der Presentation- Schicht aufgenommen und dem UI framework präsentiert. Diese Vorgehensweise ermöglicht unterschiedliche Darstellungen des Fahrzeugkonfigurators für den Kunden, z.B. für verschiedene Markenhomepages eines Automobilkonzerns.

Die Fassade wird üblicherweise folgendermaßen initialisiert:

package carFacade;
import configurations.*;
public class carFacade{
  private car _subject;
  public carFacade (car subject){
    _subject = subject;
  };
}

Das Subjekt

Eine Fassade bezieht sich immer auf ein Objekt der Problemdomäne (im Beispiel ein Auto). Diese Beziehung (oder Referenz) wird durch den Aufruf von private car _subject hergestellt (s.o.)

Retrieval Methoden (Getter)

Als Retrieval Methoden werden üblicherweise die "Getter"- Methoden der Fassade bezeichnet. Sie komponieren die Attribute der Domäne zu einem Objekt auf der Ebene der Superklasse (in unserem Beispiel ein Fahrzeug für den Konfigurator).

Am Beispiel (Fahrzeugkonfigurator) soll hier gezeigt werden, wie die Modellfarbe des Subjekts ermittelt wird.

Class ConfiguratorFacade {
  public String color(); {
    return _subject.colorOf("color").name();
  }
}

Auf die gleiche Weise kann auch eine bestimmte Motorengeneration ermittelt werden, deren Wahl zum Beispiel auch über die Treibstoffart entscheidet. Entsprechend komplex gestaltet sich dann die Retrieval Methode.

Da die Presentation- Schicht meist andere Datentypen erwartet als sie in der Domäne verwendet werden (sie erwartet zum Beispiel keine Mengenangaben vom Typ Quantity sondern einfache ganze Zahlen), verändern sich an dieser Stelle die Datentypen entsprechend.

Die Manipulatoren

Die Manipulator- Methoden verändern die Daten in der Domäne, führen also update Operationen gegen diese aus. Sie sind naturgemäß die komplexesten Operationen der Applikationsfassade.

Beim Verändern der Daten in der Domäne muss die update- Methode sicherstellen, dass die Gesamtkonsistenz der Domänendaten erhalten bleibt. Innerhalb der Domäne können die einzelnen Objekte vielfältige Beziehungen zueinander haben, denen beim Aktualisieren der Daten Rechnung getragen werden muss.

In unserem Beispiel eines Fahrzeugkonfigurators könnten solche Beziehungen zwischen Preisangaben, Modelleigenschaften und Finanzierungsmethoden entstehen, die der Kunde bei seiner Fahrzeugwahl jeweils beeinflusst.

Zur Gruppe der manipulierenden Methoden gehören auch die Validierer (legal values). Sie gewährleisten, dass die Eingabewerte der Daten korrekt sind, die in die Domäne eingebracht werden sollen.

Zusammenfassung der typischen Methoden einer Applikationsfassade

Die folgenden Methoden kommen typischerweise in einer Applikationsfassade zum Einsatz:

Übersicht: Methoden der Anwendungsfassade
Methode OO-Name Funktion
retrieve get Akzessor
update set Manipulator
legal values   Liste zulässiger Werte / Grenzwerte
validation   Validierer
default   Standardwert setzen

Literatur

Weblinks

  • [1] Martin Fowlers Artikel zur Anwendungsfassade
  • [2] Präsentation zu Application Facades (engl.)
  • Beispiel-Implementierung Java-Quellen als Eclipse-Projekt und Dokumentation zur Beispiel-Implementierung