Anwendungsfassade

Die Anwendungsfassade (englisch Application Facade) ist ein Analysemuster aus der Softwaretechnik von Martin Fowler, welches die Organisation von Schichtenarchitekturen verbessert. Das Grundprinzip ähnelt dem des Entwurfsmusters „Fassade“ der GoF. Beide Muster vereinfachen die Nutzung eines komplexen Subsystems durch den Zugriff über eine spezielle Schnittstelle.

Prinzip der GoF-Fassade

Schichtenarchitektur

Der Einsatz der Anwendungsfassade setzt eine Aufteilung der Anwendung in mehrere Schichten voraus (Multi-Tier-Architektur):

• Datenquellschicht
• Domänenschicht
• Anwendung
  • Anwendungslogik
  • Präsentationsschicht

Typischerweise kann die Präsentationsschicht nur einfache Datentypen verarbeiten, während die Domäne komplizierte abstrakte Datentypen enthält. Daher muss die Anwendungslogik die aus der Domänenschicht kommenden Daten für die einfacher gehaltene Präsentationsschicht übersetzen. Umgekehrt ist sie dafür verantwortlich, die vom Nutzer eingegebenen Daten in geeigneter Form in die Domäne einzubringen. Um die Programmierung von Nutzeroberflächen zu erleichtern kann an dieser Stelle das Anwendungsfassade-Muster eingesetzt werden.

Aufteilung der Anwendung in Schichten

In Umgebungen, in denen die Anwendung auf verschiedene Prozesse verteilt ist (wie beim Client-Server-Modell), sollte die Fassade ebenfalls verteilt werden. Anfragen der Präsentationsschicht an die clientseitige Fassade werden dann von dieser an eine Fassade auf dem Server weitergereicht und dort bearbeitet.

Siehe auch: Anwendungsdomäne

Prinzip

Die Idee, die hinter der Anwendungsfassade steckt, ist im Grunde recht simpel. Genau wie die Fassade eines Hauses versteckt sie das komplizierte Gerippe, das die eigentliche Substanz bildet. Dabei erzeugt sie eine logische Sichtweise. Da man auf ein Geschäftsmodell meist viele Sichtweisen haben kann, gibt es häufig mehr als nur eine Anwendungsfassade. Der Trick ist einzelne Teile aus der Domänenschicht so zusammenzubringen und verfügbar zu machen, dass ein logisches Abbild entsteht.

Stellen wir uns das Softwaresystem einer Bank vor. In der Domänenschicht gibt es unter anderem Kundenstammdaten, Konten, Depots, Kredite und Transaktionen. Die Vertriebsabteilung klassifiziert Kunden nach diesen Daten. Hier kann eine Fassade „Klassifizierter Kunde“ eingeführt werden. Sie wird eine Methode getClassification() anbieten, die zwar nach außen einfach auftritt; der Algorithmus, der die Bewertung in der Domäne sucht und konsistent hält, mag aber komplex sein. Er durchsucht die Objekte der Domäne abhängig vom jeweiligen Kunden und gibt einen String („A“, „B“, …) zurück. Für die Ausgabe der Klassifizierung eines Kunden auf dem Bildschirm reicht dann ein einfacher Aufruf der Methode (hier als Java-Implementierung):

ClassifiedCustomer classifiedCus = ClassifiedCustomer.getByName("Max Mustermann");
System.out.println(classifiedCus.getClassification());

Implementierung

Zur Umsetzung der Anwendungsfassade macht Martin Fowler recht konkrete Angaben (was für ein Analysemuster eher erstaunlich ist). Jede Anwendungsfassade besitzt ein subject, also ein bestimmtes Objekt aus der Domäne. Dieses Objekt wird als Startpunkt aller vorzunehmenden Aktionen verwendet. Die Sichtbarkeit des Subjektes ist auf private zu setzen.

In unserem obigen Beispiel wäre das Subjekt der Anwendungsfassade „klassifizierter Kunde“ ein einfaches Objekt vom Typ „Kunde“. Von ihm aus kann ClassifiedCustomer zu den einzelnen Konten, Depots und Transaktionsdaten navigieren oder eben die Einstufung in ein Klassifizierungssystem finden und bearbeiten. Damit ist die Klassifizierung nun ein Attribut der Anwendungsfassade ClassifiedCustomer. Aber Achtung: alle Attribute einer Fassade sollten von Typen sein, die auch in der Domänenschicht vorkommen.

Siehe auch: Objektorientierte Programmierung

Akzessoren

Martin Fowler nennt die Akzessoren der Anwendungsfassade retrieval method und meint damit das, was man im Allgemeinen unter einem Getter versteht. Diese Methode hat demnach die Aufgabe den aktuellen Wert eines Attributs aus der Domänenschicht zu holen und zurückzugeben. In manchen Fällen kann diese Aufgabe wesentlich komplizierter sein, als es auf den ersten Blick scheint.

Nehmen wir an, ein Kunde unserer Bank will den aktuellen Stand seines Gesamtvermögens wissen. So müssen die Salden aller Konten, alle Kredite und alle Depots berücksichtigt und beaufschlagt werden. Außerdem stellt sich die Frage, wie sichergestellt werden kann, dass die Rechnung die aktuellen Werte enthält. Solche schwierigen Vorgänge versteckt die Anwendungsfassade hinter einer einfachen Methodenschnittstelle:

classifiedCus.getTotalBalance();

Bei der Implementierung solcher Methoden ist darauf zu achten, dass der Rückgabetyp sich vom tatsächlichen Typen des untersuchten Attributes unterscheidet. Während für das Attribut hier beispielsweise ein komplexer Datentyp (Quantity) angewendet werden sollte, wird die grafische Oberfläche eher eine Gleitkommazahl erwarten.

