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.
Schichtenarchitektur[Bearbeiten | Quelltext bearbeiten]
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.
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.
Prinzip[Bearbeiten | Quelltext bearbeiten]
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[Bearbeiten | Quelltext bearbeiten]
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.
Akzessoren[Bearbeiten | Quelltext bearbeiten]
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[Bearbeiten | Quelltext bearbeiten]
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[Bearbeiten | Quelltext bearbeiten]
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[Bearbeiten | Quelltext bearbeiten]
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 ein spezieller Getter. So lässt sich das System ohne großen Aufwand vereinfachen.
| Methode | OO-Name | Funktion |
|---|---|---|
| retrieve | get | Akzessor |
| update | set | Manipulator |
| legal values | Liste zulässiger Werte / Grenzwerte | |
| validation | Validierer | |
| default | Standardwert setzen |
Mehrere Anwendungsfassaden[Bearbeiten | Quelltext bearbeiten]
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[Bearbeiten | Quelltext bearbeiten]
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:
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[Bearbeiten | Quelltext bearbeiten]
- 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.
