"Zuweilen habe ich im Schlafe die Lösung solcher Probleme gefunden, die im wachen Zustand unlösbar schienen."
(Anton Hansen Tammsaare)

Architekturen

MVC Paradigma

MVC steht für "Model-View-Controller" und geht auf das EVA-Prinzip zurück: die Eingabe, Verarbeitung und Ausgabe von Daten sollte immer getrennt betrachtet werden. Im Zusammenhang mit Smalltalk wurde in den 70er Jahren im Xerox PARC das EVA-Prinzip erstmalig auf die graphische Benutzerschnittstelle übertragen und als weiterentwickelte MVC-Architektur etabliert.

Das Model ist die genau eine Programm-Repräsentation, stellt also die eigentlichen Daten und Funktionalitäten zur Verfügung, die eng mit dem Problem verbunden sind und deshalb so lange unverändert bleiben, wie auch das Problem unverändert besteht. Die Views sind all die Präsentationen des Models gegenüber dem Anwender, also auch die echte Visualisierung der Daten und damit die Verbindung des Models zur Aussenwelt. Die Controller steuern das Verhalten der Software, nehmen also Ereignisse vom Anwender aus den Views entgegen, beeinflussen das Model und führen dadurch zur Veränderung der Views.

Strikt genommen kann das Model in ein Domain Model (M_D) und ein Application Model (M_A) geteilt werden: das M_D kümmert sich ausschließlich um das eigentliche fachliche Problem, wogegen das M_A die Schnittstellen zu den Views und Controllern enthält. Die Kommunikation zwischen M_D, M_A, V und C erfolgt häufig über Ereignisse (engl.: events) oder Nachrichten (engl.: messages).

Die Begrifflichkeiten sind hier übrigens nicht immer sauber abzugrenzen: MVC wird je nach Kontext als Muster, Idiom, Paradigma, Prinzip, Architektur oder auch Modell betrachtet. Wenn Sie weitere Informationen zu MVC suchen, geben Sie einfach in einer Internet-Suchmaschine "MVC Smalltalk" ein. Sie werden beispielsweise dieses finden.

n-tier-Model

Bei jeder auch nur halbwegs ernst gemeinten Software für einen kommerziellen Kunden mit mehr als drei Anwendern sollte die Architektur immer eine Zerlegung in Komponenten mit einer Verteilung dieser Komponenten im Netzwerk ermöglichen. Der CORBA-Standard [L16] der OMG [L3] beschreibt seit Jahren, wie eine Software auf mehrere Computer verteilt werden kann. "CORBA" ist die Abkürzung für "Common ORB Architecture" und "ORB" ist die Abkürzung für "Object Request Broker". Ein ORB ist eine Systemsoftware, die im Netzwerk mit Objekten - also Softwaremodulen - makelt. Wenn also ein Objekt ein anderes im Netzwerk sucht, kann der ORB dieses finden. CORBA ist ein allgemeiner Architekturstandard für die Implementierung von ORBs in ein System. Bekannte CORBA-Implementierungen sind beispielsweise Microsoft-COM (Component Object Model) und EJB (Enterprise Java Beans).

Es ist also sehr wohl möglich, von einem Programm auf dem einen Computer eine Funktion in einem Programm auf einem anderen Computer aufzurufen. Dies führt in der Praxis dazu, dass heutzutage die wesentliche Logik der Software von den Modulen auf den zentralen Servern erledigt wird, denn hier steht die größte Rechenleistung zur Verfügung und hier können die Änderungen so durchgeführt werden, dass sie sofort allen Anwendern zur Verfügung stehen. Die Software-Module, die wirklich auf den Anwender-PCs installiert werden, kümmern sich heutzutage nur noch um die reine Kommunikation mit dem Anwender, d.h. die Eingabe der Daten, das Auslösen von Aktionen und die Präsentation der Ergebnisse. Die Daten werden auf speziellen Datenbank-Servern gespeichert, wo sie gegen direkte Zugriffe durch die Anwender geschützt sind. Selbst die Software-Module auf den Anwender-PCs fordern diese Daten indirekt über die zentralen Logik-Server an.

Damit haben wir in der PC-Welt sowohl die Zeit hinter uns gelassen, in der die Software ausschließlich auf den PCs läuft, als auch die Zeit, in der nach Client-/Server-Technik die gesamte Logik auf dem PC läuft und nur die Daten, Dateien und Drucker zentral verwaltet werden. Heute kann auch nicht mehr nur vom "3-tier-Model" gesprochen werden, weil größere Programme noch feiner modularisiert und im Netz verteilt werden.

Das n-tier-Model ermöglicht im Wesentlichen die Kapselung und Trennung von Wissen im Software-System. So kann beispielsweise die Umrechnung von Währungen oder die Ermittlung von Rabatten mit speziellen Modulen auf speziellen Servern realisiert werden. Das Wissen über die Umrechnungsfaktoren der Währungen oder der Staffeln des Rabattsystems liegt dann in zentralen Komponenten und kann in der Regel ohne Einfluss auf den Rest des Software-Systems geändert werden. Noch wichtiger ist anders herum, dass alle anderen Module des Software-Systems zwar wissen, was es gibt und dies auch benutzen können, aber nicht wissen müssen, wie es funktioniert und wie es implementiert ist.

Die zentrale Schicht, die als "Business Tier" die Geschäftslogik implementiert, weiß also nicht, ob oder gar wie die Daten in einer Datenbank gespeichert werden; sie weiß auch nicht, welche Daten dem Anwender wie präsentiert werden. Durch die Kapselung des Wissens in Module entsteht also gleichzeitig eine Trennung des Wissens und durch klar definierte Schnittstellen kann die Entwicklung der Software auch leicht auf mehrere Entwickler gleichzeitig verteilt und nahezu beliebig skaliert werden.

Beispiel

Von Sun^TM gibt es für den Sun^TM ONE (iPlanet^TM) Application Server eine Beispiel-Applikation "Java Pet Store", deren Architektur im Internet öffentlich beschrieben ist (alternativ hier als mirror).

MDA

MDA bezeichnet die Model Driven Architecture [L20] von der OMG. Dort gibt es reichlich weitere Infos und von dort habe ich auch obiges Bild entnommen.