Richtlinie: Variabilitätsanalyse
Bei der Variabilitätsanalyse wird ein Modell erstellt, das die stabileren Aspekte des Domänenmodells von den Aspekten trennt, die Änderungen unterworfen sind. Dies ermöglicht die Externalisierung erwarteter Änderungsformen und der zugehörigen Regeln, um künftige Änderungen am vorhandenen Design ohne störende Eingriffe einbringen zu können.
Beziehungen
Hauptbeschreibung

Einführung

Der Servicedesigner muss Klarheit darüber haben, dass es bei der Erstellung einer Servicespezifikation darum geht, zwei gegenläufige Tendenzen in Einklang zu bringen.

  • Spezialisierung: Es muss sichergestellt werden, dass ein Service die an ihn gestellten Anforderungen erfüllt und die in der Aktivität Analyse vorhandener Assets identifizierte Funktion ausführt.
  • Generalisierung: Es muss sichergestellt werden, dass ein Service weitestgehend wiederverwendbar ist, so dass künftige Anforderungen keine größeren Designänderungen an vorhandenen Services notwendig machen.

Zur Lösung dieser Aufgabe kann der Designer Verfahren anwenden, die allgemein unter dem Begriff "Analyse der Gemeinsamkeiten und Unterschiede" zusammengefasst werden. Diese Verfahren sind seit einiger Zeit bekannt und dokumentiert, insbesondere im Bereich der Musterformulierung [Coplien, Gabriel] und der Entwicklung von Softwareproduktlinien [GBS, JGBS01, JB02, MRR04, Parnas, SBM01]. In diesen Bereichen muss der Designer ebenfalls die beiden genannten Tendenzen miteinander vereinbaren; er muss die Variabilität als Parameter für ein Muster erfassen um die Anwendbarkeit des Musters in verschiedenen Situationen zu ermöglichen.

In der Literatur zu Mustern beschreibt [Coplien] die Gemeinsamkeiten als den "Wesensgehalt einer Abstraktion" und die Unterschiede als die "Würze des Lebens". [Gabriel] beschreibt das Verhältnis zwischen Gemeinsamkeiten und Unterschieden dagegen etwas konkreter: "Eine gute Abstraktion muss die einheitlichen Aspekte der Lösung als Ganzes erfassen und gleichzeitig die Variabilität der einzelnen Elemente spezifizieren".

Beim Programmieren ist die Abstrahierung der Prozess der Identifikation allgemeiner Muster, zu denen es systematische Variationen gibt. Eine Abstraktion stellt das allgemeine Muster dar und bietet Möglichkeiten für die Spezifizierung der zu verwendenden Variante.

