 | ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
Glossar 
Forschungsprojekte 
Anbieterverzeichnis 
Datenbanksuche 
Highlights | ||||||||||||||||||||||||||||||||||||||||||||||
| Wissensbrowser starten | ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||
|  | |  | |  | |
| ||||||
| ||||||
|  | | ||||
| ||||||
Verfahren |
|
Architekturbeschreibung mit Rapide |
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| Beschreibung | |||||||||
| |||||||||
| Rapide hat seinen Ursprung an der Stanford University und ist eine der bekanntesten Architecture Description Languages (ADL). Diese ADL hat ihren Schwerpunkt im Prototyping großer, verteilter (Echtzeit-) Systeme.
Rapide besteht aus mehreren Teilsprachen. Zu ihrem Kern gehören eine Sprache zur Beschreibung von Komponenten-Schnittstellen (die Type Language) und eine Sprache zur Beschreibung von Kommunikationsmustern (die so genannte Pattern Language). Komponenten werden über ihre Schnittstellen beschrieben. Die Schnittstellen definieren sowohl die exportierte Funktionalität, wie auch die benötigte Funktionalität. Abhängigkeiten zwischen Komponenten werden damit explizit gemacht. Die Schnittstellen enthalten synchrone Funktionen (Functions) und asynchrone Funktionen (Actions). Systemabläufe werden als partiell geordnete Menge von Ereignissen beschreiben, den Posets. Mit der Pattern Language wird das Systemverhalten über diese Ereignismengen spezifiziert. Analysen des Systemverhaltens werden über dessen Simulation vorgenommen. Das Verhalten wird unter verschiedenen eingehenden Ereignissen beobachtet. Rapide untersucht die Ereignisse, die vom System erzeugt werden und die Konformität zu den in der Architektur festgelegten Constraints (Einschränkungen). Der folgende Ausschnitt spezifiziert die beiden Typen (Interfaces) Publisher und Subscriber, beide beschreiben einen Teil des Publisher/Subscriber Entwurfsmusters aus [Buschmann 1996].
Der Typ Subscriber benötigt die Funktion retrieve_info, mit der er erforderliche Informationen erhält. Damit wird seine importierte Schnittstelle beschrieben. Der Typ Publisher exportiert die Funktion retrieve_info. Asynchrone Kommunikation findet über die Actions notify_subscriber statt. Auch hier wird exportieren (out) und importieren (in) modelliert. Das Verhalten des Typs wird im Abschnitt behaviour über Transitionsregeln dargestellt. Eine Regel gibt an, wie sich der Zustand als Reaktion auf Ereignisse ändert. Im Beispiel wird retrieve_info als Reaktion auf notify_subscr aufgerufen. Konsistenzbedingungen werden im Abschnitt constraint definiert. Im Beispiel wird festgelegt, dass retrieve_info erst aufgerufen werden darf, wenn notify_subscr davor stattgefunden hat. Architekturen werden mit der Architecture Language aus den Typen (Interfaces) zusammengesetzt. Die Provides- werden mit den Requires-Funktionen verbunden, Out-Actions werden mit In-Actions verknüpft. Das nachfolgende Beispiel zeigt, wie aus Publisher und Subscriber eine Architektur aufgebaut wird:
Große Architekturen setzen sich aus Sub-Architekturen zusammen. Eine Architektur kann dazu einem Interface zugeordnet werden. | |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
Eintrag kommentieren | ||||
| ||||
 | Übergeordnet | | ||
| ||||
|
| | ||
| ||||
| ||||
| ||||
| ||||
| Architekturbeschreibung... | ||||
| ||||
| ||||
| ||||
| ||||
| Weitere Themen | | ||
| ||||
|
| | ||
| ||||
| ||||
| | | ||
| ||||||||||||||
|
