Komponenten in UML

Eine Komponente ist eine modulare, autonome Einheit mit definierten Schnittstellen.
Eine Komponente ist in ihrer Umgebung ersetzbar (replaceable)
(aus OMG UML2.1 2006-04-02 Kap.8.1)

Schnittstelle:

required - Schnittstellen, die aufgerufen werden

provided - Schnittstellen, die implementiert werden.

Schnittstellen können zu Ports gruppiert werden:

Port:

• Isoliert eine Komponente (Classifier) von seiner Umgebung
• Leitet Interaktionen aus der Umgebung in das Innere

Im IBM Rational Software Architekt 8.0 müssen die Interfaces auf einem Port basieren.

Konkrete Implementierungsvorstellung

Ein Port wird durch Betriebssystem- oder Middlewaremechanismus implementiert:

• CORBA
• DDS
• TCP/UDP-Socket
• Dateischnittstelle - verschiedene Syntax/Typen können konzeptionell als verschiedene Ports gesehen werden.
• Datenbank
• Shared Object/DLL-Interfaces
• RAMS-Segmente - via System V-IPC shared Memory, speicherabgebildete Dateien

Man kann hier zwischen Daten- und Service-Anbietern und -Nutzern unterscheiden. (nach VS Nov 2010):

• Bei nachrichtenorientierten Ports wie DDS usw. sind Sender Datenprovider und Empfänger/Consumenten Nutzer (require)
• Bei diensteorientierten Ports, sind die Server die Provider, die Clients sind die die "require"

Man bedenke, dass Dienste, genauer RPC-Dienste elementar aus nachrichtenbasierten Mechanismen zusammengesetzt sind: Sie empfangen Anfragen und liefern Antworten.

Bei der Verwendung der Notation muss man sich im klaren sein, welcher Natur die Ports sind und geeignete Abstraktionen wähen.

Der Vorschlag ist naheliegend, diese Portklassifikation auch in der UML graphisch zu unterscheiden.

Neu: Port hat einen Typ

Begriff: conjugated port: Dies ist die Gegenstelle, die die required -Interfaces provided hat und umgekehrt.

Um dies Abzuleiten zu können, haben die Ports nun einen Typ. Im Falle von "isConjugated" kann für den Port nun die Gegenstelle abgeleitet werden.

Kritik

Der Port konnte bisher auch sehr abstrakt aufgefasst werden. Je Wahl der Implementierung konnte eine 1:1 oder auch eine 1:n - Kommunikation dahinter gedacht werden. (1:n ist gut bei DDS oder bei Funkverbindungen oder so)

Damit könnte man beim Entwurf so vorgehen:

• Man identifiziert seine Komponenten
• Man identifiziert Interfaces und überlegt den Datenaustausch (1:1,1:n sowie vorraussichtliche Last)
• Man wählt eine Middleware passend zur Archtitektur
• Abhängig davon konkretisiert man die Ports und gruppiert die Interfaces

Unstrittig ist, das ein Port in der Komponente als Proxy realisiert wird kann (CORBA,DDS,...), und das dieses in der Implementierung ein Objekt bzw. Instanz einer Klasse ist.

Beim IBM RSA/UML2.2 bzw. bei UML2.4.1 wird man daher gezwungen, eine Klasse als Port-Type anzugeben. Diese Klasse ist dann mit den provided/required-Interfaces verbunden.
Sitzen jetzt mehrere Komponenten auf einem "Middlewarebus" wie ORB,DDS usw., dann kann nur noch der konkrete Portname diese Verwandschaft ausdrücken.

Integrating the RTI DDS with IBM Rational Rhapsody schlägt vor, dass die DDS-Middleware jeweils mit konjugierten Proxy-Objekten gebildet wird.

Es wird kritisiert, dass die Sichtweise nun zu frühzeitigen Konkretisierungen zwingt und mit den konjugierten Ports richtig 1:1-Verbindungen favorisiert und 1:n-Verbindungen wie DDS aussenvorlässt.

Komponentenbaukasten

Über das Schnittstellen- und Port-Konzept können die Komponenten zusammengeschaltet werden.

Deployment: Aufstellung, Stationierung, Verteilung
Die Komponenten können unabhängig aufgestellt (deployed) und abgebaut werden, zum Beispiel um ein System auf einen neuen Versionsstand zu bringen.

Sonstiges

KompoDSL - einfache DSL für Komponenten.