Schnittstellen festlegen

Da die Komponenten in einem Gesamtsystem arbeiten, benötigen diese Schnittstellen, über die Daten und Funktionen für die Realisierung der Systemfunktionen ausgetauscht bzw. genutzt werden. Ziel dieser dritten Architekturtätigkeit ist es, genau diese Schnittstellen zwischen den Komponenten festzulegen.

Prinzipiell unterscheidet man zwischen "angebotenen" (provided) und "benötigten" (required) Schnittstellen. Eine angebotene Schnittstelle stellt Dienste/Daten nach außen zur Verfügung, wohingegen eine benötigte Schnittstelle Dienste/Daten von außen in Anspruch nimmt. Diese Unterscheidung ist oft nicht einfach, da durch sie in dieser Phase der Entwicklung noch keine Aussagen über die Kommunikationsrichtung getroffen werden sollte. Man sollte an dieser Stelle intuitiv vorgehen und das Anbieten von Diensten/Daten als angebotene Schnittstelle modellieren.

Zum Finden der Schnittstellen können Sie die Use-Case-Diagramme der Komponenten und deren Verfeinerungen ausnutzen, da dort ja die Beteiligung der Nachbarkomponenten an einem Use-Case beschrieben wird.

Die UML bietet unterschiedliche Darstellungsmöglichkeiten für Schnittstellen. Eine davon sind die Interface-Klassen. Hier legt man eine Klasse mit dem Stereotyp <<interface>> an. Die Komponente, die dieses Interface zur Verfügung stellt, wird anschließend über eine <<realize>>-Beziehung verbunden, die verwendende Komponente über eine <<use>>-Beziehung mit dieser Klasse. Eine abkürzende Schreibweise ist die Notation "Ball & Socket". Hier werden die angebotene Schnittstelle über eine Kugel (den so genannten Lollipop) und die benötigte Schnittstelle über einen Halbkreis dargestellt.

Prinzipiell sollte jede Komponente in der Komponentenhierarchie Schnittstellen besitzen, um die abstrakte Sicht auf die Zerlegung vollständig zu unterstützen. Wenn eine Komponente eine Schnittstelle anbietet, bedeutet dies nicht zwingend, dass diese die Schnittstelle direkt realisiert, also zum Beispiel ein Stück Code implementiert werden muss. Nehmen wir als Beispiel dafür die Schnittstelle einer Komponente auf unterster Ebene. Genau diese Schnittstelle möchten wir auch in der darüber liegenden Komponente sichtbar machen. In diesem Fall können Schnittstellen nach oben delegiert werden. Das bedeutet, eine Komponente stellt die Schnittstelle ihrer Subkomponente zur Verfügung, hat aber keinen Realisierungsanteil für diese Schnittstelle. So wird im Beispiel die Schnittstelle Lokale Steuerung vollständig von der Komponente Taster realisiert. Anders sieht es aus, wenn eine Komponente mehrere Schnittstellen ihrer Subkomponenten zusammenfasst, also eine Art Fassade bildet. Hier muss auch die darüber liegende Komponente einen Teil der Realisierung übernehmen.

Das Delegieren von Schnittstellen wird in der UML-Notation über eine Abhängigkeitsrelation mit dem Stereotyp <<delegate>> dargestellt. Diese Beziehung zeigt von der zu delegierenden Schnittstelle der Subkomponente auf die delegierende Schnittstelle der übergeordneten Komponente.

Da in der Systemarchitektur nicht nur reine Software betrachtet wird, ist es oft wichtig, alle Aspekte einer Schnittstelle zu beschreiben. Bisher haben wir die logischen Informationen betrachtet, die direkt mit den Mitteln der UML dargestellt werden können. Hinzu kommen physikalische Informationen bei elektrischen und mechanischen Schnittstellen und Informationen über Protokolle bei Software-Schnittstellen. Diese Informationen können in der UML über Stereotypen (<<electrical>>, <<mechanical>> etc.) und eine Erweiterung durch spezielle Attribute für die jeweiligen Stereotypen modelliert werden.

Der Ablauf der Zusammenarbeit der Komponenten für einen System-Use-Case, also das dynamische Nutzen der Schnittstellen untereinander, kann in der UML mit Hilfe von Sequenzdiagrammen dargestellt werden. Hier kann man formaler werden und mehr Informationen gerade über die Zusammenarbeit von Softwarekomponenten modellieren. Als Kommunikationspartner erscheinen die an der Realisierung eines Use-Case beteiligten Komponenten. Die Nachrichten in dem Sequenzdiagramm bilden dann die Aufgaben der Komponenten ab. Eine Nachricht kann entweder der Aufruf einer Operation sein (synchrone Nachricht) oder das Senden eines Signals/ Events (asynchrone Nachricht).