[Parnas] definiert mit ähnlichen Worten eine Familie von Programmen, die auf den einheitlichen Merkmalen der Gruppe und den spezifischen Merkmalen der zur Gruppe gehörenden Elemente basiert. (Wir würden eine solche Familien heute als Softwareproduktlinien bezeichnen.

Eine Gruppe von Programmen kann als eine Familie angesehen werden, wenn es lohnend ist, zunächst die allgemeinen Merkmale der Gruppe zu untersuchen und dann die speziellen Eigenschaften der einzelnen "Familienmitglieder" zu bestimmen.

Variabilität erfassen

Viele Systeme werden mit sehr wenig Voraussicht erstellt. Die Integration von Änderungen, die sich durch neue Anforderungen ergeben, findet oft zu wenig Berücksichtigung. Durch die Analyse der Gemeinsamkeiten und Unterschiede wird ein flexibles Design erstellt, das in Bezug auf Änderungen weit anpassungsfähiger ist. Durch den Prozess der Externalisierung wird die feste Codierung oder das starre Entwerfen von Domänenaspekten, die voraussichtlich Änderungen unterworfen sein werden, vermieden. Die sich schneller verändernden funktionalen und strukturellen Aspekte der Domäne werden von den stabileren oder unveränderlichen Aspekten getrennt. Dieses Verfahren lässt bei neuen Anforderungen die Weiterentwicklung und das Wachsen des Systemdesigns ohne störende Eingriffe zu. Während der Analyse werden Gemeinsamkeiten und Unterschiede in Typhierarchien modelliert. Jeder Variabilitätspunkt wird identifiziert und externalisiert. Die Instanzen der Variation, z. B. Organisationskunde und Einzelkunde, können als zwei Realisierungen eines Kundentyps modelliert und dann bei Bedarf erweitert werden. Der externalisierte Typ (z. B. der Kundentyp) wird Kundenregeln zugeordnet, die für alle Kunden gelten, und Weiterentwicklungen/Erweiterungen für jeden Kundentyp über bestimmte Regeltypen ermöglichen.

Der erste Schritt der Analyse ist die Identifikation der Abhängigkeiten vom Typ aus funktionaler (statischer) Sicht sowie aus Prozesssicht (dynamischer Sicht). Die Identifikation von Prozesstypen, die sich auf Entitätstypen stützen (funktional), ist ein gutes heuristisches Verfahren für die Designumstrukturierung.

  • Identifizieren Sie allgemeine Elemente von Funktion und Prozess (z. B. eines Prozesses im Reservierungsgeschäft).
  • Trennen Sie veränderliche Aspekte von relativ konstanten Aspekten. Identifizieren Sie Schlüsseltypen für Funktion und Prozess, die sich voraussichtlich ändern werden oder abhängig sind (der Reservierungstyp ist vom Kundentyp abhängig; eine Änderung des Kundentyps kann eine Änderung des Reservierungstyps zur Folge haben).
  • Externalisieren Sie die Variationen und erstellen Sie Typhierarchien mit bekannten Instanzen (bevorzugt wird der Häufigkeitstyp oder die Regelmäßigkeit sowie die Angabe, ob die Partei eine Organisation oder eine Einzelperson ist).

Diese Variabilitätspunkte sind ein entscheidendes Element bei der Erstellung flexibler und anpassungsfähiger Systeme. Durch Externalisierung der Variabilitätspunkte können diese modifiziert werden, ohne das übrige Design zu beeinträchtigen. Der sich langsam ausbreitende Effekt von Änderungen bleibt so durch die Variabilitätspunkte überschaubar und eingeschränkt. Ein UML-Klassendiagramm, das diese Hierarchie darstellt, kann als Roadmap für ein detailliertes Design und letztlich auch für die Implementierung verwendet werden.

Für ein Design mit Gemeinsamkeiten und Unterschieden gelten folgende Basisprinzipien:

  1. Veränderliche Aspekte einer Domäne sind von den unveränderlichen Aspekten der Domäne zu trennen.
  2. Die Schnittstelle ist von der Implementierung zu trennen.
  3. Änderungen sind zu vergegenständlichen. Wenn ein Element der Domäne ständig in Fluss ist, kann es notwendig sein, dieses Element in einer Klasse (oder einer höheren Ebene der Wiederverwendung) zu vergegenständlichen.
  4. Assets müssen auf jeder Wiederverwendungsebene erstellt werden. Es gibt folgende Wiederverwendungsebenen: Basisklasse, Vererbungshierarchie, Aggregationshierarchie, Cluster, Framework, Komponente, Muster, generische Architektur.
  5. Jedes Wiederverwendungselement hat neben den Metadaten, die für eine reflektierende und anpassungsfähige Selbstbeschreibung des Elements bei Laufzeitabfragen von Servicefunktionalität notwendig sind, eigene Verhaltensregeln.

Referenzliteratur

[Arsanjani] A. Arsanjani, 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

[Coplien] J. O. Coplien, Multi-Paradigm Design for C++, Addison-Wesley Professional, 1. Auflage, 1998

[Gabriel] R. P. Gabriel, Patterns of Software: Tales from the Software Community, Oxford University Press, 1998

[GBS] J. van Gurp, J. Bosch und M. Svahnberg, Managing Variability in Software Product Lines, http://citeseer.ist.psu.edu/568368.html

[GHJV] E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns, Addision-Wesley 1994

[JGBS01] J. van Gurp, J. Bosch und M. Svahnberg, On the notion of variability in software product lines, in Proceedings 2nd Working IEEE / IFIP Conference on Software Architecture (WICSA), Seiten 45-54, IEEE Computer Society, 2001, http://citeseer.ist.psu.edu/vangurp01notion.html

[JB02] M. Jaring, J. Bosch, Representing Variability in Software Product Lines: A Case Study, wird erscheinen in Second Product Line Conference (SPLC-2), San Diego CA, 19.-22. August 2002, http://citeseer.ist.psu.edu/jaring02representing.html

[MRR04] Jürgen Meister, Ralf Reussner und Martin Rohde, Managing Product Line Variability by Patterns, http://se.informatik.uni-oldenburg.de/pubdb_files/pdf/ManagingProductLineVariabilityByPatterns-Final.pdf

[Parnas] D. L. Parnas, On the Design and Development of Program Families, IEEE Transactions on Software Engineering, SE-2(1): 1-9, 1976

[SBM01] A. Stephenson, D. Buttle und J. McDermid, Extending Commonality Analysis for Embedded Control System Families, Referate in Computer Science, Band 1951, 2001, http://citeseer.ist.psu.edu/stephenson51extending.html

[SGB01] M. Svahnberg, J. van Gurp, J. Bosch, A Taxonomy of Variability Realization Techniques, veröffentlicht Juni 2001, http://citeseer.ist.psu.edu/svahnberg01taxonomy.html