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
|