Qualität von Softwaresystemen - Ein pattern-basiertes Wissensmodell zur Unterstützung des Entwurfs und der Bewertung von Softwarearchitekturen

4 Pattern im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen (S. 103-104)

Das Konzept der Pattern umfasst die systematische Dokumentation von Entwurfswissen, das durch die Analyse von existierenden und erprobten Entwürfen gewonnen wird. Dieses Entwurfswissen kann im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen wiederverwendet werden, so dass der Prozess des Entwurfs bzw. der Bewertung effizienter und effektiver ausgeführt werden kann.

Das folgende Kapitel 4.1 diskutiert zunächst verschiedene Begriffsdefinitionen und erläutert den Bezugsrahmen des Pattern-Konzepts. Der Entwurf auf Basis von Pattern wird dargestellt und das Konzept der Pattern im übergreifenden Kontext der Softwareentwicklung positioniert. Die Anwendbarkeit des Pattern-Konzepts im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen wird im Wesentlichen durch die Struktur und den Aufbau der Pattern- Dokumentation sowie der verfügbaren Pattern-Auswahlprozesse beeinflusst. Daher werden im Anschluss die Dokumentation (Kapitel 4.2) und Auswahl von Pattern (Kapitel 4.3) untersucht. Das abschließende Kapitel 4.4 erläutert und bewertet die Nutzung des Konzepts im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen.

4.1 Konzept der Pattern

Das Konzept der Pattern entstand im Umfeld der objekt-orientierten Programmierung und einer Diskussion über die Produktivität der Entwickler, die eine derartige Programmiersprache nutzen. Gamma, Helm, Johnson und Vlissides motivieren die Entwicklung des Konzepts mit der Erkenntnis, dass es sehr schwierig ist, objekt-orientierte wiederverwendbare Software zu entwerfen: Ein Entwickler muss die „richtigen" Objekte identifizieren und sie in Klassen abbilden, Schnittstellen und Vererbungshierarchien definieren und die Beziehungen zwischen diesen Elemente identifizieren (vgl. [GHJV1995, S. 1]).

Ein Entwurf soll nicht nur die aktuellen Probleme und Anforderungen berücksichtigen, sondern flexibel und wiederverwendbar sein, so dass zukünftige Probleme und Anforderungen mit möglichst geringem Aufwand umgesetzt werden können. Derartige Entwürfe entstehen i. d. R. nicht innerhalb eines linearen, sondern innerhalb eines inkrementellen Entwurfsprozesses, d. h., ein Entwurf wird innerhalb eines Kreislaufs entwickelt, ausprobiert, angepasst und wieder ausprobiert (vgl. [GHJV1995, S. 1]). Im Kontext dieses inkrementellen Prozesses haben erfahrene Entwickler einen entscheidenden Vorteil: sie können das Entwurfsproblem auf Basis ihrer früheren Erfahrungen lösen, indem sie ein ähnliches Problem mit einer zugehörigen Lösung identifizieren, die sich als „gut" bewährt hat (vgl. [GHJV1995, S. 1, BMRS1996, S. 2]).

Der erfahrene Entwickler muss somit das Problem nicht grundlegend lösen und innerhalb eines inkrementellen Entwurfsprozesses weniger Zyklen durchlaufen, bis eine entsprechende Lösung gefunden wurde. Shaw und Garlan unterscheiden in diesem Kontext zwischen routinemäßigen Entwürfen (routine design) und innovativen Entwürfen (innovative design) (vgl. [ShGa1996, S. 7]). Ein routinemäßiger Entwurf enthält die Lösung eines bekannten Problems, indem große Teile einer vorherigen Lösung wiederverwendet werden. Ein innovativer Entwurf dagegen beinhaltet die Suche nach einer neuen Lösung für ein bisher unbekanntes Problem. Shaw und Garlan weisen darauf hin, dass in den meisten Ingenieurdisziplinen dieses Entwurfswissen systematisch erfasst und strukturiert wird, um den routinemäßigen Entwurf einfacher zu gestalten (vgl. [ShGa1996, S. 7]).

In vielen Bereichen der Softwareentwicklung erfolgt allerdings kein Rückgriff auf bereits vorhandenes Wissen, so dass der Entwurf meistens als innovativer Entwurf ausgeführt wird, obwohl Lösungen, die größtenteils wiederverwendet werden könnten, bereits existieren. Shaw und Garlan kritisieren aus diesem Grund auch den Begriff des Software Engineerings und schlagen vor, das existierende Wissen systematisch zu erfassen und zu organisieren, um die Entwicklung von Software tatsächlich als Ingenieurdisziplin zu etablieren (vgl. [ShGa1996, S. 7]).