Computational Viewpoint

 Der Computational Viewpoint zerlegt eine verteilte Anwendung in Objekte, die an festgelegten Schnittstellen miteinander agieren, ohne die Infrastruktur der Verteilung zu berücksichtigen, die ja vom Engineering Viewpoint abgedeckt wird. Dabei werden nur die Schnittstellen definiert, ohne Rücksicht auf die Implementierung zu nehmen. Mit Hilfe der an den Schnittstellen verfügbaren Operationen bieten die Objekte anderen Objekte ihre Dienste an. Im Computational Viewpoint werden die Objekte als Computational Objects und die Schnittstellen als Computational Interfaces bezeichnet. Bezüglich einer Schnittstelle kann ein Objekt verschiedene Rollen annehmen, wie z.B. Client|Server oder Producer|Consumer. Durch Templates werden die Eigenschaften der Computational Objects und der Computational Interfaces spezifiziert. Ein Computational Object Template legt alle Informationen fest, die zur Instantiierung des Objekts zur Laufzeit erforderlich sind. Darunter fallen die Anforderung des Objekts an die Umgebung, dessen Verhalten während der Laufzeit und sämtliche Schnittstellen, die es erzeugt. Das Computational Interface Template umfaßt die Signatur und das Verhalten einer Schnittstelle, die diese bei der Instantiierung zur Laufzeit annimmt. Die Signatur beschreibt die an der Schnittstelle möglichen Interaktionen und welche Dienste genutzt oder angeboten werden können. Weiter sind auch noch die Anforderungen an die Umgebung in dem Template festgelegt.

Das Referenzmodell legt drei Arten von Schnittstellen fest:

• operation: Hierbei handelt es sich um Prozedur-ähnliche Interaktionen, die nach dem Client-Server Prinzip funktionieren. Ein Client ruft eine Funktion des Servers auf, der daraufhin eine Antwort zurücksendet. Operationen können synchron oder asynchron sowie bestätigt oder unbestätigt sein. Die Antwort einer Operation wird als termination bezeichnet, während bestätigte Operationen als interrogations und unbestätigte Operationen als announcements bezeichnet werden. Tritt ein Objekt an der Schnittstelle als Dienstnutzer auf, so nimmt es die Rolle eines Client an, während es als Diensteanbieter die Rolle eines Servers annimmt.
• flow: Ein flow ist ein Datenstrom zwischen einem Erzeuger (Producer) und einem Verbraucher (Consumer). Datenströme kommen z.B. bei Video- oder Audioübertragungen innerhalb von Multimedia-Anwendungen vor.
• signal: Ein signal ist ein Ereignis, das von einem Objekt (Initiator) zu einem bestimmten Zeitpunkt generiert und an ein anderes Objekt (Responder) geschickt wird. Hierbei handelt es sich um eine atomare, also ununterbrechbare Kommunikation. Beispielsweise kann das eine Unterbrechungsaufforderung (Interrupt) sein, die von einem sie initiierendes Objekt an ein antwortendes Objekt geschickt wird.

Weiter definiert das Referenzmodell Bindungen (bindings), die als eine Art Kommunikationsverbindung zwischen den Schnittstellen zweier Computational Objects hergestellt werden. Es ist wichtig, daß die beiden an eine Bindung angeschlossenen Schnittstellen vom gleichen Typ sind. Bindungen zwischen genau zwei Schnittstellen werden als primitive Bindung bezeichnet und können implizit oder explizit sein. Implizite Bindungen werden nur zwischen Operation Interfaces aufgebaut und entsprechen einem entfernten Methodenaufruf. Bei expliziten Bindungen muß die Verbindung zwischen den kommunizierenden Objekten explizit aufgebaut werden. Wird eine Bindung zwischen mehreren Schnittstellen aufgebaut, so handelt es sich um eine komplexe Bindung (compound binding), die über ein Binding Object realisiert wird. Das Binding Object koppelt die Schnittstellen mehrerer Objekte durch primitive Bindungen aneinander, die über eine Kontrollschnittstelle hinzugefügt, überwacht oder gelöscht werden können (siehe Abbildung ).

  

Abbildung: Binding Object