Einführung
Durch das Zerlegen einer Servicekomponente in ihre funktionalen und technischen Bestandteile haben wir die von der
Servicekomponente für die funktionalen Zuständigkeiten des Subsystems bereitgestellte Funktionalität delegiert.
Funktionale Komponenten stellen die erforderliche Geschäftsfunktionalität zur Verfügung, technische Komponenten dagegen
die generische Funktionalität, zu der Authentifizierung, Fehlerbehandlung, Überwachung, Protokollierung usw. gehören.
Die generische Funktionalität ist operational und nicht funktional ausgerichtet.
Ein Servicemodell ist ein Artefakt der Designzeit. Als solches interagiert es nicht direkt mit der
Serviceimplementierung. Die tatsächliche Implementierung eines Service oder einer Servicegruppe wird von der
Realisierung einer Servicespezifikation durch eine Servicekomponente ausgeführt. Die Servicespezifikation stellt den
Implementierungsvertrag bereit. Welche Technologie oder welches Verfahren für die Implementierung des Service verwendet
wird, ist irrelevant, sofern der Vertrag erfüllt wird. Im Konzept Serviceorientierte Architektur wurde die folgende Abbildung vorgestellt, die
die Beziehung zwischen den identifizierten Services und den Komponenten und Objekten, die die Implementierung dieser
Services bereitstellen, demonstriert.
So ist erkennbar, wie das Designmodell von RUP verwendet werden kann, um das Design der
Komponenten- und Objektschichten zu erfassen. Zu diesen gehören Implementierungsmodelle und -artefakte, die Details der
Objektschicht und der zugeordneten Implementierungs- und Deployment-Artefakte erfassen. Wichtige Aspekte der Beziehung
zwischen dem Servicemodell und dem Modell des Komponentendesigns sind
folgende: Die Servicespezifikationen stellen Verträge dar, die erfüllt werden müssen; Operationen, die in
Spezifikationen identifiziert werden, müssen auf AS-IS-Basis implementiert werden, und Servicekonsumenten verwenden
dasselbe Modell, um die Schnittstelle und das Verhalten der Services, die sie verwenden möchten, zu verstehen. Im
Grunde genommen gibt es eine direkte 1:1-Beziehung zwischen der Servicespezifikation und einem
Implementierungsartefakt, das für den Service als Eingangspunkt der Erstimplementierung fungiert.
Prüfen Sie z. B. das folgende Diagramm eines Serviceproviders, das die Details von Modellelementen, die in dieser
Definition verwendet werden, zeigt.
Der Schlüssel zur Verwendung dieser Servicekomponente ist, sie direkt zum Servicemodell zurückzuverfolgen. Am
einfachsten ist es, wenn Sie den Umstand nutzen, dass das Element der Servicespezifikation eine UML-Schnittstelle ist,
die von der Servicekomponente realisiert wird und so die Konformität des Elements mit der strukturellen Spezifikation
sicherstellt. Das Ergebnis wäre folgendes:
Es liegt jetzt in der Zuständigkeit desjenigen, der die Komponente implementiert, eine Gruppe von Komponenten und
Klassen zu definieren, die das Verhalten der entstehenden Komponente bestimmen.
Arten von Servicekomponenten
Funktionale Komponenten
Die Komposition dieser funktionalen Komponenten zu einer übergeordneten Servicekomponente ist keine rein strukturelle
Zusammensetzung. Es wird auch ein Ablauf definiert, d. h. die Kollaboration der funktionalen Komponenten, um die
Funktionalität zur Unterstützung des Geschäftsprozesses bereitzustellen. Wie wir bereits festgestellt haben, wird die
Funktionalität dieser geschäftsbezogenen Komponenten über die definierten Services aktiviert (die von der
detaillierteren Objektstruktur oder herkömmlichen Systemstruktur der Komponente implementiert werden).
Es ist wichtig, dass Sie erkennen, dass dieser Schritt auch traditionelle OOAD-Aktivitäten umfasst. Wir haben einen
fokussierten und gut gegliederten Geltungsbereich für die Steuerung des Objektdesigns. Beim traditionellen
objektorientierten Design gibt es eine Tendenz, größere und abhängigere Objektdiagramme zu erstellen. Wenn auf die
Identifikation von Funktionsbereichen innerhalb des Geschäfts jedoch eine Subsystemanalyse folgt, liegt ein sehr klar
definierter Geltungsbereich vor, auf den wir uns konzentrieren und unsere Designbemühungen ausrichten können. Diese
Bemühungen münden dann in einer Reihe sehr lose miteinander verbundener Objektmodelle (durch Systemanwendungsfälle
ausgelöste Klassendiagramme und Ablaufdiagramme).
Technische Komponenten
Technische Komponenten werden wie funktionale Komponenten zu übergeordneten
Servicekomponenten zusammengesetzt. Technische Komponenten wie die
Authentifizierung, Protokollierung und Berichtserstellung können geschäftsprozessübergreifend verwendet werden. Diese
allgemeinen Komponenten werden für die Infrastruktur zur Unterstützung der funktionalen Komponenten benötigt. Ein
Hauptgrund für Variationen bei Geschäftsprozessen sind Geschäftsregeln. Dies ist in der folgenden Abbildung
"Unternehmenskomponentenmuster" dargestellt. Diese Variationen werden
in der Regel beim variationsorientierten Design erfasst.
Servicekomponentenmuster
Es wurde gesagt, dass die Servicekomponente einfach die Servicespezifikation realisiert. Allerdings hat der
Implementierer wenig Unterstützung, wenn er von einer allgemein definierten Servicedefinition zu einer Gruppe
differenzierter Implementierungsklassen und -artefakte wechselt, die erforderlich sind, um das Verhalten des Service zu
bestimmen. In diesem Zusammenhang verlässt er sich üblicherweise auf Muster, die der entstehenden Servicekomponente
eine Struktur geben, in Form eines anfänglichen Framework oder spezifischer Muster, um bestimmte strategische
Anforderungen zu berücksichtigen.
Musterauswahl, NFR-gesteuert, Architektur [mehr]
Die zusätzlichen Stereotypen, die hier eingeführt werden, sind im Artefakt Servicekomponente beschrieben.
Basismuster für Servicekomponenten
Bei der Definition der anfänglichen Struktur eines Service wird das folgende Muster als Ausgangspunkt für die Anpassung
und Fertigstellung bereitgestellt.
Die Elemente dieses Musters sind:
-
Fassadenkomponente. Die Fassade realisiert dieselbe Schnittstelle wie die Servicekomponente selbst und
stellt grundlegende Funktionen für die Nachrichtenvalidierung bereit, bevor sie die Anfrage zur Ausführung an die
pro Operation verwendeten Komponenten übergibt. In diesem Fall wird die Komponente zur Klarstellung mit dem
Stereotyp <<Facade>> versehen.
-
Pro Operation verwendete Komponente. Aufgrund der Unterteilung der Services ist es in den meisten Fällen
nützlich, eine separate Komponente bzw. Klasse für die Implementierung der einzelnen vom Service bereitgestellten
Operationen zu haben.
Im Folgenden wird die Sicht der zusammengesetzten Struktur dieses Musters veranschaulicht. In diesem Falle wird die
Fassade an die Servicekomponente selbst delegiert. An sich werden Konsumenten, die Operationen für die
Servicekomponente aufrufen, von der Fassadenkomponente bedient. Beachten Sie, dass auch UML-2.0-Ports verwendet werden
können, um die Schnittstellen verfügbar und die Delegierung mit Konnektoren explizit zu machen.
Servicekomponentenmuster für eine Einzeloperation
In einigen Fällen, in denen Services mit mehreren Operationen im Servicemodell identifiziert werden, ist es besser, die
Operationen einzeln als eigenständige Services zu implementieren und die Sichten für die logischen und die physischen
Services zu trennen. Ein solches Muster hat Vorteile hinsichtlich der Flexibilität, der Quellenermittlung, der
Versionssteuerung und der Weiterentwicklung, verzichtet jedoch auf die Kategorie der Schnittstelle zu Gunsten eines
Service als Gruppe zusammengehöriger Operationen.
Bei der Modellierung von Servicekomponenten gemäß diesem Muster wird nur eine <<Servicekomponente>>
verwendet, die eine Schnittstelle mit einer Einzeloperation realisiert. Die Benennung erfolgt in Übereinstimmung mit
allgemeinen Konventionen, die nachfolgend dargestellt sind.
In diesem Fall gibt es, wie erwähnt, keine direkte Realisierung der ursprünglichen Servicespezifikation durch ein
Element im obigen Muster. Daher scheint es lohnend zu sein, ein Element in das Modell einzuführen, das die
Rückverfolgbarkeit zur Servicespezifikation gewährleistet. Im folgenden Beispiel wird eine Komponente mit dem Stereotyp
<<Subsystem>> eingeführt, die laut Beschreibung die Servicespezifikation implementiert und auch Eignerin
der oben beschriebenen Elemente ist.
Dieses Muster führt auch nicht die Komponente <<Fassade>> ein, da Servicekonsumenten die Verantwortung
dafür tragen, die Services, die sie nutzen, zu identifizieren.
Muster für vermittelte Operationen
Wenn es eine Möglichkeit gibt, die Anfrage eines Servicekonsumenten zur Ausführung an eine Auswahl von
Operationskomponenten weiterzuleiten, kann das Muster mit einem Mediator erweitert werden, um diese Nachrichten
weiterzuleiten. Sehen Sie sich dazu die folgende Abbildung an. Beachten Sie, dass die Komponente bzw. Klasse zur
Klarstellung mit dem Stereotyp <<Mediator>> versehen wird. Der exakte Mechanismus für die Vermittlung ist
nicht definiert. Eine statische Gruppe von Implementierungen könnte vorab definiert werden, eine Registry könnte
ebenfalls verwendet werden, um eine Zuordnung zu einer bestimmten Implementierung vorzunehmen, basierend auf Konsument,
Anfragenachricht usw. Dieses Muster ist nicht für die Verwendung mit dem Muster für Einzeloperationen vorgesehen.
Das betrifft auch die Sicht für die zusammengesetzte Struktur der Servicekomponente. Wie unten dargestellt, verläuft
die Mediatorverbindung über die Fassade, die sie verwendet, um Aufrufe an die Operationskomponente zu leiten.
Wenn eine Registry außerhalb des Mediators selbst verwendet wird, ist es eventuell nicht möglich, in den verschiedenen
Teilen des zusammengesetzten Strukturdiagramms statische Abhängigkeiten zwischen Mediator, Operationskomponenten oder
Konnektoren aufzuzeigen. Wie also kann eine Abhängigkeit des Mediators von den vermittelten Operationskomponenten
modelliert werden? Im folgenden Diagramm wurde eine Schnittstelle eingeführt, die von jeder Operationskomponente
implementiert werden soll. Anschließend kann die Verwendung vom Mediator bis zur Schnittstelle, wie unten dargestellt,
modelliert werden.
Außerdem wird die Beziehung im zusammengesetzten Strukturdiagramm geändert, das einen neuen, durch die Schnittstelle
typisierten Teil enthält. Die Multiplizität zwischen dem Mediator und den Operationskomponenten im Konnektor wird wie
in der folgenden Abbildung dargestellt.
Komponenten für Datenzugriff
Wenn Serviceoperationen gemeinsame Datenanforderungen haben, kann es außerdem nützlich sein, die spezifischen
Komponenten hervorzuheben, die Datenmanagementfunktionen für die Implementierung bereitstellen. Beachten Sie, dass die
Komponente bzw. Klasse zur Klarstellung mit dem Stereotyp <<Data Access>> (Datenzugriff) versehen wird.
Unternehmenskomponentenmuster
Das folgende Unternehmenskomponentenmuster zeigt die Servicekomponente als Fassade für die zugrunde liegenden
funktionalen und technischen Komponenten. Services werden an der Außengrenze der Servicekomponente, auf der
Komponentenfassade, verfügbar gemacht. Serviceanfragen auf der Fassade werden an einen Mediator gesendet, der die
Nachricht dann an die entsprechende funktionale oder technische Komponente weiterleitet.
Unternehmenskomponentenmuster
Die Abhängigkeiten der funktionalen Komponenten von den technischen Komponenten und ihre Anforderungen an die
technischen Komponenten sind unten am Beispiel "Rent-a-Car" dargestellt.
Servicekomponente "Reservierung" von Rent-a-Car unter Verwendung des Musters
Unternehmenskomponente
Aus den Subsystemkomponentenmodellen wird das Modell der funktionalen Komponenten zusammengestellt, das die
Abhängigkeit der funktionalen Komponenten von den technischen Komponenten und die Wechselwirkungen zwischen den
funktionalen Komponenten zeigt. Untergeordnete, in der Hierarchie als Blattknoten dargestellte Prozesse, die der
Subsystemfassade zugeordnet sind, müssen als vom Subsystem bereitgestellte Services spezifiziert werden. Diese
untergeordneten Prozesse werden durch eine detailliertere Gruppe von Systemanwendungsfällen unterstützt und
implementiert, die in die Struktur des Subsystems eingebunden sind. Die funktionalen Komponenten bilden die
Voraussetzung für die Realisierung der Anwendungsfälle, sind jedoch hinsichtlich ihrer Infrastrukturanforderungen auf
die technischen Komponenten und Dienstprogramme angewiesen.
|