Manipulatoren

Natürlich muss eine Anwendungsfassade auch Methoden zur Manipulation der Attribute anbieten, sogenannte update methods. Diese Setter können ebenfalls eine sehr hohe Komplexität erreichen. Nicht selten erfordern sie beachtlichen Einsatz. Zwischen den Objekten der Domänenschicht bestehen viele Beziehungen, gerade deshalb setzt man ja die Anwendungsfassade ein. Wird nun eines dieser Objekte verändert, so müssen auch abhängige Objekte unter Umständen aktualisiert werden.

Suchen wir als Beispiel einen unserer Kunden, der als „C-Kunde“ eingestuft ist (also am unteren Ende unseres Systems rangiert) und aktualisieren wir mit der update method sein Konto aufgrund eines unerwarteten Geldsegens:

classifiedCus.setBalance(new Quantity(1000000,Unit.get("Euro")));

Offensichtlich muss nun auch dafür gesorgt werden, dass die Einstufung des Kunden automatisch aktualisiert wird. Alternativ könnte auch die Einstufung als nicht aktuell markiert und bei der nächsten Abfrage auf den neuesten Stand gebracht werden.

Doch damit nicht genug. Es sind noch viele Szenarien denkbar, welche die Implementierung einer update method verkomplizieren können. Beispielsweise könnte es in einem System unzulässig sein, beim Setzen eines Attributes seinen alten Wert einfach zu überschreiben. Dann muss bei einer Aktualisierung der alte Wert irgendwie gesichert oder markiert werden. Aber auch Update-Methoden für als Collections ausgeprägte Attribute machen die Implementierung aufwändig. In diesem Fall werden zwei Methoden notwendig: eine zum Hinzufügen von Werten zur Liste und eine zum Löschen.

Validierer

Werden Daten in die Domänenschicht eingebracht, also Werte von Objekten verändert, muss sichergestellt werden, dass diese Daten auch plausibel sind. In einfachen Fällen kann es ausreichen für qualitative Merkmalstypen eine Liste mit möglichen Ausprägungen und für quantitative Merkmale Grenzen bereitzuhalten. Dies geschieht in Form einer legal values method. Die Validierungsmethode überprüft dann einfach ob der gegebene Wert in der Liste der erlaubten Werte aufgeführt ist, beziehungsweise ob er innerhalb der vorgegebenen Grenzen liegt. Manchmal ist die Überprüfung auf Zulässigkeit aber auch nicht ganz so einfach, beispielsweise wenn es sich um Datumsangaben handelt.

Standardwerte

Schließlich gehört zur Anwendungsfassade noch eine sogenannte default method. Hinter ihr verbirgt sich ein wirkungsvoller Trick zur weiteren Reduktion der Komplexität. Belegt man einen Datensatz beim Anlegen zunächst mit Standardwerten, dann kann man beim Einpflegen der initialen Werte einfach auf die Update-Methode zurückgreifen. Die Umsetzung der Standardwerte-Methode ist sehr einfach, sie ist im Grunde eine spezieller Getter. So lässt sich das System ohne großen Aufwand vereinfachen.

UML-Diagramm der Domänenschicht aus Martin Fowlers Artikel Application Facades

UML-Diagramm der Anwendungslogik aus Martin Fowlers Artikel Application Facades

Ü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

Mehrere Anwendungsfassaden

Der Einsatz mehrerer Anwendungsfassaden bietet weitere Möglichkeiten die Architektur der Anwendung zu verbessern. Verwendet eine Ansicht der Präsentationsschicht Informationen aus mehreren Fassaden, kann sie dem Anwender völlig neue Darstellungen zur Verfügung stellen. Auch Vererbung kann bei Fassaden sinnvoll eingesetzt werden. In unserem Beispiel einer Banken-Software existiert wahrscheinlich eine Anwendungsfassade „Customer“, „ClassifiedCustomer“ ist also nur eine Spezialisierung. Solche Vorgehensweisen verbessern das System zusätzlich hinsichtlich Flexibilität und Stabilität.

Beispiel-Implementierung

Ein ausführliches Beispiel zur Funktionsweise der Anwendungsfassade stellt Martin Fowler mit seinem Artikel „Application Facades“ zur Verfügung. Exemplarisch erklärt er darin die Idee und Umsetzung anhand eines Informationssystems für Krankenhäuser. Außerdem beinhaltet das in Java gehaltene Programm viele andere Analysemuster von Fowler, zum Beispiel:

• Unit
• Quantity
• Phenomenon
• Observation

Das detaillierte Beispiel geht auf die Einzelheiten der Methodik ein und zeigt die Verwendung von Modultests. Zur kompletten Implementierung fehlen trotz vieler Bruchstücke einige Teile.

Bei einer teilweisen Implementierung des Beispiel-Programmes in Python konnte gezeigt werden, dass mit Fowlers Ansatz sogar die Umsetzung in ein zur Laufzeit rekonfigurierbares Programm möglich ist.

Literatur

• Martin Fowler: Analysemuster: Wiederverwendbare Objektmodelle. Addison-Wesley-Longman, Bonn 1999, ISBN 3-8273-1434-8.
• Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley, 1996, ISBN 0-201-63361-2.

Weblinks

• Der Artikel Application Facades von Martin Fowler. (PDF-Datei; 94 kB)
• www.MartinFowler.com Homepage von Martin Fowler.
• .zip-Datei zum Download mit den Java-Quellen für ein Eclipse-Projekt und der Dokumentation zur Beispiel-Implementierung