Aufgabe: Komponentenspezifikation (SOA) |
|
 |
Diese Aufgabe spezifiziert die Details der Servicekomponenten, die ein Designsubsystem realisieren. |
|
Zweck
Beziehungen
Rollen | Hauptrollen:
| Zusätzliche Rollen:
| Unterstützende Rollen:
|
Eingaben | Verbindlich:
| Optional:
| Extern:
|
Ausgaben |
|
Hauptbeschreibung
In einer SOA-basierten Lösung verwendete Services werden mit Hilfe von Servicekomponenten realisiert, die zu einem Subsystem gehören, das
auf eine bestimmte Geschäftsfunktion ausgerichtet ist. Jede Servicekomponente ist für die Qualität der von ihr
realisierten Services zuständig. Als unternehmensweite Assets müssen die Servicekomponenten finanziert, kontrolliert
und gewartet werden. Verfügbarkeit, Lastausgleich, Sicherheit, Leistung, Versionssteuerung und ordnungsgemäßer Betrieb
der Servicekomponente müssen durch ein etabliertes Infrastrukturmanagement sichergestellt werden. Die Servicekomponente
selbst ist für die Implementierung der Funktionalität einer Reihe von Services verantwortlich und muss die
Servicequalität gewährleisten. Funktionale Komponenten und technische Komponenten können jeweils für verschiedene
Servicekomponenten genutzt werden.
|
Schritte
Komponentenschnittstellen modellieren
Komponenten sollten Operationen nicht direkt bereitstellen. Dies gilt insbesondere für Servicekomponenten. Stattdessen
sollten sie Schnittstellen zur Beschreibung einer Reihe von Operationen verwenden und dann die Schnittstelle zur
Verfügung stellen bzw. realisieren. Eine allgemeine Beschreibung hierzu finden Sie im RUP, unter den Aufgaben Subsystemdesign (SOA) und Designelemente identifizieren.
Beispiel
In unserem Beispiel "Rent-a-Car" haben wir (mittels Subsystemanalyse) festgestellt, dass eine Servicekomponente für
Reservierungen benötigt wird. Um ein wiederverwendbares und flexibles Design zu erhalten, können wir auch eine
entsprechende Reservierungsschnittstelle erstellen oder die Servicespezifikation (von der Aufgabe Servicespezifikation) nutzen, um die Schnittstelle für unsere
Servicekomponente zu beschreiben. Die Komponente wird jede bereitgestellte Schnittstelle realisieren (UML-Terminologie)
und kann über die UML-Verwendungsbeziehung auch ihre Abhängigkeit von anderen Komponentenschnittstellen anzeigen.
Vergleichen Sie dazu die folgende Abbildung.
Beachten Sie, dass die Details der Schnittstellen zur besseren Verdeutlichung weggelassen wurden.
|
Komponentenattribute modellieren
In diesem Schritt werden wir die Details der einzelnen Servicekomponenten definieren. Dazu gehören Attribute, Services,
Richtlinien und Regeln. Die Vorlage für die Dokumentation der Servicekomponentenspezifikation wird die folgenden Attribute
enthalten:
-
Eigenschaften oder Attribute
-
Regeln
-
Variationen
-
Abhängigkeit von <anderen Komponenten>
-
Kombination funktionaler und technischer Komponenten
-
Bereitgestellte Services
-
Erforderliche Services
|
Komponentenereignisse und Nachrichten modellieren
Während dieser Aktivität werden Ereignisse identifiziert, die die Komponente erkennen muss und auf deren Eintreten sie
reagieren muss. Ankommende und abgehende Komponentennachrichten werden ebenfalls spezifiziert. Services, die von Änderungen
an Daten gesteuert werden, müssen datenzentrisch betrachtet werden. Geschäftsprozesse, die nicht zum Umfang der
servicebasierten Lösung gehören, müssen identifiziert und für die Generierung von Ereignissen sowie für die Bereitstellung
von Daten für die Verbraucherservices der serviceorientierten Lösung bewertet werden. Mehrere Geschäftsprozesse innerhalb
eines Pakets eines unabhängigen Softwareanbieters könnten beispielsweise einen neuen Client hinzufügen. Möglicherweise
werden die für den Client erfassten Daten nicht in allen Fällen identisch sein, sondern vom spezifischen Kontext des
jeweiligen Geschäftsprozess abhängen. Verbraucherservices, die über einen Providerservice vom Vorhandensein neuer Clients
erfahren, müssen in der Lage sein, den neuen Clientservice unabhängig davon aufzurufen, welcher Geschäftsprozess diesen
Service generiert. |
Komponenteninterne Struktur modellieren
Während dieser Aktivität muss auf jeden Fall ein Klassendiagramm erstellt werden, das die Beziehungen zwischen
den funktionalen und technischen Komponenten der einzelnen Servicekomponenten zeigt. In diesem Stadium kommt die
Standard-UML-Modellierung zur Anwendung. Die Verwendung von Mustern wird empfohlen, um das resultierende Objektdiagramm
so zu strukturieren, dass es erweiterbar und offen für Änderungen ist. Falls bereits absehbar ist, dass sich zahlreiche
Änderungen ergeben werden, sollten Sie auf dieser Stufe eine Variabilitätsanalyse durchführen.
Wie bereits in der vorherigen Aufgabe beschrieben, ist es klug, die Verfahren der Variabilitätsanalyse zu nutzen, wenn Sie Entwürfe für künftige Änderungen
vorbereiten oder mit wesentlichen Auswirkungen künftiger Geschäftsänderungen auf Design und Struktur des IT-Systems
rechnen müssen. Diese Verfahren klammern die Gemeinsamkeiten aus und externalisieren Unterschiede mit Hilfe von
Designmustern. Die bereits festgestellten Gemeinsamkeiten und Unterschiede können als Ausgangspunkt verwendet und durch
allgemeine Designmuster wie Strategie, Status [i], Regelobjekt [ii], Typobjekt usw. erweitert werden.
Eine während des detaillierten Designs durchgeführte Analyse identifiziert Gemeinsamkeiten und fokussiert sich auf die
Erstellung modularer Variationen. Sie wendet sechs Prinzipien an, die helfen, veränderliche von kaum veränderlichen
Aspekten von Softwaresystemen zu trennen sowie die Änderungen zu isolieren und zu kapseln.
-
Trennung und Modellierung der veränderlichen Aspekte von nicht veränderlichen Aspekten der Domäne: Zunehmende
Variationen werden identifiziert, abgesondert, gekapselt und externalisiert.
-
Erstellen von Typhierarchien für jeden Variationspunkt
-
Zuordnen von Regeltypen zu jedem Variationstyp
-
Implementierung von drei Abstraktionsebenen; Verwendung eines kumulierten Vererbungsmetamusters
-
Beginn bei Wiederverwendungsebenen oberhalb der Objektebene und Erstellung von Assets auf jeder dieser Ebenen;
Aufbau kleiner Frameworks um Variationspunkte, die im allgemeinen nicht mehr als 7 Klassen (+-2 Klassen) haben
sollten
-
Jedes Wiederverwendungselement zeichnet sich durch ein eigenes Verhalten aus. Externalisierung des Verhaltens
in Form konfigurierbarer Daten, die in die Anwendung eingelesen werden können, um Softwareverknüpfungen zu
ermöglichen.
[i] Erich
Gamma, Richard
Helm, Ralph
Johnson, John
Vlissides, Design Patterns, Addision-Wesley 1994.
[ii] Arsanjani, A., Rule Object: A Pattern Language for Flexible Modeling and Construction of Business Rules,
Washington University Technical Report number: wucs-00-29, Proceedings of the Pattern Languages of Program Design, 2000
|
Komponentenablauf modellieren
Während dieser Aktivität wird der interne Ablauf der Steuerung innerhalb der Servicekomponente identifiziert. Er kann
als Ablauf- oder Aktivitätsdiagramm dargestellt werden.
Hinweis zu unabhängigen Softwareanbietern: Der interne Ablauf einer Komponente in einem Paket eines unabhängigen
Softwareanbieters kann verfügbar und/oder konfigurierbar sein. Es gibt aber auch Pakete, bei denen dies nicht der Fall
ist. Sind Objekte innerhalb der Komponente des unabhängigen Softwareanbieters verfügbar und konfigurierbar, kann ihr
Verarbeitungsablauf angepasst und auf die Lösung abgestimmt werden. Bei einem solchen Vorgehen sollten jedoch Fragen
einer kontinuierlichen Pflege/Wartung berücksichtigt werden, die sich daraus ergeben könnten. In vielen Fällen wird es
nicht möglich und auch gar nicht notwendig sein, den komponenteninternen Ablauf in Paketen unabhängiger
Softwareanbieter zu identifizieren. In solchen Fällen sollte die Komponente des unabhängigen Softwareanbieters als
Blackbox angesehen werden, für die nur verfügbar gemachte und realisierte Services dokumentiert sind.
|
|
Eigenschaften
Mehrere Vorkommen |  |
Ereignisgesteuert |  |
Fortlaufend |  |
Optional |  |
Geplant |  |
Wiederholt anwendbar |  |
Weitere Informationen
© Copyright IBM Corp. 1987, 2006. Alle Rechte vorbehalten.
|
|