Im Laufe der letzten Jahrzehnte wurden zahlreiche Architekturen für die Umsetzung grafischer Systeme vorgestellt. Der am weitesten verbreitete Ansatz ist die Model-View-Controller (MVC) Architektur (Krasner & Pope, 1988). Das System besteht aus drei grundlegenden Komponenten. Das Modell (Model) beinhaltet die darzustellenden Daten und in einigen Varianten des MVC-Musters auch die zugehörige Geschäftslogik. Das Model ist komplett unabhängig von der Darstellung und der Vor- und Nachbearbeitung durch die Benutzerschnittstelle. Die Sicht (View) umschließt die Darstellung des Modells mit Hilfe visueller Elemente und ermöglicht die Benutzerinteraktion. Die Sicht kennt demnach sowohl das Modell als auch die Steuerungslogik (Controller). Die Steuerungslogik kennt sowohl das Modell als auch die Sicht und implementiert den Kontroll- und Datenfluss zwischen diesen beiden Elementen. Benutzerinteraktionen und Veränderungen innerhalb der Sicht werden hier verarbeitet und bei Bedarf können in der Folge sowohl die Sicht selbst als auch das Modell verändert werden. Gleichzeitig überwacht die Steuerungslogik Änderungen am Modell, um diese dann auf die Sicht zu übertragen. Das MVC-Architekturmuster hat sich etabliert, da es die drei involvierten Komponenten klar voneinander trennt. Auf diese Weise wird ein höherer Grad der Wiederverwendung des Modells ermöglicht und die Programmier- und Wartbarkeit von Oberflächensystemen wird stark erhöht. Allerdings ist die Steuerungslogik stark mit dem Modell und der Sicht verbunden und kann nicht ohne weiteres in anderen Nutzungsfällen wiederverwendet werden. Auch besitzt die Sicht eine starke Abhängigkeit zum Datenmodell und kann nicht änderungslos von diesem getrennt werden.
Eine Variante des MVC-Musters ist das Model-View-Presenter (MVP) Architekturmuster . Dies besteht dieses aus den drei Komponenten Model, View und Presenter. Im Gegensatz zum MVC-Muster werden hier Modell und Sicht vollständig entkoppelt. Die direkte Integration wird durch einen komplexen Presenter übernommen der beide Komponenten kennt und zwischen diesen Koordiniert. Auf diese Weise kann sowohl die Sicht als auch das Modell unabhängig voneinander wiederverwendet werden. Das Modell und die Sicht kommunizieren Änderungen indirekt über eine Benachrichtigungsschnittstelle.
Bei dem Passive-View Architekturmuster oder dem auf Microsoft XAML spezialisierte Model-View-ViewModel Architekturmuster (Sorensen & Mihailesc, 2010) werden Modell und Sicht noch weiter entkoppelt. Entsprungen aus der Anforderung Oberflächensysteme besser testen zu können, gibt es im Passive-View Ansatz keine Beziehung mehr zwischen Modell und Sicht. Der Presenter bekommt noch mehr Verantwortlichkeiten, in dem er sowohl die Datenbindung der Sicht als auch die Datenbeschaffung und –synchronisation regelt.
Im Rahmen von SysPlace wurde entschieden Anwendungen nach dem Passive-View-Muster zu implementieren, da dies die größte Entkoppelung von Model und View ermöglicht. Auf diese Weise können Oberflächen leichter in eine andere Anwendung migriert werden. Darüber hinaus können Datenmodelle zur Laufzeit vollständig ausgetauscht werden. So ist es möglich eine Anwendung mit einem entfernten Datenmodell zu koppeln, um zwei Anwendungen zu synchronisieren, indem diese das gleiche Modell verwenden. Die Abbildung zeigt die Oberflächenarchitektur einer BI-Anwendung mit einem SMAGs Komponentenmodell. Das Oberflächensystem ist dabei in vier Teile untergliedert:
- Das Modell wird über eine ModelAccessComponent zugänglich gemacht, die Lese- und Schreiboperationen auf anwendungsspezifischen Daten ermöglicht. Darüber hinaus wird eine Ereignisschnittstelle angeboten, die über Modelländerungen benachrichtigt. Dies ist vor allem bei verteilten Modellen wichtig, die von verschiedenen Anwendungen verwendet werden.
- Der Presenter vermittelt zwischen dem Modell und der Sicht, indem er Daten aus dem Modell an die Oberflächenkomponenten bindet. Dem Presenter stehen spezielle Ports zur Verfügung um die Darstellung der Daten anwendungsspezifisch anzupassen (z.B. Zeitformatierung etc.) und Ports und die Benachrichtigung bei interaktiven Elementen (z.B. Buttons, Textfeldern etc.) zu steuern. Der Presenter ist auch die Schnittstelle zur BI-Komponente, die die Interaktion zwischen verteilten Anwendungen regelt.
- Die Sicht (View) stellt alle Oberflächenkomponenten zusammen. Oberflächen werden in Form von Komponenten spezifiziert und können über in einer Meta-Architektur standardisierte Schnittstellen angesprochen werden. Alle Änderungen an dem Oberflächenmodell werden über die ViewAccessComponent realisiert.
- Die BI-Komponente (BI-Component) regelt die Kommunikation und Kollaboration mit anderen BI-Anwendungen.
