Konnektor (UML)

Ein Konnektor (engl. Connector) ist ein Modellelement in der Unified Modeling Language (UML), einer Modellierungssprache für Software und andere Systeme.

Ein Konnektor modelliert eine Verbindung zwischen zwei oder mehr verbindbaren Elementen, das heißt Parts, Ports, Parametern und Variablen. Man beachte, dass in dieser Aufzählung die Modellelemente Klasse, Schnittstelle oder Komponente nicht vorkommen. Daraus ergibt sich der wesentliche Unterschied zwischen Assoziationen und Konnektoren. Konnektoren spezifizieren Verbindungen zwischen Teilen eines Classifiers, während Assoziationen Verbindungen zwischen den Classifiern selbst beschreiben.

Aussagekraft von Konnektoren gegenüber Assoziationen

Das Bedürfnis für das Modellelement Konnektor ergibt sich vor allem aus dem Schwachpunkt, dass die Modellierung mit Klassen und Assoziationen oft nicht ausreicht, um die innere Struktur eines Systems darzustellen.

Ein Klassendiagramm, das die innere Struktur eines Autos spezifiziert. Die nötige Präzision kann nur mit Hilfe von Einschränkungen erreicht werden.

Die Abbildung links zeigt zum Beispiel ein Klassendiagramm, das die innere Struktur eines Autos modellieren soll. Dass ein Auto über zwei Vorderräder und zwei Hinterräder verfügt, ist mit zwei Kompositionsbeziehungen zwischen Auto und Rad dargestellt. Eine weitere Kompositionsbeziehung zeigt, dass jedes Auto einen Motor enthält. Mit Hilfe einer Assoziation ist relativ einfach darstellbar, dass ein Motor zwei Räder antreibt. Ohne zusätzliche Einschränkung auf der Klasse Auto wären gemäß diesem Klassendiagramm jedoch einige degenerierten Konfigurationen von Ausprägungen denkbar. Zum Beispiel könnte ein Motor ein Hinterrad und ein Vorderrad antreiben. Der Motor eines Autos könnte zudem mit zwei Hinterrädern eines anderen Autos verbunden sein. Erst die Einschränkung, die mit der Klasse Auto verbunden ist, schließt diese Fälle aus.

Ein Kompositionsstrukturdiagramm, das die innere Struktur eines Autos spezifiziert. Ein Konnektor verbindet die Part :Motor und vorderRad.

Die gleiche innere Struktur eines Autos lässt sich mit Hilfe eines Kompositionsstrukturdiagramm darstellen. Die oben beschriebenen degenerierten Fälle können hier nicht auftreten. Ein Konnektor zwischen den Parts :Motor und vorderRad reicht aus, um die strukturellen Einschränkungen vollständig zu spezifizieren, eine zusätzliche Einschränkung ist nicht nötig.

Kompositions- und Delegationskonnektor

Die UML2 unterscheidet mit dem Kompositions- und dem Delegationskonnektor zwei spezielle Arten von Konnektoren.

Beispiel eines Komponentendiagramm mit zwei Kompositionskonnektoren

Ein Kompositionskonnektor verbindet zwei Ports von zwei Komponenten, die zusammenarbeiten, das heißt zu einer größeren Einheit komponiert werden. Der Port der einen Komponente muss eine Schnittstelle anbieten, die der Port der anderen Komponente benötigt. Graphisch wird der Kompositionskonnektor nicht als durchgehende Linie zwischen den beiden beteiligten Ports, sondern als zwei ineinandergreifende Symbole für eine angebotene und eine benötigte Schnittstelle dargestellt. In der Abbildung links gibt es zwei Kompositionskonnektoren. Der eine verbindet EmailManagement mit MailEingang, der andere EmailManagement mit MailAusgang.

Beispiel eines Kompositionsstrukturdiagramms mit zwei Delegationskonnektoren

Ein Delegationskonnektor verbindet einen Port eines Classifiers mit einem Part im Innern des Classifiers. Er steht für die Tatsache, dass Meldungen, die von außen beim Port eintreffen, an den verbundenen Part weitergeleitet, d. h. delegiert werden. In der Abbildung links sind zwei Delegationskonnektoren eingezeichnet. Der eine verbindet den Management Port mit dem Part :Benutzerverwaltung, der andere einen anonymen Port, an dem E-Mails eintreffen, mit dem Part :Meldungsdatenbank.

Unterschiede zur UML 1.4

Das Modellelement Konnektor wurde in der UML2 neu eingeführt.

Literatur

• Christoph Kecher: UML 2.0 - Das umfassende Handbuch. Galileo Computing, 2005, ISBN 3-89842-573-8
• Conrad Bock: UML 2 Composition Model. in Journal of Object Technology, vol. 3, no. 10, November-December 2004, pp. 47-73, [1]