Aufgabe: Komponentenspezifikation (SOA)
Diese Aufgabe spezifiziert die Details der Servicekomponenten, die ein Designsubsystem realisieren.
Disziplinen: Analyse und Design
Zweck

Ausarbeitung von Designsubsystemen, die während der Aufgabe Subsystemdesign (SOA) beschrieben wurden, um detaillierte Designs für Servicekomponenten bereitzustellen

Beziehungen
RollenPrimärer Ausführender: Zusätzliche Ausführende:
EingabenVerbindlich: Optional:
Ausgaben
Prozessverwendung
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:
  1. Eigenschaften oder Attribute
  2. Regeln
  3. Variationen
  4. Abhängigkeit von <anderen Komponenten>
  5. Kombination funktionaler und technischer Komponenten
  6. Bereitgestellte Services
  7. 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.

  1. Trennung und Modellierung der veränderlichen Aspekte von nicht veränderlichen Aspekten der Domäne: Zunehmende Variationen werden identifiziert, abgesondert, gekapselt und externalisiert.
  2. Erstellen von Typhierarchien für jeden Variationspunkt
  3. Zuordnen von Regeltypen zu jedem Variationstyp
  4. Implementierung von drei Abstraktionsebenen; Verwendung eines kumulierten Vererbungsmetamusters
  5. 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
  6. 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.

Zuordnung von Komponenten zu Schichten

Die Unterteilung in Schichten bietet folgende Vorteile:

  • Schichten helfen, ein IT-System mit Qualitätsattributen für Modifizierbarkeit und Portierbarkeit zu versehen. Eine Änderung an einer unteren Schicht, die keine Auswirkung auf die Schnittstelle hat, erfordert keine Änderung an einer darüber liegenden Schicht. So kann zum Beispiel jeder mit dem Standard J2EE™ konforme Anwendungsserver frei und ohne Änderung an der Software auf Anwendungsebene ersetzt werden. Eine Änderung an einer höheren Schicht hat keinen Einfluss auf die unteren Schichten, sofern sie sich nicht auf die Anforderungen an untere Schichten auswirkt. Änderungen an einem mehrschichtigen Softwaresystem, die keine Schnittstellen betreffen, sind generell auf nur eine Schicht begrenzt.
  • Schichten sind Teil der Planungsrolle, die die Architektur bei der Konstruktion des Systems spielt. Wenn Entwickler wissen, in welchen Schichten sich ihre Software befindet, kennen Sie die Services, auf die Sie in der Codierungsumgebung setzen können. Schichten können Arbeitszuordnungen für Entwicklerteams definieren. (Dies ist jedoch nicht immer der Fall.)
  • Schichten sind Teil der Kommunikationsrolle, die die Architektur inne hat. Bei einem großen System nimmt die Zahl der Abhängigkeiten unter den Modulen rasch zu. Die Organisation der Software in Schichten mit Schnittstellen ist ein wichtiges Tool bei der Verwaltung der Komplexität und beim Informationsaustausch mit den Entwicklern über die Struktur.
  • Schichten unterstützen die Analyserolle der Architektur. Sie können genutzt werden, um die Auswirkungen von Änderungen am Design zu analysieren.

Die Unterteilung in Schichten kann strikt oder nicht strikt sein. Ein striktes Schichtungsschema bedeutet, dass Komponenten nur Komponenten derselben Schicht oder aus den direkt darunter liegenden Schichten verwenden können. Bei einem nicht strikten Schichtungsschema können Komponenten derselben Schicht oder aus allen darunter liegenden Schichten verwenden. Beachten Sie jedoch, dass Komponenten generell keine Komponenten aus höheren Schichten verwenden sollten. Wenn Komponenten von Komponenten höherer Schichten abhängig sind, wird es schwierig, die Komponenten der höheren Schichten zu ersetzen, ohne die Komponenten der darunter liegenden Schicht ändern zu müssen. Weitere Informationen hierzu sowie zum Modellierungsverfahren für Schichten finden Sie im Konzept Lösungspartitionierung.

Es ist wichtig, dass Sie die hier beschriebenen Softwareschichten nicht mit denen des Dreischichtenmodells (3-Tier-Architekturmodell mit Front-End, Anwendungsschicht und Back-End) verwechseln. Die Zuordnung zu Maschinen in einer Verteilten Umgebung, der Datenfluss zwischen Elementen und das Vorhandensein bzw. die Nutzung von Kommunikationskanälen werden tendenziell Schichtdiagrammen nach dem Dreischichtenmodell dargestellt, die manchmal kaum von Diagrammen der Softwareschichten zu unterschieden sind. Schichtdiagramme nach dem Dreischichtenmodell enthalten häufig bidirektionale Pfeile, um eine Art der bidirektionalen Kommunikation anzuzeigen. In einem Diagramm der Softwareschichten ist bidirektionale (symmetrische Kommunikation) eher negativ. Darüber hinaus basiert die Zuordnung einer Komponente zu einer Schicht des Dreischichtenmodells auf den Platzierungsregeln, die beim Definieren der Operationsarchitektur berücksichtigt werden, und sie wird von den erforderlichen Systemmerkmalen auf Serviceebene bestimmt. Der Hauptunterschied zwischen Diagrammen der Softwareschichten und Abbildungen nach dem Dreischichtenmodell besteht darin, dass es in ersteren keinen konkrete Platzierung gibt, wohingegen in letzteren klar definierte Positionen vorhanden sind.

Faustregeln für die Unterteilung in Schichten

  • Alle Komponenten, die anwendungsunabhängige Geschäftsfunktionen bereitstellen, könnten einer Schicht zugeordnet werden. Anwendungsunabhängige Geschäftsfunktionen sind z. B. das "Kundenmanagement" und das "Produktmanagement" für einen Bereich verschiedener Anwendungen.
  • Alle Komponenten, die technische Funktionen wie Fehlerbehandlung, Authentifizierung, Protokollierung und Prüfung bereitstellen, könnten einer anderen (logischen) Schicht zugeordnet werden. Diese Komponenten sind geschäfts- und anwendungsunabhängig. In manchen Fällen kann die räumliche Nähe technischer und funktionaler Komponenten eine Zuordnung beider zu einer gemeinsamen Schicht erforderlich machen. Dies sind Entscheidungen hinsichtlich der Architektur und müssen als solche dokumentiert werden.
  • Middlewarekomponenten wie das Message-Queuing und relationale DBMS-Software können einer weiteren Schicht zugeordnet werden. Dies wird auch als die "Struktur" oder das "Gefüge" (Fabric) bezeichnet.

Beispiel

Die folgende Abbildung zeigt eine SOA-Sicht mit typischen (und tatsächlich empfohlenen) Schichten für die verschiedenen Elemente einer Lösung.

In diesem Schichtungsschema lässt sich recht einfach herausfinden, welcher Schicht unsere Komponenten zuzuordnen sind. Wir werden die relevanten Komponenten unseres Beispiels "Rent-a-Car" in die Servicekomponentenschicht stellen. Schauen Sie sich dazu die folgende Abbildung an. Da wir ein Modell mit strikter Schichtung wünschen, werden wir die UML-Komposition nutzen, um unsere Komponenten in die Servicekomponentenschicht aufzunehmen, und die Funktionalität der Servicekomponenten nur über Stellvertreter-Ports verfügbar machen, die dieselbe Schnittstelle wie die Servicekomponente selbst bereitstellen.

Weitere Informationen