Aufgabe: Komponentenklassendiagramm erstellen
Diese Aufgabe spezifiziert die Details der Servicekomponenten, die ein Designsubsystem realisieren.
Zweck

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

Beziehungen
RollenHauptrollen: Zusätzliche Rollen: Unterstützende Rollen:
EingabenVerbindlich: Optional: Extern:
  • Ohne
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
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

Eigenschaften
Mehrere Vorkommen
Ereignisgesteuert
Fortlaufend
Optional
Geplant
Wiederholt anwendbar
Weitere Informationen