Qualität von Softwaresystemen (eBook)

Dr. Stefan Malich promovierte bei Prof. Dr. Stefan Eicker am Lehrstuhl für Wirtschaftsinformatik und Software-Technik der Universität Duisburg-Essen. Er hat langjährige Erfahrung als IT-Berater und Software-Entwickler und war u. a. bei der Unternehmensberatung Accenture GmbH tätig.

Geleitwort 6
Vorwort 7
Inhaltsübersicht 9
Inhaltsverzeichnis 11
Abbildungsverzeichnis 15
Tabellenverzeichnis 18
Abkürzungsverzeichnis 19
1 Einleitung 21
1.1 Problemstellung 21
1.2 Zielsetzung 23
1.3 Forschungsansatz 24
1.4 Aufbau der Arbeit 27
2 Grundlagen und Bezugsrahmen des Entwurfs von Softwarearchitekturen 29
2.1 Begriffsdefinitionen 29
2.2 Bezugsrahmen 35
2.3 Bedeutung der Softwarearchitektur 41
2.4 Einflussfaktoren 44
2.5 Dokumentation von Softwarearchitekturen 48
2.6 Verwandte Arbeiten 53
2.7 Zusammenfassung 64
3 Bewertung von Softwarearchitekturen 67
3.1 Ziele und Annahmen der Bewertung 67
3.2 Qualität von Softwareprodukten und -architekturen 69
3.3 Bewertungsmethoden für Softwarearchitekturen 94
3.4 Zusammenfassung 120
4 Pattern im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen 123
4.1 Konzept der Pattern 123
4.2 Dokumentation von Pattern 130
4.3 Konzepte zur Auswahl von Pattern 149
4.4 Pattern im Kontext des Entwurfs und der Bewertung 156
4.5 Zusammenfassung 158
5 Entwicklung eines pattern-basierten Wissensmodells 159
5.1 Entwicklung des Wissensmodells 159
5.2 Entwicklung der Vorgehensweise 194
5.3 Validierung der Vorgehensweise und des Wissensmodells 205
5.4 Verwendung der Wissensbasis 216
5.5 Zusammenfassung 224
6 Schlussbetrachtung 225
6.1 Zusammenfassung der Ergebnisse 225
6.2 Weiterer Forschungsbedarf 226
6.3 Ausblick 230
Literaturverzeichnis 232
Anhang A 241
Anhang B 245

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]).