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:
-
Veränderliche Aspekte einer Domäne sind von den unveränderlichen Aspekten der Domäne zu trennen.
-
Die Schnittstelle ist von der Implementierung zu trennen.
-
Ä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.
-
Assets müssen auf jeder Wiederverwendungsebene erstellt werden. Es gibt folgende Wiederverwendungsebenen:
Basisklasse, Vererbungshierarchie, Aggregationshierarchie, Cluster, Framework, Komponente, Muster, generische
Architektur.
-
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
|