Qualität von Softwaresystemen : ein pattern-basiertes Wissensmodell zur Unterstützung des Entwurfs und der Bewertung von Softwarearchitekturen 9783834997265, 3834997269 [PDF]

Zitiervorschau

Stefan Malich Qualität von Softwaresystemen

GABLER EDITION WISSENSCHAFT

Stefan Malich

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

Mit einem Geleitwort von Prof. Dr. Stefan Eicker und Prof. Dr. Reinhard Jung

GABLER EDITION WISSENSCHAFT

Bibliografische Information Der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar.

Dissertation Universität Duisburg-Essen, 2007

1. Auflage 2008 Alle Rechte vorbehalten © Betriebswirtschaftlicher Verlag Dr. Th. Gabler | GWV Fachverlage GmbH, Wiesbaden 2008 Lektorat: Frauke Schindler / Anita Wilke Der Gabler Verlag ist ein Unternehmen von Springer Science+Business Media. www.gabler.de Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Umschlaggestaltung: Regine Zimmer, Dipl.-Designerin, Frankfurt/Main Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier Printed in Germany ISBN 978-3-8349-1030-1

Geleitwort Der Einsatz software-intensiver Systeme prägt immer weiter gehender die Abläufe/Prozesse in Unternehmen und Verwaltungen und beeinflusst überdies – teilweise unbemerkt – auch das Leben von Privatpersonen. Durch die Durchdringung von Wirtschaft und Gesellschaft mit software-intensiven Systemen wächst allerdings auch die Abhängigkeit von ihnen; entsprechend bedeutend sind ihre Anforderungskonformität und ihre Qualität. Da die IT-Systeme inhärent komplex sind, kann ihre Anforderungskonformität und eine adäquate Qualität nur durch einen wohl-strukturierten Entwurf der jeweils zugrunde liegenden Softwarearchitektur sichergestellt werden. Die Softwarearchitektur betrachtet die übergeordnete Struktur eines Softwaresystems und beschreibt dessen wesentliche Elemente mit ihren Eigenschaften sowie die Beziehungen zwischen den Elementen. Die Qualität eines IT-Systems ist grundsätzlich erst nach der Implementierung messbar. Da die Qualität aber wesentlich von den getroffenen Entwurfsentscheidungen auf der Softwarearchitekturebene abhängt, kann eine Ex-ante-Bewertung über die zu erwartenden Auswirkungen dieser Entwurfsentscheidungen auf die Qualität des Gesamtsystems erfolgen. Es ist unverständlich, weshalb eine solche Bewertung in der Praxis kein fester Bestandteil des Softwareentwicklungsprozesses ist. Denn entsprechende Modelle und Methoden stehen zur Verfügung. Stefan Malich untersucht in der vorliegenden Arbeit, wie die Beziehungen zwischen den Entwurfsentscheidungen bezüglich der Softwarearchitektur und den daraus entstehenden Auswirkungen auf die Qualität des Systems einerseits ermittelt und andererseits dokumentiert werden können. Beim Architekturentwurf kommen heute vielfach Entwurfsmuster, sogenannte Pattern, zum Einsatz. Stefan Malich zeigt durch Einordnung von Pattern aus den wichtigsten Pattern-Katalogen in sein Modell dessen Einsetzbarkeit auf und leistet damit eine wichtige Grundlagenarbeit für den Architekturentwurf in der Praxis. Durch das entstandene, erweiterbare Modell können die erfassten Pattern hinsichtlich ihrer Auswirkungen auf die Qualität effizient analysiert und bewertet werden. Wir wünschen der Arbeit eine große Verbreitung in Wissenschaft und Praxis, damit der durch ihre Ergebnisse mögliche positive Einfluss auf die Qualität software-intensiver Systeme auch konkret genutzt wird!

Prof. Dr. Stefan Eicker & Prof. Dr. Reinhard Jung

Vorwort Im Rahmen von IT-Projekten wurde ich als freiberuflicher IT-Berater und als Mitarbeiter der Unternehmensberatung Accenture unmittelbar mit der steigenden Größe und Komplexität von IT-Systemen konfrontiert. Die Gründe und unmittelbaren Folgen dieser Entwicklung waren bzw. sind aus einer praxisorientierten Perspektive offensichtlich: Die Anforderungen an die IT-Systeme werden immer umfangreicher und komplexer. Es werden kontinuierlich neue ITAnwendungen und Technologien eingeführt. Die Anwendungen, die in den Unternehmen bereits im Einsatz sind, werden immer weiter gehender integriert. Die Entwicklung von anforderungsgerechten IT-Systemen ist deshalb mit erheblichen Risiken verbunden und erfordert immer mehr Ressourcen, die im Rahmen des Projektmanagements effizient gesteuert und kontrolliert werden müssen. Diese Problemstellung beschäftigte mich zunächst nur in der Praxis, obwohl im Forschungsgebiet der Informatik bzw. Wirtschaftsinformatik mit den Konzepten im Umfeld der Softwarearchitekturen bereits erste Lösungsansätze entwickelt wurden. Mein Interesse an diesen Konzepten war (und ist nach wie vor) sehr groß. Jedoch ließen die IT-Projekte, an denen ich beteiligt war, es zeitlich nicht zu, dass ich mich intensiv mit diesen Konzepten beschäftigen konnte. Im Sommer 2004 entschied ich mich daher für eine zweijährige „Auszeit“ vom Beratungsgeschäft, um als wissenschaftlicher Mitarbeiter und Doktorand am Institut für Informatik und Wirtschaftsinformatik der Universität Duisburg-Essen tätig zu werden. Das vorliegende Buch bzw. die zugrunde liegende Dissertation ist – neben vielen weiteren Ergebnissen – das wesentliche Ziel dieser Tätigkeit gewesen. Es beschreibt die Entwicklung eines patternbasierten Wissensmodells, das den Entwurf und die Bewertung von Softwarearchitekturen unterstützt. Das spezielle Forschungsgebiet der Softwarearchitekturen ist relativ jung und sehr dynamisch. Im Verlauf des Begutachtungsprozesses der vorliegenden Arbeit sind weitere Arbeiten zu diesem Themenkomplex – insbesondere im Rahmen der sog. Pattern-Oriented Software Architecture-Serie – erschienen. Ich bin stolz darauf, im Kontext dieses Forschungsgebietes einen Beitrag geleistet zu haben und plane, auf Basis dieser Arbeit weitere Forschungsaktivitäten durchzuführen. Die Ergebnisse dieser und zukünftiger Arbeiten werden auf der Website http://www.architecturalpatterns.com aufgelistet. Obwohl eine derartige Arbeit von einer einzelnen Person verfasst wird, erfordert sie dennoch ein Umfeld, das eine wissenschaftliche und persönliche Unterstützung bietet. Mein Dank sei deshalb an dieser Stelle all denen ausgesprochen, die die Entstehung der vorliegenden Arbeit direkt und indirekt unterstützt haben. Mein aufrichtiger Dank gilt insbesondere meinem Doktorvater Prof. Dr. Stefan Eicker, der mir ein hervorragendes wissenschaftliches Umfeld geboten und die Entwicklung der Arbeit begleitet hat. Zu besonderem Dank bin ich Herrn Christian Engels verpflichtet, der trotz einer angespannten Projektsituation sehr großes Verständnis für meine persönliche Entscheidung

VIII

Vorwort

zeigte und mir im Kontext meiner Tätigkeit bei der Unternehmensberatung Accenture den Weg zu einer „Auszeit“ ebnete. Für die vielen und umfangreichen fachlichen Diskussionen möchte ich mich explizit bei Christian Hegmanns und Thorsten Spies bedanken. Unsere zahlreichen Diskurse zum Themenkomplex der Softwarearchitekturen waren für mich sehr motivierend und boten mir stets die Gelegenheit, eigene Ansätze und Ideen zu diskutieren. Eine große Unterstützung waren auch Annett Nagel, Thorsten Offermann, Christian Stefan Walter und Dr. Christian Piwetz. Ihre kritische Durchsicht der Entwurfsversionen ermöglichte es mir, die Qualität der finalen Arbeit zu verbessern. In meinem persönlichen Umfeld möchte ich mich insbesondere bei meinen Eltern dafür bedanken, dass sie mir für eine derartige Leistung das Notwendige mit auf den Weg gegeben haben. Ihnen sei deshalb das vorliegende Buch gewidmet.

Stefan Malich

Inhaltsübersicht Abbildungsverzeichnis ............................................................................................................XV Tabellenverzeichnis............................................................................................................... XIX Abkürzungsverzeichnis ......................................................................................................... XXI 1

2

3

4

5

Einleitung ............................................................................................................................ 1 1.1

Problemstellung ......................................................................................................... 1

1.2

Zielsetzung................................................................................................................. 3

1.3

Forschungsansatz....................................................................................................... 4

1.4

Aufbau der Arbeit ...................................................................................................... 7

Grundlagen und Bezugsrahmen des Entwurfs von Softwarearchitekturen......................... 9 2.1

Begriffsdefinitionen................................................................................................... 9

2.2

Bezugsrahmen.......................................................................................................... 15

2.3

Bedeutung der Softwarearchitektur ......................................................................... 21

2.4

Einflussfaktoren....................................................................................................... 24

2.5

Dokumentation von Softwarearchitekturen............................................................. 28

2.6

Verwandte Arbeiten................................................................................................. 33

2.7

Zusammenfassung ................................................................................................... 44

Bewertung von Softwarearchitekturen.............................................................................. 47 3.1

Ziele und Annahmen der Bewertung....................................................................... 47

3.2

Qualität von Softwareprodukten und -architekturen ............................................... 49

3.3

Bewertungsmethoden für Softwarearchitekturen .................................................... 74

3.4

Zusammenfassung ................................................................................................. 100

Pattern im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen ......... 103 4.1

Konzept der Pattern ............................................................................................... 103

4.2

Dokumentation von Pattern ................................................................................... 110

4.3

Konzepte zur Auswahl von Pattern ....................................................................... 129

4.4

Pattern im Kontext des Entwurfs und der Bewertung ........................................... 136

4.5

Zusammenfassung ................................................................................................. 138

Entwicklung eines pattern-basierten Wissensmodells .................................................... 139 5.1

Entwicklung des Wissensmodells.......................................................................... 139

5.2

Entwicklung der Vorgehensweise ......................................................................... 174

5.3

Validierung der Vorgehensweise und des Wissensmodells .................................. 185

5.4

Verwendung der Wissensbasis .............................................................................. 196

X

Inhaltsübersicht

5.5 6

Zusammenfassung ................................................................................................. 204

Schlussbetrachtung.......................................................................................................... 205 6.1

Zusammenfassung der Ergebnisse......................................................................... 205

6.2

Weiterer Forschungsbedarf.................................................................................... 206

6.3

Ausblick................................................................................................................. 210

Literaturverzeichnis................................................................................................................ 213 Anhang A ............................................................................................................................... 223 Anhang B................................................................................................................................ 227

Inhaltsverzeichnis Abbildungsverzeichnis ............................................................................................................XV Tabellenverzeichnis............................................................................................................... XIX Abkürzungsverzeichnis ......................................................................................................... XXI 1

2

Einleitung ............................................................................................................................ 1 1.1

Problemstellung ......................................................................................................... 1

1.2

Zielsetzung................................................................................................................. 3

1.3

Forschungsansatz....................................................................................................... 4

1.4

Aufbau der Arbeit ...................................................................................................... 7

Grundlagen und Bezugsrahmen des Entwurfs von Softwarearchitekturen......................... 9 2.1

Begriffsdefinitionen................................................................................................... 9

2.2

Bezugsrahmen.......................................................................................................... 15

2.3

Bedeutung der Softwarearchitektur ......................................................................... 21

2.4

Einflussfaktoren....................................................................................................... 24

2.5

Dokumentation von Softwarearchitekturen............................................................. 28

2.6

Verwandte Arbeiten................................................................................................. 33 2.6.1 Attribut-basierte Architektur-Stile ............................................................... 33 2.6.1.1 Darstellung des Ansatzes............................................................... 34 2.6.1.2 Bewertung des Ansatzes im vorliegenden Kontext ....................... 35 2.6.2 Extraktion von architektur-relevanten Informationen nach Zhu, Ali Babar und Jeffery .................................................................. 37 2.6.2.1 Darstellung des Ansatzes............................................................... 37 2.6.2.2 Bewertung des Ansatzes im vorliegenden Kontext ....................... 39 2.6.3 Dokumentation von architektur-relevanten Informationen nach Ali Babar ............................................................................................. 40 2.6.3.1 Darstellung des Ansatzes............................................................... 40 2.6.3.2 Bewertung des Ansatzes im vorliegenden Kontext ....................... 43

2.7 3

Zusammenfassung ................................................................................................... 44

Bewertung von Softwarearchitekturen.............................................................................. 47 3.1 3.2

Ziele und Annahmen der Bewertung....................................................................... 47 Qualität von Softwareprodukten und -architekturen ............................................... 49 3.2.1 Bezugsrahmen der Softwarequalität ............................................................ 50 3.2.2 Konzept der Qualitätsmodelle...................................................................... 52 3.2.2.1 Aufbau von Qualitätsmodellen ...................................................... 52

XII

Inhaltsverzeichnis

3.2.2.2 Eigenschaften eines Softwareprodukts .......................................... 54 3.2.2.3 Probleme bei der Anwendung von Qualitätsmodellen .................. 55 3.2.3 Qualitätsmodell des ISO/IEC 9126-Standards ............................................ 56 3.2.3.1 Anwendungsbereiche und Ziele .................................................... 57 3.2.3.2 Qualitätsansätze ............................................................................. 57 3.2.3.3 Qualitätsmodell.............................................................................. 59 3.2.3.4 Metriken......................................................................................... 60 3.2.3.5 Identifikation der Rangfolge der Qualitätsmerkmale .................... 62 3.2.3.6 Bewertung des Qualitätsmodells ................................................... 65 3.2.4 Qualitätsmodell des Software Engineering-Instituts ................................... 66 3.2.4.1 Anwendungsbereiche und Ziele .................................................... 66 3.2.4.2 Qualitätsmodell.............................................................................. 67 3.2.4.3 Modell der Qualitätsmerkmal-Szenarios ....................................... 69 3.2.4.4 Erstellung von Szenarios ............................................................... 71 3.2.4.5 Bewertung des Qualitätsmodells ................................................... 73 3.3

Bewertungsmethoden für Softwarearchitekturen .................................................... 74 3.3.1 Überblick der existierenden Bewertungsmethoden ..................................... 75 3.3.1.1 Assoziationen zwischen den Methoden......................................... 76 3.3.1.2 Vererbungen zwischen den Methoden........................................... 78 3.3.1.3 Eigenständige Methoden ............................................................... 80 3.3.1.4 Positionierung und Auswahl der Architecture Tradeoff Analysis-Methode...................................... 80 3.3.2 Architecture Tradeoff Analysis-Methode .................................................... 81 3.3.2.1 Ziele und Annahmen...................................................................... 82 3.3.2.2 Konzept der Sensitivitäts- und Abwägungspunkte........................ 84 3.3.2.3 Konzept der Risiken und Sicherheiten .......................................... 86 3.3.2.4 Konzept des Nutzwert-Baums ....................................................... 86 3.3.2.5 Phasen und Arbeitsschritte ............................................................ 89 3.3.2.6 Ergebnisse der Bewertung ............................................................. 97 3.3.2.7 Bewertung der Methode ................................................................ 98

3.4 4

Zusammenfassung ................................................................................................. 100

Pattern im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen ......... 103 4.1

Konzept der Pattern ............................................................................................... 103 4.1.1 Begriffsdefinitionen und Bezugsrahmen ................................................... 104 4.1.2 Eigenschaften des Entwurfs auf Basis von Pattern.................................... 107 4.1.3 Positionierung des Pattern-Konzepts ......................................................... 108

Inhaltsverzeichnis

4.2

XIII

Dokumentation von Pattern ................................................................................... 110 4.2.1 Konzept der Pattern-Schablonen................................................................ 111 4.2.1.1 Untersuchung ausgewählter Pattern-Schablonen ........................ 111 4.2.1.2 Bewertung der Pattern-Schablonen ............................................. 114 4.2.2 Konzept der Klassifikationen von Pattern ................................................. 116 4.2.2.1 Untersuchung ausgewählter Pattern-Klassifikationen................. 116 4.2.2.2 Bewertung der Pattern-Klassifikationen...................................... 120 4.2.3 Konzept der Definition von Pattern-Sprachen........................................... 120 4.2.3.1 Untersuchung ausgewählter Pattern-Sprachen ............................ 121 4.2.3.2 Bewertung der Pattern-Sprachen ................................................. 128

4.3

Konzepte zur Auswahl von Pattern ....................................................................... 129 4.3.1.1 Untersuchung ausgewählter Konzepte ........................................ 130 4.3.1.2 Bewertung der Konzepte ............................................................. 136

5

4.4

Pattern im Kontext des Entwurfs und der Bewertung ........................................... 136

4.5

Zusammenfassung ................................................................................................. 138

Entwicklung eines pattern-basierten Wissensmodells .................................................... 139 5.1

Entwicklung des Wissensmodells.......................................................................... 139 5.1.1 Zieldefinition und Annahmen .................................................................... 140 5.1.2 Grundlegende Struktur und Aufbau des Wissensmodells ......................... 141 5.1.3 Definition eines homogenen Qualitätsmodells .......................................... 144 5.1.4 Katalog-übergreifende Identifikation von Pattern ..................................... 150 5.1.5 Identifikation des Pattern-Typs und des Bezugs der Zuordnung............... 151 5.1.6 Identifikation und Klassifikation der Beziehungen zwischen Pattern ....... 153 5.1.7 Klassifikation der Auswirkungen .............................................................. 155 5.1.7.1 Positive Reaktionen ..................................................................... 158 5.1.7.2 Sensitivitätspunkte....................................................................... 160 5.1.7.3 Abwägungspunkte ....................................................................... 164 5.1.7.4 Negative Reaktionen.................................................................... 167 5.1.7.5 Interpretation der Reaktionen ...................................................... 168 5.1.8 Klassifikation der Tabellenfelder............................................................... 172

5.2

Entwicklung der Vorgehensweise ......................................................................... 174 5.2.1 Zieldefinition und Annahmen .................................................................... 174 5.2.2 Prozess zum Aufbau einer Wissensbasis ................................................... 175 5.2.2.1 Prozesslogik und Aktivitäten im Überblick................................. 175 5.2.2.2 Beschreibung der Aktivitäten ...................................................... 176 5.2.2.2.1 Selektion der Pattern-Kataloge ................................... 177

XIV

Inhaltsverzeichnis

5.2.2.2.2 Selektion der Architektur-Pattern eines Katalogs....... 179 5.2.2.2.3 Erfassung eines Architektur-Pattern ........................... 180 5.3

Validierung der Vorgehensweise und des Wissensmodells .................................. 185 5.3.1 Selektion der Pattern-Kataloge .................................................................. 186 5.3.2 Identifikation der Architektur-Pattern der Kataloge .................................. 187 5.3.3 Erfassung der Architektur-Pattern ............................................................. 188 5.3.4 Zusammenfassung der Ergebnisse............................................................. 193

5.4

Verwendung der Wissensbasis .............................................................................. 196 5.4.1 Verwendung im Kontext des Entwurfs von Softwarearchitekturen .......... 196 5.4.1.1 Auswahl eines Pattern auf Basis der Problemstellung ................ 196 5.4.1.2 Auswahl eines Pattern auf Basis der Konsequenzen ................... 198 5.4.1.3 Bewertung der Verwendung im Kontext des Entwurfs............... 199 5.4.2 Verwendung im Kontext der Bewertung von Softwarearchitekturen........ 200 5.4.2.1 Verwendung im Kontext der Architecture Tradeoff Analysis-Methode.................................... 200 5.4.2.2 Bewertung der Unterstützung der Architecture Tradeoff Analysis-Methode.................................... 203

5.5 6

Zusammenfassung ................................................................................................. 204

Schlussbetrachtung.......................................................................................................... 205 6.1 6.2

Zusammenfassung der Ergebnisse......................................................................... 205 Weiterer Forschungsbedarf.................................................................................... 206 6.2.1 Validierung der Effizienz und Effektivität des Wissensmodells ............... 207 6.2.2 Erweiterung des Wissensmodells .............................................................. 207 6.2.3 Erweiterung der Pattern-Dokumentation ................................................... 208 6.2.4 Entwicklung eines Werkzeugs zur Verwaltung und Verwendung der Wissensbasis .................................................................. 209

6.3

Ausblick................................................................................................................. 210

Literaturverzeichnis................................................................................................................ 213 Anhang A ............................................................................................................................... 223 Anhang B................................................................................................................................ 227

Abbildungsverzeichnis Abbildung 1-1: Aufbau der Arbeit .......................................................................................... 7 Abbildung 2-1: Struktur und Aufbau des Zachman-Frameworks......................................... 17 Abbildung 2-2: Positionierung der Softwarearchitektur im Zachman-Framework .............. 19 Abbildung 2-3: Modell der Informationssystem-Architektur ............................................... 20 Abbildung 2-4: Positionierung der Softwarearchitektur im Modell der Informationssystem-Architektur .......................................... 21 Abbildung 2-5: Einflussfaktoren der Softwarearchitektur .................................................... 25 Abbildung 2-6: Darstellung des Architecture Business Cycle .............................................. 26 Abbildung 2-7: Ansatz nach Zhu, Ali Babar und Jeffery ...................................................... 38 Abbildung 2-8: Vorlage zur Dokumentation der architektur-relevanten Informationen eines Pattern ......................................................................... 41 Abbildung 2-9: Vorlage zur Dokumentation von konkreten Szenarios ................................ 42 Abbildung 2-10: Positionierung von architektur-relevanten Informationen in der Pattern-Dokumentation...................................................................... 42 Abbildung 3-1: Aufbau von Qualitätsmodellen .................................................................... 53 Abbildung 3-2: Qualitätsansätze des ISO/IEC 9126-Standards............................................ 58 Abbildung 3-3: Qualitätsmerkmale für die interne und externe Qualität.............................. 59 Abbildung 3-4: Qualitätsmerkmale für die Qualität der Nutzung......................................... 59 Abbildung 3-5: Qualitätsmerkmale des Systems .................................................................. 67 Abbildung 3-6: Betriebswirtschaftliche Qualitätsmerkmale ................................................. 68 Abbildung 3-7: Architektur-bezogene Qualitätsmerkmale ................................................... 68 Abbildung 3-8: Modell der Qualitätsmerkmal-Szenarios ..................................................... 70 Abbildung 3-9: Positionierung des Modells der Qualitätsmerkmal-Szenarios ..................... 71 Abbildung 3-10: Beispiel für ein generelles Szenario............................................................. 72 Abbildung 3-11: Beispiel für ein konkretes Szenario ............................................................. 73 Abbildung 3-12: Assoziationen zwischen den Bewertungsmethoden .................................... 77 Abbildung 3-13: Vererbungen der Software Architecture Analysis- und der Architecture Tradeoff Analysis-Methode.............................................. 78 Abbildung 3-14: Unabhängige Bewertungsmethoden ............................................................ 80 Abbildung 3-15: Kerngedanke der Architecture Tradeoff Analysis-Methode........................ 83 Abbildung 3-16: Konzept der Sensitivitätspunkte .................................................................. 84 Abbildung 3-17: Konzept der Abwägungspunkte................................................................... 85 Abbildung 3-18: Aufbau eines Nutzwert-Baums .................................................................... 87 Abbildung 3-19: Erfassung von Prioritäten innerhalb des Nutzwert-Baums.......................... 88 Abbildung 3-20: Phasen und Arbeitsschritte der Architecture Tradeoff Analysis-Methode .................................................... 89

XVI

Abbildungsverzeichnis

Abbildung 3-21: Überprüfung der Architekturansätze............................................................ 92 Abbildung 3-22: Vorgehensweise innerhalb der Analyse der Architekturansätze ................. 93 Abbildung 4-1: Positionierung des Pattern-Konzepts ......................................................... 109 Abbildung 4-2: Beziehungen zwischen den Entwurfs-Pattern............................................ 122 Abbildung 4-3: Beziehungen zwischen den POSA 1-Pattern ............................................. 124 Abbildung 4-4: Beziehungen zwischen den POSA 2-Pattern ............................................. 125 Abbildung 4-5: Beziehungen zwischen den J2EE Core Pattern ......................................... 127 Abbildung 5-1: Ziele des Wissensmodells .......................................................................... 140 Abbildung 5-2: Positionierung der Problemlösungsmethode der Klassifikation und des Wissensmodells............................................... 141 Abbildung 5-3: Grundlegende Struktur und Aufbau der Tabelle........................................ 142 Abbildung 5-4: Herleitung der Lösung im Kontext der Bewertung.................................... 142 Abbildung 5-5: Herleitung der Lösung im Kontext des Entwurfs ...................................... 143 Abbildung 5-6: Ableitungsregeln für die Vorspalten „Pattern Name“ und „Source“......... 150 Abbildung 5-7: Ableitungsregeln für die Vorspalten „Pattern Type“, „Context“, „Stimulated Artifact“ und „Supported General Scenarios“ ....................... 153 Abbildung 5-8: Ableitungsregeln für die Vorspalte „Relationships“.................................. 154 Abbildung 5-9: Ableitungsregel für die Beeinflussung eines Qualitätsmerkmals .............. 157 Abbildung 5-10: Positive Reaktion in Bezug auf ein Qualitätsmerkmal .............................. 158 Abbildung 5-11: Ableitungsregeln für die Dokumentation einer positiven Reaktion .......... 159 Abbildung 5-12: Beispiel für die Dokumentation von positiven Reaktionen ....................... 159 Abbildung 5-13: Sensitivitätspunkt in Bezug auf ein Qualitätsmerkmal.............................. 160 Abbildung 5-14: Ableitungsregeln für die Dokumentation eines Sensitivitätspunkts .......... 161 Abbildung 5-15: Beispiel für die Dokumentation von Sensitivitätspunkten mit einheitlicher Auswirkung .................................................................... 163 Abbildung 5-16: Beispiel für die Dokumentation von Sensitivitätspunkten mit engem Definitionsbereich.................................................................... 163 Abbildung 5-17: Abwägungspunkt in Bezug auf mehrere Qualitätsmerkmale .................... 164 Abbildung 5-18: Ableitungsregeln für die Dokumentation eines Abwägungspunkts........... 165 Abbildung 5-19: Beispiel für die Dokumentation von Abwägungspunkten (Qualitätsmerkmal des Zeitverhaltens) ...................................................... 166 Abbildung 5-20: Beispiel für die Dokumentation von Abwägungspunkten (Qualitätsmerkmal der Analysierbarkeit) .................................................. 167 Abbildung 5-21: Negative Reaktion in Bezug auf ein Qualitätsmerkmal............................. 167 Abbildung 5-22: Ableitungsregeln für die Dokumentation einer negativen Reaktion.......... 168 Abbildung 5-23: Beispiel für die Dokumentation von negativen Reaktionen ...................... 168 Abbildung 5-24: Beispiel für die Interpretation der Reaktionen (Qualitätsmerkmal der Veränderlichkeit) .................................................. 170

Abbildungsverzeichnis

XVII

Abbildung 5-25: Prozesslogik und Aktivitäten zum Aufbau einer Wissensbasis................. 176 Abbildung 5-26: Beziehungen zwischen den ausgewählten Pattern-Katalogen ................... 187 Abbildung 5-27: Beispielhaftes Szenario des „Service Locator“-Pattern............................. 194 Abbildung 5-28: Darstellung der Wissensbasis (sehr starke Verkleinerung) ....................... 195 Abbildung 5-29: Untersuchung der Auswirkungen eines Pattern auf Basis des Wissensmodells ................................................................... 197 Abbildung 5-30: Identifikation und Auswahl eines Pattern auf Basis der Konsequenzen.... 198 Abbildung 5-31: Verwendung der Wissensbasis im Kontext der Architecture Tradeoff Analysis-Methode............................................ 201

Tabellenverzeichnis Tabelle 2-1:

Stakeholder und ihre Kommunikationsanforderungen ................................ 29

Tabelle 3-1:

Tabellenstruktur der Dokumentation der Metriken ..................................... 61

Tabelle 3-2:

Rangfolgen der Qualitätsmerkmale (Teil 1) ................................................ 63

Tabelle 3-3:

Rangfolgen der Qualitätsmerkmale (Teil 2) ................................................ 64

Tabelle 3-4:

Beispiel für eine qualitätsmerkmal-spezifische Tabelle .............................. 72

Tabelle 3-5:

Beschreibung der Spezialisierung der Software Architecture Analysisund der Architecture Tradeoff Analysis-Methode....................................... 79

Tabelle 4-1:

Pattern-Schablone nach Gamma, Helm, Johnson und Vlissides................ 112

Tabelle 4-2:

Pattern-Schablone der Pattern-Oriented Software Architecture-Serie ...... 113

Tabelle 4-3:

Pattern-Schablone nach Alur, Crupi und Malks ........................................ 114

Tabelle 4-4:

Klassifikationsschema nach Gamma, Helm, Johnson und Vlissides ......... 117

Tabelle 4-5:

Klassifikationsschema nach Buschmann, Meunier, Rohnert et al. ............ 118

Tabelle 4-6:

Klassifikationsschema nach Alur, Crupi und Malks.................................. 119

Tabelle 4-7:

Zuordnung von Anforderungen und Pattern (Präsentationsschicht).......... 135

Tabelle 5-1:

Qualitätsmerkmale des Wissensmodells (Teil 1)....................................... 146

Tabelle 5-2:

Qualitätsmerkmale des Wissensmodells (Teil 2)....................................... 147

Tabelle 5-3:

Qualitätsmerkmale des Wissensmodells (Teil 3)....................................... 148

Tabelle 5-4:

Kategorien des Ausmaßes einer Reaktion ................................................. 157

Tabelle 5-5:

Beispiel für die Interpretation der Reaktionen (Kontext, stimulierter Artefakt) ................................................................. 170

Tabelle 5-6:

Farbliche Klassifikation der Tabellenfelder............................................... 173

Tabelle 5-7:

Hilfsmittel zur Selektion von Pattern-Katalogen....................................... 178

Tabelle 5-8:

Aktivität: Selektion der Pattern-Kataloge.................................................. 179

Tabelle 5-9:

Aktivität: Identifikation der Architektur-Pattern eines Katalogs............... 180

Tabelle 5-10:

Beispiel für eine Transformationsregel...................................................... 184

Tabelle 5-11:

Aktivität: Erfassung eines Architektur-Pattern.......................................... 185

Tabelle 5-12:

Ergebnis der Selektion der Pattern-Kataloge............................................. 186

Tabelle 5-13:

Ergebnis der Identifikation der Architektur-Pattern der Kataloge............. 188

Tabelle 5-14:

Transformationsregeln bei der Erfassung der Pattern (Teil 1)................... 192

Tabelle 5-15:

Transformationsregeln bei der Erfassung der Pattern (Teil 2)................... 193

Abkürzungsverzeichnis ABAS

Attribute-Based Architectural Styles

ABC

Architecture Business Cycle

ADR

Active Design Reviews

ALMA

Architecture-Level Modifiability Analysis

ALPSM

Architecture Level Prediction of Software Maintenance

AQA

Architecture Quality Assessment

ARID

Active Reviews for Intermediate Design

ATAM

Architecture Tradeoff Analysis-Methode

CBAM

Cost Benefit Analysis-Methode

DIN

Deutsche Industrie-Norm

EBNF

Erweiterte Backus-Naur-Form

ESAAMI

Extending SAAM by Integration in the Domain

FAAM

Familiy Architecture Assessment-Methode

FCM

Factor-Criteria-Metrics

GQM

Goal Question Metrics

IEC

International Electrotechnical Commission

ISA

Informationssystem-Architektur

ISAAMCR

Integrating SAAM in Domain-centric and Reuse-based Development Processes

ISO

International Organization for Standardization

IT

Informationstechnologie

J2EE

Java 2 Platform, Enterprise Edition

Java EE

Java Platform, Enterprise Edition

JNDI

Java Naming and Directory Interface

NATO

North Atlantic Treaty Organization

OSI

Open Systems Interconnection

PASA

Performance Assessment of Software Architecture

QAW

Quality Attribute Workshop

PLoP

Pattern Languages of Programs

POSA

Pattern-Oriented Software Architecture

ROI

Return on Investment

SAAM

Software Architecture Analysis-Methode

SAAMCS

Software Architecture Analysis Method for Complex Scenarios

SAAMER

Software Architecture Analysis Method for Evolution and Reusability

XXII

Abkürzungsverzeichnis

SACAM

Software Architecture Comparison Analysis-Methode

SAE

Software Architecture Evaluation

SAEM

Software Architecture Evaluation Model

SBAR

Scenario-Based Architecture Reengineering

SEI

Software Engineering-Institut (der Carnegie Mellon Universität)

UML

Unified Modeling Language

VPN

Virtual Private Network

WWW

World Wide Web

XML

Extensible Markup Language

1 Einleitung 1.1

Problemstellung

Software-intensive Systeme prägen immer weiter gehender die modernen Gesellschaften: In Unternehmen und Verwaltungen werden die Geschäftsprozesse auf Basis von entsprechenden IT-Systemen ausgeführt und Entscheidungsprozesse werden vermehrt durch entsprechende IT-Anwendungen und Datenbanken unterstützt. Privatpersonen werden im Alltag zunehmend von IT-Systemen begleitet, die teilweise bewusst genutzt bzw. gesteuert werden, teilweise eher „unsichtbar“ im Hintergrund arbeiten. Die starke und noch rasch weiter wachsende Verbreitung der software-intensiven Systeme erhöht ihre Bedeutung und führt dementsprechend zu einer immer größeren Abhängigkeit von ihnen (vgl. z. B. [TEIU2005a, S. 17 f.; TEIU2005b, S. 4]). Durch die einerseits immer weiter reichenden Anforderungen an die Systeme und ihre immer weiter gehende Integration andererseits erhöhen sich allerdings ihr Umfang und vor allem ihre Komplexität. Die Entwicklung von anforderungsgerechten IT-Systemen ist deshalb mit erheblichen Risiken verbunden und erfordert immer mehr Ressourcen, die im Softwareentwicklungsprozess effizient gesteuert und kontrolliert werden müssen. Als Voraussetzung für die Steuerung und Kontrolle wird zwingend ein angemessener Entwurf des IT-Systems benötigt, da er die Grundlage für das Projektmanagement und die Implementierung bildet. Wesentlicher Bestandteil des Entwurfs ist die Softwarearchitektur des Systems (vgl. z. B. [BaCK2003, S. 26, S. 29 f.]). Eine Softwarearchitektur betrachtet die übergeordnete Struktur eines IT-Systems und beschreibt die wesentlichen Softwareelemente des Systems mit ihren Eigenschaften und Beziehungen untereinander (vgl. [BaCK2003, S. 21-23]). Sie stellt eine konzeptuelle Abstraktion des Systems dar, weil sie ausschließlich die extern sichtbaren Bestandteile des Systems berücksichtigt, die internen Details der Implementierung der Elemente und Beziehungen zwischen ihnen dagegen bewusst ausblendet. Die Entwurfsentscheidungen, die auf der Ebene der Softwarearchitektur getroffen werden, unterstützen oder behindern die Realisierung nahezu aller Qualitätsmerkmale eines komplexen IT-Systems (vgl. [ClKK2002, S. 11, S. 20]). Insofern ist es grundsätzlich möglich und sinnvoll, diese Entscheidungen im Hinblick auf ihre Auswirkungen auf die Qualitätsmerkmale des Systems zu bewerten, um so eine Vorhersage der Qualität des Gesamtsystems zu ermöglichen (vgl. [ClKK2002, S. 21]). Das Ziel der Bewertung von Softwarearchitekturen muss somit darin bestehen, die Beziehungen zwischen den Entwurfsentscheidungen innerhalb der Softwarearchitektur auf der einen Seite und den Auswirkungen der Entscheidungen auf die Qualität des zugehörigen Systems auf der anderen Seite systematisch zu untersuchen, zu verstehen und zu bewerten (vgl. [ClKK2002, S. 110]).

2

Einleitung

Zu beachten ist, dass eine Softwarearchitektur im Kontext der spezifizierten Anforderungen entworfen wird und somit auch nur in diesem Kontext bewertet werden kann. Dementsprechend existiert per se keine „gute“ oder „schlechte“ Softwarearchitektur, sondern eine Softwarearchitektur ist für einen definierten Einsatzbereich, der durch die Anforderungen spezifiziert wird, mehr oder weniger gut geeignet (vgl. [BaCK2003, S. 15; ClKK2002, S. 29]). Da die Qualität einer Softwarearchitektur eine Aussage über den Grad der Erfüllung der spezifizierten Anforderungen trifft, stellt sich die Frage, welche Anforderungen im Kontext der Softwarearchitektur relevant und beim Entwurf sowie bei der Bewertung zu berücksichtigen sind. Außerdem ergibt sich die Zusatzfrage, wie die Anforderungen spezifiziert werden müssen, damit sie innerhalb des Entwurfs und der Bewertung adäquat berücksichtigt werden können. Die Definition und Überprüfung von Anforderungen wird u. a. durch Konzepte und Modelle der Softwarequalität unterstützt, die das zunächst allgemeine Konzept der Qualität in Bezug auf Software anwendbar machen. Da die Softwarearchitektur in diesem Kontext lediglich ein Zwischenprodukt darstellt, das in das Softwareendprodukt einfließt, ist zu überprüfen, ob diese Qualitätsmodelle auch beim Entwurf und bei der Bewertung von Softwarearchitekturen verwendet werden können, oder ob im Kontext der Softwarearchitektur spezielle Konzepte und Modelle für die Qualität erforderlich sind. Die Bewertung einer Softwarearchitektur kann grundsätzlich auf der Basis einer existierenden Bewertungsmethode erfolgen, die den Analyseprozess strukturiert und unterstützt. Der Aufwand für die Anwendung einer derartigen Methode ist relativ gering und es ergibt sich damit ein sehr gutes Kosten-/Nutzen-Verhältnis (vgl. [ClKK2002, S. 23-24, S. 39 ff.]). Deshalb ist es eigentlich unverständlich, warum die Bewertung der Softwarearchitektur in der Praxis – trotz der großen Bedeutung der Architektur und des guten Kosten-/Nutzen-Verhältnisses – kein fester Bestandteil des Softwareentwicklungsprozesses ist. Die Menge der Entwurfsentscheidungen innerhalb der Softwarearchitektur ist i. d. R. sehr umfangreich. Verschiedene Bewertungsmethoden, wie z. B. die Architecture Tradeoff Analysis-Methode (ATAM), strukturieren und gruppieren deshalb die Entwurfsentscheidungen auf Basis von sog. architektur-bezogenen Ansätzen. Diese Ansätze beschreiben eine bestimmte Anordnung und Zusammenarbeit von Softwareelementen in Verbindung mit den Auswirkungen der Struktur auf die Qualitätsmerkmale (vgl. [ClKK2002, S. 43 ff.]). Sie entsprechen damit konzeptuell dem Konzept der Pattern1, das auf die systematische Dokumentation von Entwurfswissen auf Basis von existierenden und erprobten Entwürfen abzielt. Obwohl in Bewertungsmethoden, wie z. B. der Architecture Tradeoff Analysis-Methode, die Verwendung des Pattern-Konzepts explizit vorgesehen ist, sind dennoch die Methoden und

1

Der Begriff des „Pattern“ wird in der vorliegenden Arbeit nicht mit „Muster“ übersetzt, da der englische Begriff nach der Einschätzung des Autors geläufiger ist.

Zielsetzung

3

das Pattern-Konzept bisher nicht vollständig integriert. Es stellt sich deshalb die Frage, ob durch eine stärkere Integration beider Konzepte die Effizienz und Effektivität des Entwurfs bzw. der Bewertung erhöht werden können.

1.2

Zielsetzung

Das Ziel der vorliegenden Arbeit liegt in der Untersuchung der Frage, wie die Beziehungen zwischen den Entwurfsentscheidungen innerhalb der Softwarearchitektur und deren Auswirkungen auf die Qualität des Systems ermittelt und dokumentiert werden können, damit auf Basis dieser Kenntnis der Entwurf und die Bewertung einer Softwarearchitektur effizienter und effektiver erfolgen kann. Die Effizienz eines Entwurfs und einer Bewertung bezieht sich im Kontext der vorliegenden Arbeit auf die Zeit und die personellen Ressourcen, die für den Entwurf bzw. die Bewertung einer bestimmten Softwarearchitektur benötigt werden. Je weniger Zeit und je weniger personelle Ressourcen notwendig sind, desto effizienter ist die Vorgehensweise innerhalb des Entwurfs bzw. der Bewertung. Die Effektivität betrachtet die Qualität des Entwurfs und der Bewertung einer Softwarearchitektur. Je besser der Entwurf bzw. die Bewertung einer Softwarearchitektur ist, desto effektiver ist die Vorgehensweise innerhalb des Entwurfs bzw. der Bewertung. Im Einzelnen lassen sich aus dem Ziel der Arbeit die folgenden Forschungsfragen als Teilziele ableiten: 1. Qualitätsmodelle: Wie lassen sich die Konzepte und Modelle der Softwarequalität zur Definition und Überprüfung von Anforderungen im Kontext der Softwarearchitekturen einsetzen? 2. Bewertungsmethoden: Wie werden die Beziehungen zwischen den Entwurfsentscheidungen innerhalb der Softwarearchitektur und deren Auswirkungen auf die Qualität des Systems innerhalb der Bewertungsmethoden identifiziert, untersucht und bewertet? Wie müssen die Anforderungen spezifiziert werden, damit diese im Kontext der Bewertung analysiert werden können? 3. Konzept der Pattern: Wie lässt sich das Konzept der Pattern innerhalb des Entwurfs und der Bewertung von Softwarearchitekturen einsetzen? Wie werden im Rahmen des Pattern-Konzepts die Entwurfsentscheidungen auf der Ebene der Softwarearchitektur und deren Auswirkungen auf die Qualität des Gesamtsystems dokumentiert? 4. Ermittlung und Dokumentation der Beziehungen: Wie können die Beziehungen zwischen den Entwurfsentscheidungen innerhalb der Softwarearchitektur und deren Auswirkungen auf die Qualität des Systems auf Basis des Pattern-Konzepts ermittelt und dokumentiert werden, so dass das existierende und erprobte Wissen über die Bezie-

4

Einleitung

hungen im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen wiederverwendet werden kann? Wie kann das bestehende Entwurfswissen über die Beziehungen strukturiert und aufbereitet werden, damit beim Entwurf und bei der Bewertung eine effiziente und effektive Wiederverwendung des Wissens erfolgen kann?

1.3

Forschungsansatz

Die vorliegende Arbeit entstand im Forschungsgebiet der Wirtschaftsinformatik, die analog zur Betriebswirtschaftslehre eine angewandte Wissenschaft darstellt (vgl. z. B. [Hein1993, S. 61 ff.; HeHR2004, S. 718-720]). Die Probleme, die eine angewandte Wissenschaft aufgreift, entstehen in der Praxis und bilden den Ausgangspunkt für einen Forschungskreislauf, der sich über die Praxis und die Wissenschaft erstreckt: Die Problemstellungen werden zunächst in der Praxis identifiziert. Sie werden dann anschließend durch die Wissenschaft analysiert, verallgemeinert und strukturiert. Die Lösung der Probleme erfolgt auf Basis von theoretischem Wissen und auf der Basis von entsprechenden Erfahrungen, die in der Praxis gesammelt wurden. Die Lösungen werden als Vorschläge von der Praxis übernommen und bei der Gestaltung der (betrieblichen) Realität angewendet. Im Rahmen der Anwendung können neue Probleme entstehen, die wiederum von der Wissenschaft aufgegriffen werden. Der grundlegende methodische Ansatz der vorliegenden Arbeit ist gestaltungsorientiert, d. h. das abstrakte Ziel ist eine nutzbringende Konstruktion. Hevner, March, Park und Ram beschreiben für diesen Forschungsansatz, den sie mit „design science research“ bezeichnen, sieben Richtlinien, die bei der Durchführung, Bewertung und Darstellung von gestaltungsorientierter Forschung beachtet werden sollen (vgl. [HMPR2004, S. 82 ff.]): ƒ Richtlinie 1: Entwicklung eines innovativen Artefakts: Das Ergebnis eines gestaltungs-

orientierten Forschungsvorhabens muss ein sog. IT-Artefakt sein, das entworfen wird, um ein wichtiges organisatorisches Problem zu lösen. Ein IT-Artefakt kann eine Konstruktion, ein Modell, eine Methode oder eine entsprechende Instanziierung sein, die im Kontext der Entwicklung und/oder Verwendung von IT-Systemen nutzbar ist. ƒ Richtlinie 2: Relevanz der wissenschaftlichen Problemstellung: Das Ziel eines gestal-

tungsorientierten Forschungsvorhabens ist die Entwicklung einer IT-orientierten Lösung zu einem bedeutenden und wichtigen (betriebswirtschaftlichen) Problem. ƒ Richtlinie 3: Evaluation der Entwicklung: Der Nutzen, die Qualität und die Genauigkeit

der Entwicklung müssen auf Basis einer Methode nachgewiesen werden. Die bewertenden Methoden können z. B. Fallstudien, Experimente und induktive bzw. deduktive Argumentationen umfassen.

Forschungsansatz

5

ƒ Richtlinie 4: Beitrag zum Erkenntnisfortschritt: Ein gestaltungsorientiertes Forschungs-

vorhaben muss einen deutlichen und überprüfbaren Beitrag in den Bereichen der ITArtefakte, den Grundlagen und/oder der Vorgehensweisen leisten. ƒ Richtline 5: Stringenz der Forschungsaktivitäten: Der Entwurf eines IT-Artefakts erfor-

dert die Anwendung von genauen Methoden innerhalb der Konstruktion und Bewertung des Artefakts. Die gestaltungsorientierte Forschung verwendet hierzu häufig mathematische Formalismen, um die IT-Artefakte zu beschreiben. Dabei muss beachtet werden, dass sich das Artefakt und die Umgebung, in der es eingesetzt werden soll, einer übertriebenen formellen Beschreibung widersetzen können. Die Stringenz der Forschung muss daher mit der Anwendbarkeit und Allgemeingültigkeit des Artefakts abgewogen werden. ƒ Richtline 6: Vorgehensweise der Entwicklung entspricht einem Prozess der Lösungs-

suche: Eine Entwicklung stellt grundsätzlich die Suche nach einer effizienten und effektiven Lösung zu einem bestimmten Problem dar. Der Prozess der Lösungssuche umfasst die Nutzung der verfügbaren Mittel zur Erreichung eines definierten Ziels und die Berücksichtigung der Gesetzmäßigkeiten der Umgebung in der das Problem auftritt. Der Lösungsraum umfasst alle Kombinationen der verfügbaren Mittel, die das definierte Ziel erreichen und die Gesetzmäßigkeiten der Problemumgebung nicht verletzen. Die Ermittlung einer „optimalen“ Lösung ist häufig aufgrund des großen Umfangs des Lösungsraums nicht mit vertretbarem Aufwand möglich, so dass die Suche nach einer geeigneten Lösung in den Vordergrund tritt und nicht alle möglichen Lösungen beschrieben werden. ƒ Richtlinie 7: Kommunikation der Forschungsergebnisse: Die Forschungsarbeiten und

-ergebnisse müssen sowohl einem technologie- als auch einem management-orientierten Publikum zugänglich sein. Die technologie-orientierte Zielgruppe benötigt ausreichend detaillierte Informationen, um das IT-Artefakt im organisatorischen Kontext zu erstellen bzw. zu implementieren. Darüber hinaus ist für diese Zielgruppe insbesondere der Prozess der Konstruktion und Bewertung des Artefakts relevant, um die Reproduzierbarkeit der Ergebnisse zu gewährleisten und die Grundlage für die Weiterentwicklung zu definieren. Die management-orientierte Zielgruppe dagegen benötigt ausreichend Informationen, um zu beurteilen, ob das IT-Artefakt im organisatorischen Kontext nutzbringend eingesetzt werden kann. Hevner, March, Park und Ram verfolgen mit ihrer Definition der sieben Richtlinien das Ziel, Forscher, Gutachter und Herausgeber bei der Analyse und Bewertung von Forschungsbeiträgen zu unterstützen (vgl. [HMPR2004, S. 82]). Sie fordern zwar nicht, dass die Richtlinien in jedem Forschungsprojekt zwingend angewendet werden, sondern verweisen auf die Kreativität und das Beurteilungsvermögen der Forscher, Gutachter und Herausgeber. Sie sind allerdings der Auffassung, dass im Kontext einer gestaltungsorientierten Forschungsarbeit alle sie-

6

Einleitung

ben Richtlinien adressiert werden sollten, damit die Vollständigkeit des Forschungsbeitrags gewährleistet ist. Die Richtlinien sind aus einer wissenschaftstheoretischen Perspektive durchaus kritisierbar (vgl. [Zele2007]). Sie sind dennoch gut geeignet, die vorliegende Arbeit im wissenschaftstheoretischen Kontext zu positionieren: ƒ Richtlinie 1: Das wesentliches Ergebnis der Arbeit ist ein Wissensmodell und eine

Vorgehensweise zum Aufbau einer Wissensbasis, auf deren Grundlage die Entwurfsentscheidungen innerhalb der Softwarearchitektur und deren Auswirkungen auf die Qualität des Systems ermittelt und dokumentiert werden können. Das Modell kann im Kontext des Entwurfs und der Bewertung einer Softwarearchitektur nutzbringend verwendet werden. ƒ Richtlinie 2: Die Relevanz der wissenschaftlichen Problemstellung wird in den Kapiteln

1, 1 und 1 sukzessiv herausgearbeitet und erläutert (siehe Kapitel 1.4). ƒ Richtlinie 3: Die Qualität und Genauigkeit des Entwurfs des Wissensmodells wird durch

eine entsprechende, beispielhafte Umsetzung in Kapitel 5.3 validiert. Der Nutzen und die Anwendbarkeit des Wissensmodells im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen wird in Kapitel 5.4 beschrieben und durch eine entsprechende induktive bzw. deduktive Argumentation begründet. ƒ Richtlinie 4: Der Forschungsbeitrag der vorliegenden Arbeit wird durch die Beschrei-

bungen und Untersuchungen in den Kapiteln 1, 1 und 1 dargestellt. In Kapitel 2.6 werden andere Beiträge explizit vom Beitrag dieser Arbeit abgegrenzt. ƒ Richtlinie 5: Der Entwurf des Wissensmodells wird in Kapitel 5.1 detailliert erläutert

und die Struktur sowie der Aufbau des Modells werden umfassend beschrieben. Die Inhalte des Wissensmodells basieren auf einer Syntax, die mit einer erweiterten BackusNaur-Form (EBNF) spezifiziert wird (siehe Anhang A). Die Vorgehensweise zum Aufbau einer Wissensbasis wird in Kapitel 5.2 detailliert beschrieben. Der Prozess und die wesentlichen Aktivitäten werden auf Basis der Unified Modeling Language (UML) dokumentiert (siehe Kapitel 5.2.2.1). ƒ Richtlinie 6: Das Wissensmodell und die Vorgehensweise, die in der vorliegenden Ar-

beit entwickelt und beschrieben werden, stellen eine geeignete Lösung im Kontext der Problemstellung dar. Das Ziel der vorliegenden Arbeit besteht nicht darin, alle Lösungen in diesem Zusammenhang zu identifizieren. ƒ Richtlinie 7: Die Struktur, der Aufbau, die Sprache und der Detaillierungsgrad der vor-

liegenden Arbeit adressieren sowohl die technologie- als auch die management-orientierte Zielgruppe, wobei aber Kenntnisse der Wirtschaftsinformatik, der Informatik und insbesondere der Softwaretechnik eine notwendige Voraussetzung sind.

Aufbau der Arbeit

1.4

7

Aufbau der Arbeit

Die Grundlagen und der Bezugsrahmen des Entwurfs von Softwarearchitekturen werden im zweiten Kapitel erarbeitet (siehe Abbildung 1-1). Zunächst wird die historische Entwicklung des Konzepts der Softwarearchitekturen auf Basis von verschiedenen Begriffsdefinitionen erläutert und diskutiert. Zur Bildung eines Bezugsrahmens für die vorliegende Arbeit wird anschließend das Konzept der Softwarearchitektur in das übergeordnete Konzept der Unternehmensarchitektur eingeordnet. Die folgende Diskussion der Bedeutung der Softwarearchitektur geht auf die Frage ein, wozu eine Softwarearchitektur definiert und wie sie im Kontext des Softwareentwicklungsprozesses verwendet wird. Darüber hinaus werden die Einflussfaktoren einer Softwarearchitektur und die Grundlagen der Dokumentation von Softwarearchitekturen betrachtet. Den Abschluss des zweiten Kapitels bildet eine Darstellung der Arbeiten, die im Hinblick auf die Problemstellung als „verwandt“ mit der vorliegenden Arbeit einzustufen sind.

Kapitel 1: Einleitung

Kapitel 2: Grundlagen und Bezugsrahmen des Entwurfs von Softwarearchitekturen

Kapitel 3: Bewertung von Softwarearchitekturen

Kapitel 4: Pattern im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen

Kapitel 5: Entwicklung eines pattern-basierten Wissensmodells

Kapitel 6: Schlussbetrachtung

Abbildung 1-1: Aufbau der Arbeit

Das dritte Kapitel betrachtet die Konzepte und Methoden zur Bewertung von Softwarearchitekturen. Hierzu werden zunächst die grundlegenden Ziele und Annahmen der Bewertung von

8

Einleitung

Softwarearchitekturen erläutert und insbesondere die Auswirkungen der Entwurfsentscheidungen innerhalb der Softwarearchitektur auf die Qualität des Systems diskutiert. Anschließend werden die verschiedenen Konzepte und Modelle der Softwarequalität beschrieben und analysiert, wie die Qualitätsmodelle zur Definition und Überprüfung von Anforderungen im Kontext der Softwarearchitekturen eingesetzt werden können. Nachfolgend werden die Methoden zur Bewertung einer Softwarearchitektur erläutert; insbesondere wird untersucht, wie diese die Beziehungen zwischen den Entwurfsentscheidungen innerhalb der Softwarearchitektur und deren Auswirkungen auf die Qualität des Systems identifizieren, analysieren und bewerten. Im vierten Kapitel wird das Konzept der Pattern im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen betrachtet. Zunächst wird das Pattern-Konzept aus verschiedenen Perspektiven beschrieben und die Anwendbarkeit des Konzepts innerhalb des Entwurfs und der Bewertung von Softwarearchitekturen untersucht. Im besonderen Fokus der Untersuchung steht die Frage, wie im Rahmen des Pattern-Konzepts die Entwurfsentscheidungen innerhalb der Softwarearchitektur und deren Auswirkungen auf die Qualität des Gesamtsystems dokumentiert werden. Die Ergebnisse der Untersuchungen in Kapitel 1 und 1 bilden die Basis für die Entwicklung eines pattern-basierten Wissensmodells im fünften Kapitel. Das Kapitel beschreibt zunächst die Entwicklung eines Wissensmodells, das die Grundlage für die Dokumentation der Beziehungen zwischen den Entwurfsentscheidungen innerhalb der Softwarearchitektur und deren Auswirkungen auf die Qualität des Systems bildet. Der Aufbau einer Wissensbasis erfolgt mit einer Vorgehensweise, deren Entwicklung im Anschluss erläutert wird. Das fünfte Kapitel umfasst darüber hinaus eine Beschreibung der Validierung des Wissensmodells und der Vorgehensweise. Den Abschluss des fünften Kapitels bildet eine Darstellung der Verwendung der Wissensbasis im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen. Das letzte Kapitel der vorliegenden Arbeit fasst die Ergebnisse zusammen, identifiziert den weiteren Forschungsbedarf und gibt einen Ausblick hinsichtlich des Entwurfs und der Bewertung von Softwarearchitekturen.

2 Grundlagen und Bezugsrahmen des Entwurfs von Softwarearchitekturen Im Folgenden werden die Grundlagen der Arbeit erarbeitet und ein Bezugsrahmen für den Entwurf von Softwarearchitekturen entwickelt. Dazu werden in Kapitel 2.1 verschiedene Begriffsdefinitionen vorgestellt, die die historische Entwicklung des Konzepts der Softwarearchitektur aufzeigen. Das Kapitel 2.2 erläutert den Bezugsrahmen, der der Arbeit zugrunde liegt, und ordnet das Konzept der Softwarearchitektur in das übergeordnete Konzept der Unternehmensarchitektur ein. Außerdem werden weitere Begriffe und Konzepte abgegrenzt. In Kapitel 2.3 wird die Bedeutung der Softwarearchitektur charakterisiert und die Frage diskutiert, wozu eine Softwarearchitektur definiert und innerhalb des Softwareentwicklungsprozesses verwendet wird. Das Kapitel 2.4 stellt die Faktoren vor, die eine Softwarearchitektur beeinflussen. Es werden die Beziehungen zwischen der Softwarearchitektur eines Systems und der Umgebung aufgezeigt, in der die Softwarearchitektur entsteht, eingesetzt und weiterentwickelt wird. Die wesentlichen Aspekte der Dokumentation einer Softwarearchitektur und das Sichtenkonzept werden in Kapitel 2.5 vorgestellt, da die Dokumentation die Grundlage für die Nutzung der Softwarearchitektur ist. Das abschließende Kapitel 2.6 erläutert und bewertet drei verwandte Arbeiten, deren Zielsetzungen zu den Forschungsfragen der vorliegenden Arbeit eine sehr hohe Ähnlichkeit aufweisen und deren Ergebnisse einen Beitrag zur Beantwortung der Fragen leisten können.

2.1

Begriffsdefinitionen

Für den Begriff der Softwarearchitektur existiert keine einheitliche, allgemein anerkannte Definition (vgl. z. B. [BaCK2003, S. 21; KrOS2006, S. 23]). Die Website des Software Engineering-Instituts (SEI)2 der Carnegie Mellon Universität listet z. B. über 30 unterschiedliche Begriffsdefinitionen, die entsprechenden Veröffentlichungen entnommen wurden3. Die Besucher der Website werden außerdem aufgefordert, ihr Verständnis des Begriffs in der Form einer Definition zu dokumentieren; weit über 150 Definitionen wurden dort bisher formuliert4. Um im Kontext der vorliegenden Arbeit ein einheitliches Begriffsverständnis zu etablieren, werden im Folgenden, auf Basis ausgewählter Begriffsdefinitionen, die wesentlichen Konzepte, Sichtweisen und Prinzipien im Bereich der Softwarearchitektur diskutiert. Insbesondere 2 3 4

Siehe http://www.sei.cmu.edu/ Siehe http://www.sei.cmu.edu/architecture/published_definitions.html Siehe http://www.sei.cmu.edu/architecture/community_definitions.html

10

Grundlagen und Bezugsrahmen des Entwurfs von Softwarearchitekturen

werden die Implikationen dargestellt, die sich aus der jeweiligen Definition ergeben. Schließlich werden die Begriffsdefinitionen identifiziert, die sich für die Verwendung in der vorliegenden Arbeit eignen. Der Begriff der „Architektur“ wurde bis in die späten 80er-Jahre primär im Sinne einer Systemarchitektur verwendet, die sich auf die physische Struktur eines Systems, d. h. auf die Hardware-Komponenten, bezog (vgl. [KrOS2006, S. 23]). Der Begriff der Softwarearchitektur wurde zum ersten Mal 1969 auf einer Konferenz der North Atlantic Treaty Organization (NATO) verwendet [KrOS2006, S. 23 f.]. Im Rahmen einer Diskussion zur Theorie und Praxis der Softwaretechnik ging Ian P. Sharp auf den Begriff und die wesentlichen Kerngedanken der Softwarearchitektur ein: „I think that we have something in addition to software engineering: something that we have talked about in small ways but which should be brought out into the open and have attention focused on it. This is the subject of software architecture. Architecture is different from engineering. As an example of what I mean, take a look at OS/360. Parts of OS/360 are extremely well coded. Parts of OS, if you go into it in detail, have used all the techniques and all the ideas which we have agreed are good programming practice. The reason that OS is an amorphous lump of program is that it had no architect. Its design was delegated to a series of groups of engineers, each of whom had to invent their own architecture. And when these lumps were nailed together they did not produce a smooth and beautiful piece of software.” [BuRa1970, S. 12]. Am Beispiel des Betriebssystems OS/360 identifizierte Sharp die Problematik, dass bei der Entwicklung von großen Systemen ein „übergeordneter Rahmen“ vorhanden sein muss, der die einzelnen Programme „zusammenhält“ und somit eine einheitliche Qualität des gesamten Systems gewährleistet. Dieser Rahmen wurde von Sharp als „Softwarearchitektur“ bezeichnet, da er sich auf die Struktur der Programme, d. h. die Software, eines Systems bezog. Die Relevanz der Strukturierung und Partitionierung von Programmen wurde allerdings bereits 1967 von Dijkstra diskutiert (siehe [Dijk1967; Dijk1968]): Im Kontext der Entwicklung von Betriebssystemen stellte er die Idee vor, Programme in Schichten zu gruppieren und zwischen den Schichten strikt hierarchische Zugriffsregeln zu definieren. Er betonte, dass durch die Strukturierung in Schichten die konzeptuelle Integrität sichergestellt und das Testen vereinfacht wird. Er stellte bereits 1967 die folgende These auf: Je größer ein System ist, desto wichtiger ist die Strukturierung des Systems (vgl. [Dijk1967]). Die Arbeiten von Dijkstra bilden die Grundlage für das Konzept der Schichtenmodelle bzw. Schichtenarchitekturen, das in Wissenschaft und Praxis weit verbreitet ist. Beispiele sind das ISO5/OSI6-Referenzmodell zur Kommunikation in offenen Systemen (siehe [ISIE1994]) und 5

International Organization for Standardization (ISO)

Begriffsdefinitionen

11

die standardisierte, mehrschichtige Softwarearchitektur, die als Teil der Java Platform, Enterprise Edition (Java EE)-Spezifikation7 definiert wird (siehe [Sun2006]). Die Strukturierung und Organisation von Softwaresystemen wurde dann sukzessiv untersucht und weiterentwickelt (vgl. [BaCK2003, S. 43 ff.; KrOS2006]): Brooks diskutiert ausführlich die Differenzierung zwischen der Architektur und der Implementierung eines Systems und erläutert diese Unterscheidung durch ein Zitat von Blaauw: Die Architektur beschreibt was passiert und die Implementierung beschreibt wie etwas passiert (vgl. [Broo1995, S. 45])8. Diese einfache Abgrenzung bildet noch heute einen wesentlichen Aspekt für die Erläuterung des Konzepts der Softwarearchitektur. Parnas beschrieb in den frühen 70er-Jahren grundlegende Prinzipien der Softwaretechnik, die noch heute Gültigkeit besitzen und auch für die Softwarearchitektur relevant sind. Zu diesen Prinzipien zählt das sog. Information Hiding, d. h. das Prinzip, ein System in Elemente zu strukturieren und zwischen öffentlichen und privaten Eigenschaften der Elemente zu unterscheiden (vgl. [Parn1972]). Die privaten Eigenschaften müssen für die Nutzung eines Elements nicht bekannt sein und ermöglichen es somit, Informationen innerhalb eines Elements zu „verstecken“. Dieses Prinzip bildet die Grundlage für die Entwicklung der objektorientierten Programmiersprachen (siehe z. B. [GJSB2005]) und der Komponenten-Technologien (siehe z. B. [Sun2005]). Darüber hinaus hat Parnas die grundlegenden Prinzipien der Fehlererkennung und -behandlung in Bezug auf die Interaktion zwischen Programmen bzw. Schichten beschrieben (siehe [Parn1972; Parn1976]); sie bilden die Basis für das Konzept der sog. Exceptions, wie es moderne Programmiersprachen umsetzen. Parnas hat außerdem bereits erkannt, dass die Struktur eines Systems die Qualitätsmerkmale des Systems wesentlich beeinflusst (vgl. [Parn1976]). Auch für das Konzept der sog. Software-Produktlinien (vgl. z. B. [ClNo2002]) legte Parnas die Grundlagen, indem er ein Programm als Mitglied einer Familie von Programmen einordnete und die Entwurfsentscheidungen auf der Ebene einer sog. Programm-Familie (program family) von den Entwurfsentscheidungen auf der Ebene der einzelnen Programme trennte (vgl. [Parn1976]). Diese Prinzipien wurden nicht ausschließlich von Parnas entwickelt; er dokumentierte Methoden und Vorgehensweisen, die „gute“ Programmierer für geraume Zeit bereits bei der Entwicklung von Betriebssystemen erfolgreich verwendeten [BaCK2003, S. 44]. Die Arbeiten von Parnas lassen sich daher mit dem Konzept der Pattern vergleichen, die generische und erprobte Lösungsansätze für spezifische Problemstellungen beschreiben (siehe Kapitel 1). Abstrahiert man von den einzelnen Ergebnissen der Beiträge, haben die Arbeiten von Parnas

6 7

8

Open Systems Interconnection (OSI) Mit der Version 5 der Spezifikation wurde der Name von „Java 2 Platform, Enterprise Edition (J2EE)“ nach „Java Platform, Enterprise Edition (Java EE)“ geändert. Die Quellenangabe bezieht sich auf die Jubiläumsauflage von 1995. Die erste Auflage ist bereits 1975 erschienen.

12

Grundlagen und Bezugsrahmen des Entwurfs von Softwarearchitekturen

wesentlich zur Erkenntnis beigetragen, dass die „übergeordnete Struktur“ der Programme bzw. Elemente von Relevanz für die Qualität eines Systems ist. Innerhalb dieser Strukturen erkannten „gute“ System-Designer Gemeinsamkeiten und wiederkehrende Stile, die aber zunächst nicht strukturiert untersucht worden sind (vgl. [Shaw2001]). Ab den 90er-Jahren wurden diese Strukturen und Stile verstärkt unter dem Begriff der „Softwarearchitektur“ analysiert und erste grundlegende Modelle zu dem Konzept der Softwarearchitektur entwickelt. Perry und Wolf entwickelten ein formales Modell der Softwarearchitektur; es sieht Datenelemente (data elements), Verarbeitungsschritte (processing steps) und Verbindungen (connections) sowie Beziehungen (relationships), Eigenschaften (properties) und Einschränkungen (constraints) der Elemente als die wesentlichen Bestandteile einer Softwarearchitektur vor (vgl. [PeWo1992]). Von Perry und Wolf stammt außerdem das Konzept des sog. Architektur-Stils, der eine bestimmte Anordnung und Einschränkung der grundlegenden Elemente einer Softwarearchitektur repräsentiert. Sie beschreiben informell die Softwarearchitektur als einen Rahmen, in dem die Anforderungen des Systems umgesetzt, sowie die technischen und wirtschaftlichen Grundlagen für den Entwurf und die Implementierung gelegt werden. Perry und Wolf sehen die Vorteile, die durch die Spezifikation einer Softwarearchitektur erreicht werden, in zwei Bereichen: erstens im Bereich der Analyse und zweitens im Bereich der Wiederverwendung. Die Spezifikation ermöglicht die Analyse hinsichtlich der Konsistenz der gesamten Softwarearchitektur und hinsichtlich der Abhängigkeiten innerhalb der Softwarearchitektur. Die Konsistenz wird auf der Ebene der Architektur und Architektur-Stile sowie im Zusammenhang mit den Anforderungen und dem Entwurf betrachtet. Durch die Analyse der Abhängigkeiten sollen die Beziehungen zwischen den Anforderungen, der Architektur und dem Entwurf ermittelt werden. Die Vorteile der Wiederverwendung sehen Perry und Wolf insbesondere im Bereich der Produktivitätssteigerung in der Entwurfs- und in der Implementierungsphase. Shaw und Garlan untersuchten ebenfalls die übergeordneten Strukturen und beschreiben das Konzept der Softwarearchitektur wie folgt: „Abstractly, software architecture involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on these patterns.“ [ShGa1996, S. 1]. Die Beschreibung ähnelt sehr der Definition von Perry und Wolf, wobei Shaw und Garlan keine formelle Begriffsdefinition vornehmen. Die Aspekte und Anforderungen eines formalen Modells für Softwarearchitekturen haben Shaw und Garlan aber an anderer Stelle ebenfalls diskutiert (vgl. [ShGa1996, S. 129 ff.]). Sie dokumentierten erstmals Architektur-Stile, die über mehrere Jahre hinweg in der Praxis von Designern entwickelt und verwendet worden sind (vgl. [ShGa1996, S. 19 ff.]). Die Architektur-Stile zeichnen sich dadurch aus, dass sie

Begriffsdefinitionen

13

Anordnungen und organisatorische Prinzipien spezifizieren, die mit einem bestimmten Mehrwert verbunden sind. Shaw und Garlan verwenden die Begriffe Architektur-Stil, Architektur-Pattern und Architektur-Idiom synonym und haben damit den Begriff des Architektur-Pattern geprägt (siehe Kapitel 1). Neben den theoretischen Grundlagen und Begriffsdefinitionen fokussieren sich andere Arbeiten auf die Integration des Softwarearchitektur-Konzepts in die Anforderungsanalyse und den Softwareentwicklungsprozess sowie auf die Rolle des sog. Softwarearchitekten (siehe [Lamp1983; Mill1985]). Bass, Clements und Kazman entwickelten ebenfalls eine informelle Begriffsdefinition für die Softwarearchitektur: "The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them." [BaCK2003, S. 21]. Die Definition unterteilt – im Gegensatz zu den zuvor dargestellten Definitionen – die Eigenschaften explizit in extern sichtbare und in extern unsichtbare Eigenschaften. Im Kontext der Softwarearchitektur sind nach Auffassung von Bass, Clements und Kazman lediglich die extern sichtbaren Eigenschaften der Softwareelemente relevant. Sie verweisen zwar nicht explizit auf das Prinzip des Information Hiding von Parnas, aber beide Konzepte haben offensichtlich viele Gemeinsamkeiten. Die Beschränkungen, die Shaw und Garlan bzw. Perry und Wolf in ihre Definitionen mit einbeziehen, spielen in der Begriffsdefinition von Bass, Clements und Kazman keine Rolle. Bass, Clements und Kazman diskutieren auch die Implikationen ihrer Definition, die für die vorliegende Arbeit ebenfalls relevant sind (vgl. [BaCK2003, S. 21-23]): Die Softwarearchitektur charakterisiert entsprechend der o. g. Definition Softwareelemente und die Beziehungen zwischen den Elementen. Informationen, die keinen Bezug zu diesen Softwareelementen und Beziehungen haben, werden nicht berücksichtigt. Die Softwarearchitektur ist somit eine Abstraktion des Systems und betrachtet ausschließlich die öffentlichen, d. h. extern sichtbaren, Teile eines Systems. Die privaten, d. h. extern nicht sichtbaren, Teile werden dagegen ausgeblendet; sie sind nicht architektur-relevant (architectural) (vgl. [BaCK2003, S. 21]). Diese Abgrenzung ist insbesondere für die Beantwortung der Frage entscheidend, welche Softwareelemente und Beziehungen als Teil einer Softwarearchitektur zu betrachten sind und welche nicht. Außerdem besteht nach Bass, Clements und Kazman eine Softwarearchitektur i. d. R. aus mehreren Strukturen. Sie spezifizieren in ihrer Definition aber bewusst nicht, worum es sich

14

Grundlagen und Bezugsrahmen des Entwurfs von Softwarearchitekturen

bei den architektur-relevanten Elementen und Beziehungen im Detail handelt, um die Allgemeingültigkeit der Definition zu erhalten. Eine weitere Folgerung aus der Definition ist, dass jedes rechner-basierte System auf Basis einer Software eine Softwarearchitektur besitzt. Bass, Clements und Kazman betonen, dass hieraus nicht abgeleitet werden kann, dass die Softwarearchitektur auch bekannt ist. In diesem Kontext weisen sie explizit darauf hin, dass zwischen der Softwarearchitektur eines Systems und der Repräsentation der Softwarearchitektur zu differenzieren ist. Beide können unabhängig voneinander existieren, d. h., eine Softwarearchitektur kann existieren, obwohl sie nicht dokumentiert ist, und der Entwurf einer Softwarearchitektur kann existieren, obwohl noch keine Implementierung stattgefunden hat. Nach Bass, Clements und Kazman ist das Verhalten jedes Elements Teil der Softwarearchitektur, jedoch muss nicht jedes Verhalten auf der Ebene der Softwarearchitektur gleich detailliert beschrieben werden. Zur Abgrenzung verwenden sie eine ähnliche Unterscheidung wie bei der Klassifikation in extern sichtbare und extern unsichtbare Eigenschaften: Jedes Verhalten, das die Akzeptanz des Gesamtsystems beeinflusst, ist als Teil der Softwarearchitektur zu betrachten [BaCK2003, S. 22 f.]. Diese Abgrenzung ist wiederum für die Beantwortung der Frage relevant, welches Verhalten als Teil einer Softwarearchitektur betrachtet werden muss und welches nicht: Zu unterscheiden ist zwischen architektur-relevantem Verhalten und anderem Verhalten. Schließlich weisen Bass, Clements und Kazman explizit darauf hin, dass ihre Definition keine Aussage über die Qualität einer Softwarearchitektur macht. Betrachtet man die Definition und insbesondere die Folgerungen von Bass, Clements und Kazman, so fällt auf, dass implizit eine wesentliche „Variable“ herausgearbeitet wird, die bestimmt, ob ein Softwareelement, eine Eigenschaft oder eine Beziehung architektur-relevant ist oder nicht. Diese Variable wird zwar nicht von Bass, Clements und Kazman (siehe [BaCK2003]), aber von Clements, Kazman und Klein näher untersucht (siehe [ClKK2002, S. 21 ff.]). Sie motivieren ihre Untersuchung mit der Beobachtung, dass diese Abgrenzung von hoher Relevanz für die Abstraktion, Dokumentation und Bewertung von Softwarearchitekturen ist, da sie bestimmt, welche Softwareelemente, Eigenschaften und Beziehungen in die jeweilige Betrachtung einzubeziehen sind und welche nicht. Clements, Kazman und Klein bezeichnen die Variable als „Kontext“ und definieren – insbesondere im Hinblick auf die Bewertung von Softwarearchitekturen – das folgende Kriterium zur Identifikation der Eigenschaft der „Architektur-Relevanz“: "It must be a component, or a relationship between components, or a property (of components or relationships) that needs to be externally visible in order to reason about the ability of the system to meet its quality requirements or to support

Bezugsrahmen

15

decomposition of the system into dependently implementable pieces." [ClKK2002, S. 22]. Alle Informationen, die eine Begründung zulassen, ob ein System seine Qualitätsanforderungen erfüllt, oder die Dekomposition eines Systems unterstützen, sind entsprechend der Definition architektur-relevant (vgl. [ClKK2002, S. 22]). Da sich der Kontext stets auf ein bestimmtes System bezieht, kann grundsätzlich nur im Bezug zu einem konkreten System bestimmt werden, welche Softwareelemente, Eigenschaften und Beziehungen ein Teil der Softwarearchitektur sind und welche nicht. Dieses Kriterium wird innerhalb der vorliegenden Arbeit genutzt, um Pattern auf der Architekturebene zu identifizieren (siehe Kapitel 5.2). Darüber hinaus dient das Kriterium im Weiteren zur Verfeinerung der Definition von Bass, Clements und Kazman, die grundlegend beschreibt, welche Bestandteile eine Softwarearchitektur besitzt. Das Kriterium von Clements, Kazman und Klein verfeinert diese Definition, indem die Bestandteile einer Softwarearchitektur weiter eingegrenzt werden und somit die Grundlage für die Konzepte der vorliegenden Arbeit z. B. im Bereich der Dokumentation (siehe Kapitel 2.5) und im Bereich der Bewertung (siehe Kapitel 1) bilden.

2.2

Bezugsrahmen

Die Diskussion der verschiedenen Begriffsdefinitionen im vorherigen Kapitel hat verdeutlicht, dass die Softwarearchitektur ausschließlich Softwareelemente betrachtet und von der Systemarchitektur, die sich auf die Hardwareelemente eines Systems bezieht, abgegrenzt werden muss. Heute wird anstelle des Begriffs der Systemarchitektur häufig der Begriff Hardwarearchitektur als Synonym verwendet. Die Begriffe beziehen sich auf unterschiedliche Abstraktionsebenen bei der Betrachtung eines Systems und damit auf unterschiedliche Elemente, unterschiedliche Beziehungen zwischen den Elementen und unterschiedliche Verhaltensweisen der Elemente. Der Entwurf auf den beiden referenzierten Ebenen kann deshalb prinzipiell unabhängig voneinander erfolgen (vgl. [ShGa1996, S. 4]). Eine vollständig isolierte Betrachtung der beiden Abstraktionsebenen ist aber nicht möglich, da die Softwareelemente auf Basis der Hardwareelemente implementiert bzw. ausgeführt werden und daher abhängig von der Hardwareebene sind. Die Softwarearchitektur wird von der zugrunde liegenden Systemarchitektur beeinflusst und muss auch bestimmte Aspekte der Systemarchitektur berücksichtigen oder zumindest bestimmte Annahmen bezüglich der Hardwareelemente treffen (vgl. [BaCK2003, S. 34]). Bass, Clements und Kazman verteidigen in diesem Zusammenhang die Betonung des Begriffs und die Bedeutung der Softwarearchitektur mit dem Argument, dass die Gestaltungsmöglichkeiten auf der Ebene der Software vielfältiger sind als auf der Ebene der Hardware und daher

16

Grundlagen und Bezugsrahmen des Entwurfs von Softwarearchitekturen

der Entwurf der Softwarearchitektur eine größere Bedeutung besitzt als der Entwurf einer Systemarchitektur (vgl. [BaCK2003, S. 34]). Sie weisen außerdem darauf hin, dass die Entwurfsentscheidungen bezüglich der Systemarchitektur häufig außerhalb des Einflussbereichs des Architekten bzw. Designers liegen, da z. B. betriebswirtschaftliche Aspekte, unternehmensweite Standards oder bereits existierende Hardware, die mit anderen Systemen bzw. Anwendungen geteilt werden muss, die Systemarchitektur beeinflussen. Ein Beispiel ist die Netzinfrastruktur, die i. d. R. nicht ausschließlich von einem System bzw. einer Anwendung genutzt, sondern von mehreren Systemen bzw. Anwendungen geteilt wird und daher vom Architekten bzw. Designer nicht direkt beeinflusst werden kann. Der Architekt bzw. Designer muss die Auslastung der Netzinfrastruktur durch die anderen Systeme bzw. Anwendungen analysieren und innerhalb des Entwurfs der Softwarearchitektur berücksichtigen. In der vorliegenden Arbeit wird der Argumentation von Bass, Clements und Kazman folgend ebenfalls der Begriff der Softwarearchitektur (vgl. Kapitel 2.1) verwendet und die implizite Annahme getroffen, dass die relevanten Aspekte der Systemarchitektur innerhalb des Entwurfs und der Bewertung berücksichtigt werden. Die Softwarearchitektur kann wiederum auf zwei unterschiedlichen Abstraktionsebenen betrachtet werden: erstens auf der Ebene einer einzelnen Anwendung und zweitens auf der Ebene des gesamten Unternehmens. Die erste Ebene betrachtet die einzelnen Softwareelemente einer Anwendung, die Beziehungen zwischen diesen Elementen und die Verhaltenweise dieser Elemente. Die Softwarearchitektur auf der Ebene des Unternehmens betrachtet dagegen die einzelnen Anwendungen eines Unternehmens, die Beziehungen zwischen diesen Anwendungen und die Verhaltensweise dieser Anwendungen. Diese Ebene wird im Folgenden als unternehmensweite Softwarearchitektur bezeichnet. Sie abstrahiert – analog zu den Eigenschaften eines Softwareelements – von den internen Eigenschaften einer Anwendung und betrachtet die Anwendungen bezüglich der Eigenschaften, die extern für andere Anwendungen sichtbar sind. Der wesentliche Unterschied zwischen beiden Konzepten liegt im Untersuchungsgegenstand: Auf der Ebene der Softwarearchitektur stehen die einzelnen Softwareelemente einer Anwendung im Vordergrund, wohingegen auf der Ebene der unternehmensweiten Softwarearchitektur der Fokus auf den einzelnen Anwendungen eines Unternehmens liegt und eine Anwendung als ein Softwareelement betrachtet wird. Innerhalb der vorliegenden Arbeit wird in erster Linie die Ebene einer Anwendung betrachtet und daher der Begriff der Softwarearchitektur verwendet. Die Ansätze und Konzepte können aber i. d. R. auch auf die Ebene der unternehmensweiten Softwarearchitektur übertragen werden, da die zugrunde liegenden Basiskonzepte ebenfalls auf beiden Abstraktionsebenen angewendet werden können9. 9

Als Beispiel sei das Konzept der Pattern genannt (siehe Kapitel 1). Es existieren Pattern-Kataloge, die Pattern auf der Ebene einer einzelnen Anwendung beschreiben (vgl. z. B. [AlCM2003]). Daneben betrachten andere Pattern-Kataloge ausschließlich Pattern für die Integration einzelner Anwendungen und abstrahieren von der Softwarearchitektur der einzelnen Anwendung (vgl. z. B. [HoWo2004]).

Bezugsrahmen

17

Daneben existieren zahlreiche weitere Ansätze, die den Begriff der Architektur aus einer ganzheitlichen Perspektive eines Unternehmens betrachten und neben den Softwareelementen und Anwendungen weitere Untersuchungsgegenstände, wie z. B. die Unternehmensstrategie, Geschäftsprozesse oder Organisationsstrukturen untersuchen. Diese Ansätze beschreiben sog. Informationssystem-Architekturen (vgl. [Krcm2005]) oder sog. Unternehmensarchitekturen (enterprise architectures) (vgl. [Zach1987]). Sie haben das Ziel, Wissen über die informationswirtschaftliche Nutzung und die technologischen Handlungsmöglichkeiten eines Unternehmens aus einer ganzheitlichen Perspektive zu betrachten [Krcm2005, S. 41]. Die Softwarearchitektur und die unternehmensweite Softwarearchitektur sind konzeptuelle Bestandteile dieser Ansätze und können innerhalb der verschiedenen Ansätze positioniert werden. Zur Definition des Bezugsrahmens der vorliegenden Arbeit werden im Folgenden zwei ausgewählte Ansätze kurz vorgestellt und die Softwarearchitektur bzw. die unternehmensweite Softwarearchitektur im Kontext dieser Ansätze dargestellt. Für einen weiteren Überblick der existierenden Ansätze sei an dieser Stelle auf eine Arbeit von Schekkerman verwiesen, der 14 derartige Ansätze zum Vergleich zusammengefasst hat (siehe [Sche2004]).

Data

Function

Network

People

Time

Motivation

Scope Business Model System Model Technology Model Components

Abbildung 2-1: Struktur und Aufbau des Zachman-Frameworks Quelle: in Anlehnung an [Zach1987, S. 463; SoZa1992, S. 600 f.]

Zachman entwickelte Ende der 80er-Jahre das sog. „framework for information system architecture“, um die Inkonsistenz bezüglich der Begriffe, Konzepte und Notationen im Umfeld der Informationssystem-Architekturen auszuräumen (vgl. [Zach1987]). Er verweist auf die große Relevanz dieser Thematik und die Notwendigkeit, eine Unternehmensarchitektur auf Basis einer strukturierten Vorgehensweise und den entsprechenden Werkzeugen zu entwickeln bzw. zu steuern. Die Entwicklung derartiger Vorgehensweisen und Werkzeuge sah Zachman aufgrund der Vielfalt der Begriffe, Konzepte und Notationen gefährdet, und erkannte die Notwendigkeit, ein Bezugssystem (framework) zu entwickeln, das als ZachmanFramework bezeichnet wird (vgl. [Zach1987; SoZa1992]). Das Bezugssystem basiert auf einer Matrix, die aus zwei Dimensionen aufgespannt wird (vgl. Abbildung 2-1).

18

Grundlagen und Bezugsrahmen des Entwurfs von Softwarearchitekturen

Die Zeilen unterscheiden verschiedene Abstraktionsebenen, auf denen Modelle erstellt werden, die bezüglich ihres Inhalts, ihrer Bedeutung, ihrer Motivation usw. unterschiedlich sind (vgl. [Zach1987]): ƒ Die Ebene des Umfangs (Scope) beschreibt den Anwendungsbereich, die grundsätzliche

Funktionalität und die Kosten eines Informationssystems. ƒ Die Abstraktionsebene des Geschäftsmodells (Business Model) stellt den „Entwurf“ des

Geschäfts dar, d. h., die wesentlichen Geschäftsobjekte und wie diese mit den Geschäftsprozessen interagieren. ƒ Das Systemmodell (System Model) charakterisiert eine Ebene, die entsprechende Mo-

delle bezüglich der „Systeme“ des Unternehmens enthält, die die Grundlage zur Verwaltung der Geschäftsobjekte und Ausführung der Geschäftsprozesse bilden. Diese „Systeme“ müssen nicht zwangsweise auf einer Informationstechnologie (IT) basieren, sondern können auch aus (ausschließlich) manuellen Prozessen und/oder Arbeitsschritten bestehen (vgl. [SoZa1992]). ƒ Die Ebene des Technologiemodells (Technology Model) betrachtet die detaillierten Ent-

würfe, die das Systemmodell auf Basis einer bestimmten Technologie, Entwicklungsplattform usw. verfeinern und insbesondere die Beschränkungen der zugrunde liegenden Technologie und Plattform berücksichtigen. 10

ƒ Die Ebene der Komponenten (Components)

umfasst die Umsetzung des Technologiemodells auf Basis von Programmiersprachen, Datenbeschreibungssprachen und Konfigurationsdaten.

Die Spalten beschreiben grundlegende Perspektiven, die auf jeder Abstraktionsebene eingenommen werden können. Die sechs Perspektiven gewährleisten auf jeder Ebene die Vollständigkeit bezüglich der in den Modellen betrachteten Aspekte: ƒ Die Spalte der Daten (Data) identifiziert die Entitäten des Unternehmens auf den unter-

schiedlichen Abstraktionsebenen, d. h., innerhalb dieser Perspektive werden z. B. Geschäftsobjekte, Stamm- und Bewegungsdaten, Datenbanktabellen oder Felddefinitionen betrachtet. ƒ Die Spalte der Funktionen (Function) betrachtet – wie die Bezeichnung bereits andeu-

tet – die Funktionen auf den unterschiedlichen Ebenen, so dass z. B. Geschäftsprozesse, Anwendungsfunktionen oder Methoden einer Klasse beschrieben werden. ƒ Innerhalb der Spalte „Netzwerk“ (Network) werden die Aspekte der Verteilung darge-

stellt.

10

Diese Ebene wurde in der ersten Veröffentlichung des Zachman-Frameworks als „detaillierte Beschreibung“ (detailed description) bezeichnet (siehe [Zach1987]).

Bezugsrahmen

19

ƒ In der Spalte „Personen“ (People) werden Rollen und deren Verantwortlichkeiten be-

schrieben. ƒ Die Spalte „Zeit“ (Time) stellt die zeitliche Reihenfolge von z. B. Geschäftsprozessen,

Anwendungsfunktionen oder Methodenaufrufen dar. ƒ Die Spalte der Motivation (Motivation) schließlich berücksichtigt Ziele und Beweg-

gründe auf den unterschiedlichen Abstraktionsebenen. Innerhalb der Matrix ist jede Zeile und Spalte eindeutig von den anderen Zeilen und Spalten abgrenzbar, so dass exakt beschrieben werden kann, was sich inhaltlich in jedes Tabellenfeld einordnet (vgl. [Zach1987]). Unterschiedliche Begriffe, Konzepte und Notationen können deshalb innerhalb der Matrix eindeutig positioniert werden. Die Matrix kann auch verwendet werden, um im Kontext der Gestaltung einer Unternehmensarchitektur die Vollständigkeit der berücksichtigten Abstraktionsebenen und Perspektiven zu gewährleisten. Obwohl das Zachman-Framework einige Begriffe verwendet, die heute nicht weit verbreitet (z. B. Technologiemodell) oder semantisch vieldeutig sind (z. B. Komponenten), kann die grundsätzliche Struktur, die durch die Abstraktionsebenen und Perspektiven definiert wird, zur Klassifikation von Begriffen, Konzepten und Notationen verwendet werden: Die Softwarearchitektur und die unternehmensweite Softwarearchitektur können auf der Ebene des Systemmodells eingeordnet werden. Sie verfeinern diese Ebene aufgrund der unterschiedlichen Untersuchungsgegenstände in zwei weitere Abstraktionsebenen (siehe Abbildung 2-2).

Abbildung 2-2: Positionierung der Softwarearchitektur im Zachman-Framework Quelle: in Anlehnung an [Zach1987, S. 463; SoZa1992, S. 600 f.]

Beide Ebenen, auf denen die Softwarearchitektur untersucht werden kann, müssen alle Perspektiven des Zachman-Frameworks berücksichtigen11. 11

Die unterschiedlichen Perspektiven einer Softwarearchitektur werden in Kapitel 2.5 detailliert diskutiert.

20

Grundlagen und Bezugsrahmen des Entwurfs von Softwarearchitekturen

Ein anderer Ansatz, den Begriff der Architektur aus einer ganzheitlichen Perspektive eines Unternehmens zu betrachten, ist das sog. Modell der Informationssystem-Architektur (ISA) von Krcmar (vgl. [Krcm1990]), das in der Abbildung 2-3 dargestellt wird.

Stategie

ProzessArchitektur

AnwendungsArchitektur

Da Archi

Infra

AufbauorganisationsArchitektur

ten tektur

KommunikationsArchitektur

struktur

Abbildung 2-3: Modell der Informationssystem-Architektur Quelle: in Anlehnung an [Krcm1990, S. 399]

Die oberste Ebene des Modells enthält die Geschäftsstrategie, deren grundsätzliche Richtung und Vision sich – angedeutet durch den Pfeil – durch das gesamte Unternehmen und alle eingesetzten Systeme zieht. Die zweite Ebene beinhaltet organisatorische Aspekte, d. h., die Aufbau- und Ablauforganisation des Unternehmens, wobei die Ablauforganisation im Kontext des Modells als Prozessarchitektur bezeichnet wird. Innerhalb der dritten Ebene differenziert Krcmar drei Architekturtypen, die auf Basis von drei Perspektiven (Anwendungen, Daten und Kommunikation) abgeleitet werden: ƒ Die sog. Anwendungs-Architektur beschreibt Funktionen (Prozesse und ihre Unterstüt-

zung), ƒ die sog. Daten-Architektur betrachtet die statischen Zusammenhänge zwischen den

Daten auf Basis von Datenmodellen und ƒ die sog. Kommunikations-Architektur spezifiziert die Informationsflüsse zwischen den

Anwendungen und Daten auf einer logischen Ebene. Die vierte Schicht stellt die zugrunde liegende Informations- und Kommunikationstechnologie, die innerhalb des Unternehmens genutzt wird, dar.

Bedeutung der Softwarearchitektur

21

Die Kreiselform des Modells wurde von Krcmar bewusst ausgewählt, um zu verdeutlichen, dass alle Teile der Informationssystem-Architektur ausbalanciert sein müssen; wird ein Teil des Modells entfernt, gerät die Informationssystem-Architektur aus dem Gleichgewicht (vgl. [Krcm1990, S. 399]). Die Softwarearchitektur und die unternehmensweite Softwarearchitektur können innerhalb der dritten Ebene des Modells der Informationssystem-Architektur eingeordnet werden. Analog zur Positionierung im Zachman-Framework wird die dritte Ebene aufgrund der unterschiedlichen Untersuchungsgegenstände in zwei Abstraktionsebenen verfeinert (siehe Abbildung 2-4).

Stategie

ProzessArchitektur

AufbauorganisationsArchitektur

unternehmensweite Softwarearchitektur AnwenKommuDa ten dungsnikationsArchi tektur Architektur Softwarearchitektur Architektur

Infra

struktur

Abbildung 2-4: Positionierung der Softwarearchitektur im Modell der Informationssystem-Architektur Quelle: in Anlehnung an [Krcm1990, S. 399]

Die Softwarearchitektur und die unternehmensweite Softwarearchitektur müssen – wie bereits bei der Positionierung im Zachman-Framework diskutiert – mehrere Perspektiven berücksichtigen. Diese Perspektiven beinhalten auch die von Krcmar verwendeten Perspektiven, so dass durch das Konzept der Softwarearchitektur alle drei Architekturtypen der dritten Ebene abgedeckt sind (vgl. Abbildung 2-4).

2.3

Bedeutung der Softwarearchitektur

Die Bedeutung der Softwarearchitektur wurde bereits von Dijkstra Ende der 60er Jahre erkannt. Er stellte 1967 die These auf, dass mit der steigenden Größe der Systeme, die Strukturierung der Systeme eine zunehmende Bedeutung erhält (vgl. Kapitel 2.1). Parnas wies bereits

22

Grundlagen und Bezugsrahmen des Entwurfs von Softwarearchitekturen

Mitte der 70er Jahre darauf hin, dass zwischen der Struktur und der Qualität eines Systems ein enger Zusammenhang besteht (vgl. [Parn1976]). Shaw und Garlan verweisen im Kontext einer Diskussion der Bedeutung der Softwarearchitektur auf die steigende Größe und Komplexität der Softwaresysteme und leiten daraus ab, dass dem Entwurf und der Spezifikation der übergeordeten Struktur eines Systems eine größere Bedeutung zukommt als der Auswahl von Algorithmen und Datenstrukturen (vgl. [ShGa1996, S. 1]). Sie argumentieren, dass der Entwurf von Software auf unterschiedlichen Abstraktionsebenen erfolgt (vgl. [ShGa1996, S. 4]). Auf jeder Ebene werden primitive und zusammengesetzte Elemente, bestimmte Regeln der Kombination der Elemente und die Verhaltensweisen der Elemente betrachtet. Auf der Ebene einer Programmiersprache sind diese Elemente z. B. Zahlen, Zeichen, Zeiger oder Kontrollstrukturen und die Regeln zur Kombination dieser Elemente werden z. B. durch die arithmetischen Operationen der Sprache bestimmt (vgl. [ShGa1996, S. 4]). Die Betrachtung der übergeordneten Struktur eines Systems, d. h. der Softwarearchitektur, erfordert aufgrund der Größe und Komplexität eine Erhöhung des Abstraktionsniveaus, so dass nur noch die grob-granularen Elemente einer Programmiersprache, wie z. B. Module, oder andere Strukturierungselemente, wie z. B. Komponenten, betrachtet werden. Wird die unternehmensweite Softwarearchitektur untersucht, muss das Abstraktionsniveau aufgrund der Größe und Komplexität weiter erhöht werden. Auf dieser Ebene stehen die Anwendungen, die Beziehungen zwischen den Anwendungen und die Verhaltensweisen der Anwendungen im Fokus. Neben den unterschiedlichen Elementen werden auf den Ebenen auch unterschiedliche Regeln der Kombination und Verhaltensweisen betrachtet, so dass sich auch andere Entwurfsprobleme ergeben. Aus diesem Grund ist es sinnvoll, die verschiedenen Ebenen zu unterscheiden, wodurch die Softwarearchitektur ihre Daseinsberechtigung erhält (vgl. [ShGa1996, S. 4]). Jede Ebene kann grundsätzlich unabhängig analysiert werden, aber es bestehen auch zahlreiche Abhängigkeiten zwischen den Ebenen. Die Elemente einer Ebene werden z. B. durch die Kombinationsregeln der untergeordneten Ebenen erstellt bzw. implementiert. Eine Anwendung besteht z. B. aus mehreren Modulen bzw. Komponenten, die auf Basis einer Programmiersprache implementiert werden. Bass, Clements und Kazman untersuchen die Bedeutung der Softwarearchitektur primär aus der Perspektive der praktischen Softwareentwicklung und unterscheiden drei fundamentale Gründe für die große Relevanz der Softwarearchitektur (vgl. [BaCK2003, S. 26-35]): ƒ Die Softwarearchitektur ist ein wichtiges Kommunikationsinstrument, ƒ sie spezifiziert grundlegende Entwurfsentscheidungen und ƒ sie ermöglicht ihre Übertragbarkeit sowie Wiederverwendbarkeit im Kontext von meh-

reren Anwendungen.

Bedeutung der Softwarearchitektur

23

Die Softwarearchitektur ist ein wesentliches Kommunikationsinstrument, auf dessen Basis die unterschiedlichen Interessen und Anforderungen der sog. Stakeholder12 kommuniziert, verhandelt und abgestimmt werden können. Die Stakeholder sind alle Personen und/oder Organisationen, die ein Interesse an der Erstellung bzw. am Einsatz des Systems haben (vgl. [BaCK2003, S. 6]). Die Gruppe der Stakeholder umfasst nicht nur die Kunden oder Endbenutzer eines Systems, sondern auch z. B. die Entwickler, Projektmanager oder Mitarbeiter des Vertriebs. Die Softwarearchitektur ist ein Modell, das aufgrund des höheren Abstraktionsniveaus im Fall von großen und komplexen Systemen eine Diskussion der Interessen und Anforderungen ermöglicht. Ohne dieses Modell ist es nicht möglich, umfangreiche und komplexe Systeme zu verstehen, Entwurfsentscheidungen zu treffen und diese Systeme zu bewerten (siehe Kapitel 1). Daneben ist die Softwarearchitektur von hoher Relevanz, da innerhalb des Entwurfs einer Softwarearchitektur die ersten und insbesondere grundlegenden Entwurfsentscheidungen getroffen werden (vgl. [BaCK2003, S. 29]). Die Softwarearchitektur umfasst die frühesten Entwurfsentscheidungen, die innerhalb des Softwareentwicklungsprozesses getroffen werden. Diese Entscheidungen sind am schwierigsten zu treffen und im späteren Verlauf der Entwicklung nur mit großem Aufwand zu ändern (vgl. [BaCK2003, S. 29]). Innerhalb der Softwarearchitektur werden die wesentlichen Einschränkungen bezüglich der Implementierung definiert. Diese Einschränkungen haben weitreichende Auswirkungen. Insbesondere die Qualität des gesamten Systems wird durch die Softwarearchitektur maßgeblich beeinflusst, denn die Entwurfsentscheidungen, die innerhalb der Softwarearchitektur getroffen werden, unterstützen oder behindern die Erreichung nahezu aller Qualitätsmerkmale einer nicht-trivialen Anwendung (siehe Kapitel 1). Darüber hinaus hat die Softwarearchitektur einen großen Einfluss auf das Projektmanagement innerhalb der Entwicklung eines Softwareprodukts bzw. einer Anwendung (vgl. [BaCK2003, S. 29 f.]). Sie beschreibt u. a. die grundsätzliche Struktur und Dekomposition des Systems, die üblicherweise die Grundlage für die Erstellung eines Projektstrukturplans sind. Auf der Basis dieses Plans wird die Projektorganisation, Aufwandsschätzung und Zeitplanung erstellt. Diese Abhängigkeiten veranschaulichen die große Relevanz der Softwarearchitektur für das Projektmanagement, denn wird die Softwarearchitektur im späteren Projektverlauf modifiziert, können Änderungen an der Projektorganisation, Aufwandsschätzung und/oder Zeitplanung notwendig werden. Die Abhängigkeit zwischen Softwarearchitektur und Projektmanagement hebt auch die Bedeutung der Bewertung einer Softwarearchitektur im Kontext des Softwareentwicklungsprozesses hervor (siehe Kapitel 1): Die Eignung einer Softwarearchitektur sollte durch eine entsprechende Bewertung festgestellt werden, bevor die Softwarearchitektur als Grundlage in12

Da der Begriff im Sinne von Bass, Clements und Kazman nicht adäquat übersetzt werden kann, wird im Folgenden der englische Begriff verwendet.

24

Grundlagen und Bezugsrahmen des Entwurfs von Softwarearchitekturen

nerhalb der Erstellung weiterer Projektdokumente und -ergebnisse verwendet wird. Anderenfalls werden im Fall einer Modifikation der Softwarearchitektur im fortgeschrittenen Projektverlauf u. U. umfangreiche Änderungen an den entsprechenden abhängigen Projektdokumenten und -ergebnissen notwendig, die ggf. den Erfolg eines Projektes gefährden können. Darüber hinaus ist die Softwarearchitektur auch innerhalb der Wartungs- und Pflegephase eines Softwareprodukts bzw. einer Anwendung von großer Bedeutung. Sie kann z. B. die Fehlersuche bzw. -analyse unterstützen und im Kontext von neuen bzw. geänderten Anforderungen die Grundlage für eine Analyse der zu ändernden Softwareelemente sein. Ein weiterer Grund für die große Relevanz der Softwarearchitektur ist nach Bass, Clements und Kazman die Übertragbarkeit und Wiederverwendbarkeit der Softwarearchitektur (vgl. [BaCK2003, S. 32-35]). Im Vergleich zu der Wiederverwendung auf der Ebene einer Programmiersprache ist der Nutzen der Wiederverwendung einer Softwarearchitektur wesentlich größer. So basieren z. B. Softwareproduktfamilien auf einer gemeinsamen Softwarearchitektur, die beschreibt, welche Bestandteile für alle Mitglieder einer Produktfamilie fixiert und welche variabel sind. Die einmalige Definition und mehrfache Verwendung einer Softwarearchitektur führt zu einer Reduktion der Entwicklungskosten und einer Verbesserung der Produktqualität. Auf diesen Aspekt der Produktivitätssteigerung von Designern und Entwicklern weisen auch Perry und Wolf hin (vgl. [PeWo1992]). Daneben können auf Basis der Definition einer Softwarearchitektur Systeme erstellt werden, die zu großen Teilen aus extern implementierten oder zugekauften Softwareelementen bestehen (vgl. [BaCK2003, S. 33]). Bass, Clements und Kazman erläutern, dass auf der Ebene der Softwarearchitektur der Fokus nicht auf der Implementierung, sondern auf der Zusammenstellung und Endfertigung von Softwareelementen liegt, d. h., die einzelnen Softwareelemente müssen nicht zwangsweise „an einem Ort“ implementiert werden, sondern können unabhängig voneinander implementiert und anschließend zu einem System „zusammengebaut“ werden. Die Komposition von Systemen aus unterschiedlichen Softwareelementen wird durch die Softwarearchitektur unterstützt, da neben der übergeordneten Struktur eines Systems die wesentlichen Softwareelemente identifiziert werden.

2.4

Einflussfaktoren

Im Fokus dieses Kapitels stehen die Faktoren, die die Entstehung, den Einsatz und die Weiterentwicklung einer Softwareachitektur beeinflussen. Im Kontext verschiedener Vorgehensmodelle für die Softwareentwicklung werden im Wesentlichen die Anforderungen des Systems bzw. der Anwendung als Einflussfaktoren der Softwarearchitektur betrachtet. Diese Vorgehensmodelle basieren i. d. R. auf der impliziten Annahme, dass der Entwurf eines Systems ausschließlich auf Basis der Anforderungen erfolgt (vgl. [BaCK2003, S. 3]).

Einflussfaktoren

25

Bass, Clements und Kazman weisen jedoch darauf hin, dass diese Annahme – zumindest für den Entwurf der Softwarearchitektur – nicht vollständig gilt, d. h., die Softwarearchitektur wird nicht ausschließlich von den Anforderungen beeinflusst (vgl. [BaCK2003, S. 5]). Sie ist ein Ergebnis von technischen, betriebswirtschaftlichen und sozialen Einflüssen, die auf den Entwurf einer Softwarearchitektur einwirken. Bass, Clements und Kazman differenzieren vier Kategorien von Einflussfaktoren auf Softwarearchitekturen, die in der Abbildung 2-5 dargestellt werden: die Stakeholder (Stakeholders), die entwickelnde Organisation (Developing Organization), die technische Umgebung (Technical Environment) sowie die Kenntnisse und Erfahrungen der Architekten (Architect’s Experience) (vgl. [BaCK2003, S. 6-9]).

Abbildung 2-5: Einflussfaktoren der Softwarearchitektur Quelle: in Anlehnung an [BaCK2003, S. 10]

Die Stakeholder umfassen alle Personen und/oder Organisationen, die ein Interesse an der Erstellung bzw. am Einsatz des Systems haben (vgl. [BaCK2003, S. 6]). Hierzu gehören nicht nur die Kunden oder Endbenutzer eines Softwareprodukts, sondern z. B. auch die Entwickler, Architekten, Projektmanager oder Mitarbeiter des Vertriebs (vgl. Kapitel 2.3). Die Stakeholder haben funktionale und nicht-funktionale Anforderungen (siehe Kapitel 3.2.2.2) an das System bzw. die Anwendung, die innerhalb des Entwurfs der Softwarearchitektur berücksichtigt werden müssen. Das hieraus resultierende Problem ist, dass die verschiedenen Stakeholder unterschiedliche Anforderungen haben, die sich teilweise sogar widersprechen können (vgl. [BaCK2003, S. 7]). Die Softwarearchitektur wird auch von der Organisation, die das Softwareprodukt entwickelt, beeinflusst (vgl. [BaCK2003, S. 8]). Zu diesen organisatorischen Einflussfaktoren zählen Bass, Clements und Kazman z. B. die Kenntnisse, Fähigkeiten und Verfügbarkeit der Entwickler. Weiterhin wirken die Zeitplanung und das vorhandene Budget auf den Entwurf einer Softwarearchitektur ein. Die Organisation bestimmt auch das grundsätzliche Investitionsverhalten bezüglich der Softwarearchitektur, d. h., ob eine Softwarearchitektur für genau ein System bzw. eine Anwendung entworfen oder ob die Softwarearchitektur als Grundlage für eine umfangreiche Produktfamilie verwendet wird. Die Kenntnisse und Erfahrungen der Architekten haben ebenfalls einen großen Einfluss auf den Entwurf der Softwarearchitektur (vgl. [BaCK2003, S. 8]). Die Entwurfsentscheidungen,

26

Grundlagen und Bezugsrahmen des Entwurfs von Softwarearchitekturen

die ein Architekt im Kontext des Entwurfs der Softwarearchitektur trifft, werden maßgeblich von der Ausbildung und Erfahrung des Architekten geprägt. Ein architektur-bezogener Ansatz, der dem Architekten bzw. Architekturteam nicht bekannt ist, kann innerhalb des Entwurfs auch nicht berücksichtigt werden. Wenn ein Architekt z. B. bereits gute Erfahrungen mit einem bestimmten Ansatz gemacht hat, wird er diesen Ansatz vermutlich in nachfolgenden Projekten bevorzugt einsetzen. Darüber hinaus beeinflusst der Zugang des Architekten zu Pattern-Dokumentationen (siehe Kapitel 4.2) und/oder vorhandenen Systemen dessen Entwurfsentscheidungen, da aus diesen u. U. wertvolles Entwurfswissen extrahiert werden kann. Die Entwurfsentscheidungen werden somit nicht vollständig objektiv getroffen, sondern stark durch die Person des Architekten sowie seinen Kenntnissen und Erfahrungen beeinflusst. Darüber hinaus kann die technische Umgebung auf den Entwurf und Einsatz der Softwarearchitektur einwirken (vgl. [BaCK2003, S. 9]). Die technische Umgebung umfasst nach Bass, Clements und Kazman die aktuellen Techniken, Technologien und Praktiken, die innerhalb der Softwaretechnik vorherrschend verwendet werden. Dies bedeutet aber nicht, dass zwangsweise die neuesten Techniken oder Technologien benutzt werden sollten.

Abbildung 2-6: Darstellung des Architecture Business Cycle Quelle: in Anlehnung an [BaCK2003, S. 10]

Der Entwurf der Softwarearchitektur und die Umsetzung der Architektur innerhalb eines Systems beeinflussen wiederum die technische, betriebswirtschaftliche und soziale Umgebung, so dass neue Softwarearchitekturen nicht auf Basis der gleichen Einflussfaktoren entstehen können (vgl. [BaCK2003, S. 5]). Bass, Clements und Kazman bezeichnen diesen Rückkopplungseffekt als sog. Architecture Business Cycle (ABC) (vgl. [BaCK2003, S. 5, S. 9-12], vgl. Abbildung 2-6).

Einflussfaktoren

27

Die aktuelle Umgebung wirkt auf den Entwurf einer Softwarearchitektur ein und die Existenz bzw. Umsetzung der Softwarearchitektur beeinflusst wiederum die Umgebung, in der neue Softwarearchitekturen entwickelt werden. Die Rückkopplungen können durch die Softwarearchitektur oder durch das System entstehen, das auf Basis der Softwarearchitektur implementiert wird (vgl. Abbildung 2-6). Bass, Clements und Kazman weisen explizit darauf hin, dass dieser Zyklus, der die aktuelle Umgebung, die Softwarearchitektur und das eingesetzte System umfasst, durch das Unternehmen gesteuert und kontrolliert werden kann (vgl. [BaCK2003, S. 9 f.]). Die Steuerung und Kontrolle des Architecture Business Cycle ermöglicht z. B. die gezielte Nutzung von Investitionen, die bereits in den Entwurf von Softwarearchitekturen und die entsprechenden Systeme getätigt worden sind, oder den systematischen Einsatz einer Softwarearchitektur zur Unterstützung einer bestimmten Wachstumsstrategie des Unternehmens. Entsprechend des Architecture Business Cycle beeinflusst die Softwarearchitektur z. B. die Struktur der Organisation, da sie die Grundlage für die Erstellung eines Projektstrukturplans ist (vgl. Kapitel 2.3). Auf Basis des Projektstrukturplans erfolgt der Aufbau der Projektorganisation, die Aufwandsschätzung und Zeitplanung, die wiederum entsprechende Auswirkungen auf die Struktur der Organisation haben. Die Softwarearchitektur beschreibt z. B. die Softwarelemente, die zur Realisierung eines Systems implementiert werden müssen. Die Menge der Softwareelemente bildet die Grundlage für eine Aufwandsschätzung und Zeitplanung, in der jedem Element ein geschätzter Aufwand bzw. eine entsprechende Realisierungszeit zugeordnet wird. Auf Basis des geschätzten Aufwands und der Zeitplanung lässt sich z. B. ermitteln, wie viele Mitarbeiter bzw. Entwickler in der Implementierungsphase benötigt werden, um die gesamte Menge der Softwareelemente innerhalb eines bestimmten Zeitraums zu implementieren. Daneben kann das eingesetzte System auf die Ziele der Organisation einwirken, indem z. B. ein erfolgreiches System den Ausbau der Marktpositionierung unterstützt (vgl. [BaCK2003, S. 10 f.]). Der Entwurf der Softwarearchitektur beeinflusst auch die Kenntnisse und Erfahrungen des bzw. der Architekten, da innerhalb der Entwurfsphase entsprechende neue Kenntnisse erworben und neue Erfahrungen gemacht werden, die innerhalb des Entwurfs nachfolgender Softwarearchitekturen ebenfalls berücksichtigt werden können. Eine Softwarearchitektur kann u. U. sogar die technische Umgebung, d. h. die vorherrschenden Techniken, Technologien und Praktiken der Softwaretechnik, beeinflussen. Bass, Clements und Kazman nennen in diesem Kontext u. a. das sog. World Wide Web (WWW) und die standardisierte, mehrschichtige Softwarearchitektur der Java EE-Spezifikation (vgl. [BaCK2003, S. 11 f.]).

28

Grundlagen und Bezugsrahmen des Entwurfs von Softwarearchitekturen

In der vorliegenden Arbeit werden im Kontext des Entwurfs und der Bewertung der Softwarearchitekturen primär die o. g. Anforderungen als Einflussfaktoren der Softwarearchitekturen betrachtet (siehe Kapitel 1). Diese Anforderungen repräsentieren die unterschiedlichen Interessen der verschiedenen Stakeholder und der Organisation. Daneben werden aber auch weitere Einflussfaktoren betrachtet. Insbesondere die Bedeutung der Kenntnisse und Fähigkeiten der Architekten wird im Kontext der pattern-basierten Bewertung der Softwarearchitekturen kritisch untersucht (siehe Kapitel 1 und 1).

2.5

Dokumentation von Softwarearchitekturen

Eine Softwarearchitektur beschreibt nach Bass, Clements und Kazman eine Menge von Softwareelementen mit ihren extern sichtbaren Eigenschaften und deren Beziehungen untereinander (vgl. Kapitel 2.1). Der Entwurf einer Softwarearchitektur umfasst Entscheidungen bezüglich der Softwareelemente, deren extern sichtbare Eigenschaften und der Beziehungen zwischen den Softwareelementen. Diese Entwurfsentscheidungen müssen dokumentiert werden, um die Softwarearchitektur insbesondere innerhalb der Implementierungsphase und einer Bewertung (siehe Kapitel 1) nutzen zu können. Die Nutzung einer Softwarearchitektur setzt deshalb ihre Dokumentation voraus. Aus diesem Grund werden im Folgenden die wesentlichen Aspekte der Dokumentation von Softwarearchitekturen erläutert. Clements, Bachmann, Bass et al. unterscheiden drei wesentliche Arten der Verwendung einer Softwarearchitektur-Dokumentation (vgl. [CBBG2003, S. 10-12]): ƒ Hilfsmittel zur Ausbildung: Die Verwendung der Softwarearchitektur-Dokumentation

als Hilfsmittel zur Ausbildung umfasst z. B. die Einweisung von neuen Entwicklern, externen Beratern oder neuen Architekten. ƒ Kommunikation zwischen den Stakeholdern: Die Softwarearchitektur ist ein Kommuni-

kationsinstrument, auf dessen Basis die unterschiedlichen Interessen und Anforderungen der Stakeholder kommuniziert, verhandelt und abgestimmt werden können (vgl. Kapitel 2.3). ƒ Grundlage für die Analyse bzw. Bewertung des Systems: Die Softwarearchitektur-Doku-

mentation muss alle Informationen enthalten, um im Kontext der Bewertung der Softwarearchitektur Aussagen bezüglich der Ausprägungen der Qualitätsmerkmale abzuleiten bzw. zu ermitteln (siehe Kapitel 1). Die verschiedenen Verwendungsarten führen zu unterschiedlichen Anforderungen bezüglich der Inhalte der Dokumentation einer Softwarearchitektur. Darüber hinaus haben die verschiedenen Rollen von Stakeholdern – entsprechend ihrer Aufgaben und Verantwortlichkeiten – unterschiedliche Anforderungen an die Inhalte einer derartigen Dokumentation.

Dokumentation von Softwarearchitekturen

29

Tabelle 2-1 listet beispielhaft Stakeholder mit ihren entsprechenden Kommunikationsanforderungen auf.

Stakeholder

Kommunikationsanforderung

Architekten und Personen, die die Anforderungen auf der Seite des Kunden vertreten

Verhandlung und Abwägung zwischen konkurrierenden Anforderungen

Architekt und Designer, die die einzelnen Softwareelemente entwerfen

Auflösung von Konkurrenzsituationen bezüglich des Zeit- und Verbrauchsverhaltens

Entwickler

Beschreibung der unantastbaren Einschränkungen, die durch die Softwarearchitektur beschrieben werden, und der Freiheiten, die der Entwickler innerhalb der Implementierung nutzen kann

Integrations- und Anwendungstester

Spezifikation des korrekten „Black-box“-Verhaltens der Softwareelemente

Wartungsprogrammierer

Ausgangspunkt für die Wartungsaktivitäten und Analyse der Auswirkungen einer Änderung

Designer von anderen Systemen, die mit dem zugrunde liegenden System integriert werden müssen

Definition der nach außen verfügbaren Funktionen bzw. Dienste und die Spezifikation der entsprechenden Protokolle

Manager

Grundlage für die Erstellung eines Projektstrukturplans und den weiteren abhängigen Dokumenten, wie z. B. die Projektorganisation, Aufwandsschätzung und Zeitplanung

Produktmanager

Ermittlung, ob ein potenzielles neues Mitglied der Produktfamilie im Anwendungsbereich der Softwarearchitektur liegt oder nicht

Qualitätssicherungsteam

Grundlage für die Überprüfung, ob die Implementation den Rahmen und die Richtlinien der Softwarearchitektur einhält oder nicht

Tabelle 2-1: Stakeholder und ihre Kommunikationsanforderungen Quelle: in Anlehnung an [CBBG2003, S. 10 f.]

Die Softwarearchitektur eines nicht-trivialen Systems ist inhärent komplex und umfangreich, d. h., sie umfasst zahlreiche Softwareelemente mit vielen Eigenschaften, die über vielschichtige und verflochtene Beziehungen miteinander verbunden sind. Ein derartig kompliziertes Gebilde kann i. d. R. nicht auf Basis einer eindimensionalen Struktur dargestellt werden (vgl. [CBBG2003, S. 13; BaCK2003, S. 204]). Diese Erkenntnis berücksichtigt auch die Begriffsdefinition von Bass, Clements und Kazman. Sie beschreibt, dass es sich bei einer Softwarearchitektur um eine oder mehrere Strukturen eines Systems handelt (vgl. Kapitel 2.1). Diese Strukturen charakterisieren die Softwarearchitektur des Systems aus verschiedenen Sichten, so dass eine Softwarearchitektur auf Basis von einer oder mehreren Sichten spezifiziert wird. Dieses Konzept wird auch als sog. Sichtenkonzept bezeichnet und

30

Grundlagen und Bezugsrahmen des Entwurfs von Softwarearchitekturen

ist ein fundamentales Prinzip der Softwarearchitektur-Dokumentation (vgl. [CBBG2003, S. 13]). Clements, Bachmann, Bass et al. definieren das Sichtenkonzept wie folgt: „Documenting an architecture is a matter of documenting the relevant views and then adding documentation that applies to more than one view.“ [CBBG2003, S. 13]. Dabei ist zu beachten, dass keine Sicht allein die Softwarearchitektur repräsentiert, aber alle Sichten zusammen übermitteln bzw. kommunizieren die Softwarearchitektur (vgl. [CBBG2003, S. 13; BaCK2003, S. 204]). Eine Sicht enthält z. B. eine Repräsentation, mit der die grundlegenden Softwareelemente und deren Beziehungen dargestellt werden (vgl. [CBBG2003, S. 15]). Diese Repräsentation basiert gewöhnlich auf einer grafischen Notation, wie z. B. der sog. Unified Modeling Language13 (siehe [OMG2005a; OMG2005b]), die zur Darstellung der Softwareelemente und deren Beziehungen verwendet wird. Eine Sicht kann einen Katalog der in der Sicht dargestellten Softwareelemente enthalten und innerhalb dieses Katalogs die Eigenschaften der Softwareelemente definieren. Darüber hinaus kann eine Sicht die Schnittstellen, das Verhalten und weitere Entwurfsinformationen darstellen. Die verschiedenen Sichten stellen verschiedene Qualitätsmerkmale der Softwarearchitektur (siehe Kapitel 1) in unterschiedlichem Umfang heraus (vgl. [CBBG2003, S. 14]). Jede Sicht unterstützt deshalb eine Argumentation bezüglich der Ausprägungen bestimmter Qualitätsmerkmale (vgl. [BaCK2003, S. 40 f.]). Die Sichten können auch als Ausgangspunkt für eine geplante Veränderung eines Qualitätsmerkmals verwendet werden. Dabei stellt sich die Frage, welche konkreten Sichten zur Dokumentation einer Softwarearchitektur verwendet werden sollten. Die Auswahl der Sichten hängt von den Zielen bzw. der Nutzung der Dokumentation ab, so dass keine Menge von Sichten für jeden Anwendungsfall definiert werden kann (vgl. [CBBG2003, S. 13]). Kruchten schlägt innerhalb seines sog. „4+1“-Modells vier Sichten vor, die für die Beschreibung der Softwareelemente und deren Beziehungen verwendet werden sollten (vgl. [Kruc1995]). Eine weitere fünfte Sicht verbindet die vier beschreibenden Sichten auf Basis von Szenarios. Das Modell definiert für jede Sicht die Elemente und ihre Verbindungen. Es kann auf Basis unterschiedlicher Notationen und Werkzeuge verwendet werden. Kruchten unterscheidet im Detail die folgenden Sichten (vgl. [Kruc1995]): ƒ Logische Sicht (logical view): Die logische Sicht beschreibt die Funktionen, die ein Sys-

tem seinen Endnutzern bereitstellen soll. Diese Sicht unterstützt die Definition von funktionalen Anforderungen (siehe Kapitel 3.2.2.2) an ein System. Das System wird auf Basis von objekt-orientierten Konzepten strukturiert, d. h., die wesentlichen Abstrak13

Siehe auch http://www.uml.org

Dokumentation von Softwarearchitekturen

31

tionen sind Klassen und Objekte, die Mechanismen, wie z. B. die Kapselung und Vererbung, nutzen können. ƒ Prozess-orientierte Sicht (process view): Die prozess-orientierte Sicht betrachtet die

Verteilung der Objekte bzw. Methoden auf unterschiedliche logische Prozesse, d. h., welche Prozesse die einzelnen Methoden eines Objektes ausführen. ƒ Entwicklungs-orientierte Sicht (development view): Die entwicklungs-orientierte Sicht

spezifiziert die Organisation der einzelnen Softwaremodule innerhalb der Entwicklungsumgebung. Die grundlegenden Softwareelemente dieser Sicht sind z. B. Programmbibliotheken oder Subsysteme, die von einem oder mehreren Entwicklern implementiert werden können. ƒ Physische Sicht (physical view): Die physische Sicht bildet die in den anderen Sichten

identifizierten Softwareelemente auf Rechnerknoten ab, d. h., es wird beschrieben auf welchem Rechner sich welche Prozesse, Aufgaben, Objekte usw. befinden. Hofmeister, Nord und Soni untersuchten die Softwarearchitektur-Dokumentation von großen, komplexen Systemen, um die Gemeinsamkeiten und Prinzipien zu erkennen, die zu „guten“ und „nutzbaren“ Dokumentationen für Softwarearchitekturen führen (vgl. [HoNS1995, S. 9; SoNH1995, S. 196 ff.]). Im Kontext dieser Analyse identifizierten sie vier wesentliche Sichten, die zur Dokumentation von Softwarearchitekturen verwendet werden (vgl. [HoNS1995, S. 11 f.]): ƒ Sicht des Quellcodes (code view): Die Sicht beschreibt die Organisation des Quellcodes,

des Objektcodes und der Bibliotheken innerhalb der Entwickungsumgebung. ƒ Sicht der Module (module view): Die Modulsicht stellt die Partitionierung des Systems

in Module, Komponenten und Schichten dar. Darüber hinaus werden die Schnittstellen zwischen diesen Softwareeelementen spezifiziert. Diese Sicht unterstützt die Prinzipien der Abstraktion und Kapselung, wodurch die arbeitsteilige Implementierung von umfangreichen, komplexen Systemen in großen Teams möglich wird. ƒ Sicht der Ausführung (execution view): Die Sicht charakterisiert das dynamische Ver-

halten des Systems zur Laufzeit und die Verteilung der einzelnen Softwareelemente auf die verfügbaren Hardwareelemente. Darüber hinaus werden die Kommunikation zwischen den Prozessen und Aspekte der Koordination und Synchronisation beschrieben. ƒ Konzeptuelle Sicht (conceptual view): Die konzeptuelle Sicht betrachtet das System hin-

sichtlich der wesentlichen Softwareelemente des Entwurfs und der Beziehungen zwischen diesen Elementen. Bei diesen Softwareelementen kann es sich um kommunizierende Objekte auf einem höheren Abstraktionsniveau oder aber um andere Zusammenfassungen, wie z. B. Komponenten und deren Verbindungen, handeln.

32

Grundlagen und Bezugsrahmen des Entwurfs von Softwarearchitekturen

Hofmeister, Nord und Soni definieren im Vergleich zum „4+1“-Modell von Kruchten keine explizite fünfte Sicht zur Verbindung der vier beschreibenden Sichten, jedoch diskutieren sie die Beziehungen und Abhängigkeiten, die zwischen den einzelnen Sichten existieren und berücksichtigt werden müssen (vgl. [HoNS1995, S. 12 ff.]). Zur grafischen Darstellung der einzelnen Sichten verwenden Hofmeister, Nord und Soni die UML, wobei sie allerdings den Standard zur Dokumentation von Softwarearchitekturen erweitern bzw. anpassen mussten (vgl. [HoNS1995, S. 16]). Die UML hat sich als de-facto-Standard innerhalb der grafischen Modellierungssprachen bzw. Notationen etabliert (vgl. [BaCK2003, S. 218; LaCh2006]). Obwohl die UML nicht für die Modellierung von Softwarearchitekturen entwickelt worden ist, können die Elemente der Sprache zur Softwarearchitektur-Dokumentation verwendet bzw. erweitert werden (vgl. [CBBG2003, S. 349]). Die UML unterstützt das Sichtenkonzept, indem für unterschiedliche Sichten verschiedene Diagrammtypen mit entsprechenden Modellelementen definiert werden. Sie ermöglicht auch die Modellierung auf unterschiedlichen Abstraktionsebenen. Die UML unterstützt aber nicht direkt die Abbildung von architektur-bezogenen Aspekten, wie z. B. Schichten, Subsysteme, Architektur-Stile oder Architektur-Pattern (vgl. [BaCK2003, S. 218]). Diese Aspekte können auf Basis von Erweiterungsmechanismen, wie z. B. Stereotypen (stereotypes), teilweise abgebildet werden (vgl. [OMG2005a, S. 649]). Hieraus ergibt sich die Problematik, dass die auf Basis der Erweiterungsmechanismen erstellten Modelle nicht mehr konform zum UML-Standard sind. Die Erweiterungen der UML können zwar in einem sog. UML Profil (UML profile) spezifiziert werden (vgl. [OMG2005a, S. 624]), jedoch existiert z. Z. kein vollständiges und standardisiertes Profil für die Modellierung von Softwarearchitekturen14. Die Dokumentation einer Softwarearchitektur umfasst darüber hinaus weitere Informationen, die sich auf mehrere Sichten oder die gesamte Dokumentation beziehen (vgl. [CBBG2003, S. 15, 323]). Diese sichten-übergreifende Dokumentation charakterisiert nach Clements, Bachmann, Bass et al. im Wesentlichen die folgenden Aspekte (vgl. [CBBG2003, S. 323]): ƒ Beschreibung der Organisation der Dokumentation: Die sichten-übergreifende Doku-

mentation spezifiziert den Inhalt und Umfang der Softwarearchitektur-Dokumentation, damit die Stakeholder effizient innerhalb der Dokumentation navigieren und suchen können. Es werden für jede Sicht entsprechende Vorlagen definiert, um eine einheitliche Verwendung der verschiedenen Sichten zu gewährleisten. ƒ Beschreibung der Softwarearchitektur: Die Beschreibung der Softwarearchitektur um-

fasst einen groben Überblick des zugrunde liegenden Systems, damit der Nutzer der Dokumentation bzw. der Stakeholder die Positionierung und den Zweck des Systems nachvollziehen kann. Die Beschreibung innerhalb der übergreifenden Dokumentation

14

Siehe z. B. http://www.uml.org/#UMLProfiles

Verwandte Arbeiten

33

enthält eine Spezifikation der Beziehungen zwischen den unterschiedlichen Sichten, eine Liste aller Softwareelemente und eine Aufstellung in welchen Sichten diese Elemente verwendet werden, sowie ein Glossar und ein Abkürzungsverzeichnis für die gesamte Softwarearchitektur. ƒ Begründung und Zielsetzung der Softwarearchitektur: Die sichten-übergreifende Doku-

mentation beschreibt auch die Beschränkungen und Hintergrundinformationen, die innerhalb des Entwurfs berücksichtigt wurden und die Softwarearchitektur beeinflusst haben. Darüber hinaus stellt sie die Gründe für die grundlegenden Entwurfsentscheidungen dar. Clements, Bachmann, Bass et al. erläutern in diesem Zusammenhang weitere detaillierte Fragestellungen der Dokumentation von Softwarearchitekturen, die im Kontext der vorliegenden Arbeit nicht relevant sind und daher nicht diskutiert werden (vgl. [CBBG2003, S. 315 ff.]).

2.6

Verwandte Arbeiten

In diesem Kapitel werden verwandte Arbeiten vorgestellt, d. h. Forschungsarbeiten, deren Zielsetzungen mit den Forschungsfragen der vorliegenden Arbeit eine sehr hohe Ähnlichkeit aufweisen und deren Ergebnisse einen Beitrag zur Beantwortung der Forschungsfragen, die in dieser Arbeit untersucht werden (vgl. Kapitel 1.2), leisten können. Die verwandten Arbeiten umfassen die sog. attribut-basierten Architektur-Stile (AttributeBased Architectural Styles, ABAS), die auf Basis des Konzepts der Architektur-Stile und analytischen Modellen die Analyse der Auswirkungen von Entwurfsentscheidungen auf die Qualitätsmerkmale eines Systems unterstützen sollen (siehe Kapitel 2.6.1) Ein Ansatz von Zhu, Ali Babar und Jeffery soll es ermöglichen, architektur-relevante Informationen aus Pattern-Dokumentationen zu extrahieren, um die Bewertung einer Softwarearchitektur zu unterstützen (siehe Kapitel 2.6.2). Die Dokumentation der extrahierten architektur-relevanten Informationen soll auf Basis einer einheitlichen Vorlage erfolgen, die innerhalb eines Beitrags von Ali Babar spezifiziert wird (siehe Kapitel 2.6.3) Die im Folgenden verwendeten Begriffe und Konzepte, die noch nicht eingeführt oder vorgestellt wurden, werden mit Verweisen auf die entsprechenden folgenden Kapitel versehen.

2.6.1 Attribut-basierte Architektur-Stile Das Konzept der attribut-basierten Architektur-Stile wurde von Klein, Kazman, Bass et al. erstmalig als Konferenzbeitrag veröffentlicht (siehe [KKBC1999]) und anschließend innerhalb eines Forschungsberichts des Software Engineering-Instituts erweitert bzw. verfeinert

34

Grundlagen und Bezugsrahmen des Entwurfs von Softwarearchitekturen

(siehe [KlKa1999]). Es ist eine Erweiterung des Konzepts der Architektur-Stile von Shawn und Garlan (vgl. Kapitel 2.1) und ergänzt dieses um einen Rahmen zur Analyse der Auswirkungen der Entwurfsentscheidungen innerhalb eines Architektur-Stils auf die Qualitätsmerkmale eines Systems.

2.6.1.1 Darstellung des Ansatzes Ein Architektur-Stil spezifiziert eine bestimmte Anordnung und die Interaktionen einer Menge von Softwareelementen (vgl. Kapitel 2.1). Da ein Architektur-Stil analog zu einem Architektur-Pattern (siehe Kapitel 1) in der Praxis wiederholt umgesetzt und erprobt wurde, ist es möglich, den Architektur-Stil um eine Beschreibung seiner Auswirkungen auf die Qualitätsmerkmale eines Systems zu erweitern. Die Auswirkungen können aufgrund des mehrfachen Einsatzes des Architektur-Stils ermittelt werden. Die Architektur-Stile dokumentieren somit Entwurfswissen, das im Kontext des Entwurfs und der Bewertung wiederverwendet werden kann. Die Auswirkungen auf die Qualitätsmerkmale werden durch einen Architektur-Stil bzw. ein Architektur-Pattern informell beschrieben, d. h., es erfolgt eine qualitative Beschreibung der Vor- und Nachteile (siehe Kapitel 4.1). Das Konzept der attribut-basierten Architektur-Stile ergänzt einen Architektur-Stil um ein geeignetes Modell, das eine genauere Begründung und Vorhersage der Auswirkungen bezüglich eines Qualitätsmerkmals ermöglichen soll (vgl. [KKBC1999, S. 2; KlKa1999, S. 1]). Die Modelle werden nicht neu entwickelt, sondern es wird auf existierende analytische Modelle zur Analyse eines Qualitätsmerkmals zurückgegriffen. Da die Modelle jeweils nur ein Qualitätsmerkmal berücksichtigen, betrachtet ein ABAS auch jeweils nur ein Qualitätsmerkmal (vgl. [KlKa1999, S. 1]). Da verschiedene Qualitätsmerkmale existieren (siehe Kapitel 3.2), können für einen Architektur-Stil mehrere ABAS dokumentiert werden. Die Modelle müssen nicht zwangsweise eine quantitative Begründung und Vorhersage der Auswirkungen unterstützen, sondern können auch einen qualitativen Rahmen zur Analyse der Auswirkungen spezifizieren. Klein und Kazman haben auf der Basis des Konzepts sieben ABAS in einem Forschungbericht dokumentiert (siehe [KlKa1999, S. 7 ff., 31 ff.]). Ein ABAS wird in textueller Form beschrieben, wobei Klein und Kazman zur einheitlichen Strukturierung der Dokumentation vier Kapitelüberschriften auf der ersten Ebene und drei auf der zweiten Ebene vorschlagen. Eine weiterführende Beschreibung der Struktur und des Aufbaus erfolgt nicht. Die Dokumentation eines ABAS besteht aus den folgenden vier Bestandteilen, die sich in den Kapiteln auf der ersten Ebene der Dokumentation eines ABAS widerspiegeln (vgl. [KlKa1999, S. 7]): ƒ Problembeschreibung: Eine informelle Beschreibung des zugrunde liegenden Entwurfs-

und Analyseproblems, das durch den ABAS gelöst werden soll. Die Beschreibung um-

Verwandte Arbeiten

35

fasst auch das betrachtete Qualitätsmerkmal, den Einsatzbereich des Architektur-Stils und allgemeine Anforderungen, die sich auf das betrachtete Qualitätsmerkmal beziehen. ƒ Maße des Stimulus und der Reaktion: Eine Spezifikation des Stimulus auf das der

ABAS reagiert und eine Erläuterung der Reaktion, die durch den ABAS beeinflusst wird. Der Stimulus und die Reaktion sind konzeptuell an das Modell der Qualitätsmerkmal-Szenarios angelehnt (siehe Kapitel 3.2.4.3). ƒ Beschreibung des Architektur-Stils: Eine Charakterisierung des Architektur-Stils, d. h.,

der Softwareelemente und Beziehungen des Stils sowie deren Eigenschaften und Einschränkungen (vgl. Kapitel 2.1). Da ein Architektur-Stil analog zu einem ArchitekturPattern eine abstrakte Lösung darstellt, enthält die Lösung auch Teile, die in konkreten Anwendungsfällen variieren können. Diese sog. Parameter werden auch in diesem Abschnitt dokumentiert. ƒ Analyse: Eine Erläuterung, wie das entsprechende analytische Modell im Zusammen-

hang mit dem ABAS verwendet werden kann, und die Schlussfolgerungen, die sich aus der Verwendung des Modells in Bezug auf den Einsatz des Architektur-Stils ergeben. Das Ziel des analytischen Modells ist die Erläuterung des Zusammenhangs zwischen dem Architektur-Stil und seinen variablen Parametern und den Auswirkungen des ArchitekturStils, die sich durch die Reaktionen des ABAS ergeben (vgl. [KlKa1999, S. 1]). Wenn ein geeignetes quantitatives Modell vorhanden ist, wird auf dieses zurückgegriffen. Anderenfalls erfolgt die Analyse auf Basis eines qualitativen Modells. Das analytische Modell und die in Bezug auf den ABAS abgeleiteten Schlussfolgerungen sollen nach Klein, Kazman, Bass et al. die Vorhersage der Auswirkungen auf die Qualitätsmerkmale unterstützen (vgl. [KKBC1999, S. 2]). Die Identifikation der variablen Parameter eines Architektur-Stils und die Erläuterungen der entsprechenden Auswirkungen auf ein spezifisches Qualitätsmerkmal sollen ein vertieftes Verständnis für einen Architektur-Stil ermöglichen.

2.6.1.2 Bewertung des Ansatzes im vorliegenden Kontext Das Ziel des ABAS-Konzepts ist die genauere Begründung und Vorhersage der Auswirkungen eines Architektur-Stils in Bezug auf ein Qualitätsmerkmal eines Systems. Die Basis für diese Analyse bildet ein analytisches Modell, das die Beziehungen zwischen den variablen Parametern eines Architektur-Stils und den Auswirkungen auf die Qualitätsmerkmale abbildet. Da explizit zwischen einem quantitativen und qualitativen Modell differenziert wird, wird innerhalb des Konzepts implizit davon ausgegangen, dass nicht für jeden ABAS ein geeignetes quantitatives Modell verfügbar ist. Wenn in diesem Fall auf ein qualitatives Modell zurückgegriffen wird, stellt sich die Frage nach dem Mehrwert eines ABAS, denn eine infor-

36

Grundlagen und Bezugsrahmen des Entwurfs von Softwarearchitekturen

melle Erläuterung der Auswirkungen auf die Qualitätsmerkmale ist bereits Bestandteil eines Architektur-Stils bzw. -Pattern (siehe Kapitel 1). Die Menge der spezifizierten ABAS ist im Gegensatz zu der Anzahl der existierenden Pattern sehr klein, so dass deren Bedeutung im Kontext der vorliegenden Arbeit eher gering ist. Das Konzept leistet dennoch einen Beitrag für die Beantwortung der in der vorliegenden Arbeit zu untersuchenden Forschungsfrage, wie im Rahmen des Konzepts der Architektur-Stile bzw. -Pattern die Entwurfsentscheidungen und deren Auswirkungen auf die Qualität des Gesamtsystems dokumentiert werden können: Es werden die variablen Parameter eines ArchitekturStils identifiziert und deren Auswirkungen auf ein spezifisches Qualitätsmerkmal auf Basis eines Modells analysiert. Die Ergebnisse des Konzepts sind in Bezug auf die im ersten Kapitel erläuterten Forschungsfragen (vgl. Kapitel 1.2) wie folgt einzuordnen: ƒ Einsatz der Konzepte und Modelle der Qualität: Das ABAS-Konzept basiert auf dem

Modell der Qualitätsmerkmal-Szenarios (siehe Kapitel 3.2.4.3). Es werden aber kein homogenes Qualitätsmodell und lediglich einzelne Qualitätsmerkmale betrachtet (siehe Kapitel 3.2.2). ƒ Verwendung der Beziehungen zwischen den Entwurfsentscheidungen innerhalb der

Softwarearchitektur und deren Auswirkungen auf die Qualität des Systems im Kontext der Bewertungsmethoden: Das analytische Modell kann im Kontext einer Bewertungsmethode, wie z. B. der Architecture Tradeoff Analysis-Methode, die Analyse der Beziehungen unterstützen. Klein und Kazman weisen aber darauf hin, dass in diesem Zusammenhang eine quantitative Analyse nicht effizient ist, da derartige Untersuchungen im zeitlichen Rahmen einer Bewertung nicht möglich sind (vgl. [KlKa1999, S. 25]). ƒ Verwendung des Konzepts der Pattern: Obwohl die Architektur-Stile und -Pattern auf

dem gleichen Kerngedanken basieren, fokussiert sich das ABAS-Konzept stärker auf die Architektur-Stile, die von Shaw und Garlan dokumentiert wurden (vgl. [ShGa1996, S. 19 ff.]). Die Dokumentation von (Architektur)-Pattern erfolgt aber strukturierter als die Architektur-Stile, d. h., eine Pattern-Dokumentation basiert i. d. R. auf einer sog. Pattern-Schablone (siehe Kapitel 4.2.1). Sie kann eine Pattern-Klassifikation und -Sprache umfassen (siehe Kapitel 4.2.2 und 4.2.3). Diese strukturellen Aspekte der Dokumentation werden im Kontext des ABAS-Konzepts nicht weiter betrachtet. ƒ Ermittlung und Dokumentation der Beziehungen: Die Analyse der Beziehungen zwi-

schen den Entwurfsentscheidungen innerhalb der Softwarearchitektur und deren Auswirkungen auf die Qualität des Systems erfolgt im Kontext des ABAS-Konzepts auf Basis eines analytischen Modells, wobei explizit zwischen einem quantitativen und qualitativen Modell differenziert wird. Ein Modell betrachtet zu einem Zeitpunkt nur ein Qualitätsmerkmal, so dass zu einem Architektur-Stil mehrere ABAS dokumentiert

Verwandte Arbeiten

37

werden müssen. Die Wechselwirkungen mit anderen Qualitätsmerkmalen werden nicht berücksichtigt. Die Auswahl bzw. Verfügbarkeit eines geeigneten Modells wird innerhalb des Ansatzes nicht betrachtet. In dem Fall eines qualitativen Modells entsteht der Mehrwert des Konzepts im Wesentlichen durch die explizite Dokumentation der variablen Parameter eines Ansatzes, da die Auswirkungen auf die Qualitätsmerkmale bereits in der Dokumentation eines Architektur-Stils bzw. -Pattern erläutert werden. Die Struktur und der Aufbau der Dokumentation der Beziehungen werden nicht explizit betrachtet, d. h., die effiziente und effektive Wiederverwendung des Entwurfswissens besitzt in dem ABAS-Konzept nur einen untergeordneten Stellenwert.

2.6.2 Extraktion von architektur-relevanten Informationen nach Zhu, Ali Babar und Jeffery Der Ansatz von Zhu, Ali Babar und Jeffery wurde als Beitrag zu einer Konferenz veröffentlicht (siehe [ZhAJ2004]) und fokussiert die Extraktion von allgemeinen Szenarios (siehe Kapitel 3.2.4.3) und architektur-bezogenen Taktiken (siehe Kapitel 4.1.3) aus der Dokumentation von Pattern (siehe Kapitel 4.2).

2.6.2.1 Darstellung des Ansatzes Die allgemeinen Szenarios werden auf Basis eines Prozesses, der innerhalb des Beitrags nicht weiter beschrieben wird, aus der Pattern-Dokumentation extrahiert und in einer Struktur abgelegt, die dem Modell der Qualitätsmerkmal-Szenarios (siehe Kapitel 3.2.4.3) entspricht (vgl. [ZhAJ2004, S. 27, S. 29]). Nach Zhu, Ali Babar und Jeffery unterstützen die extrahierten allgemeinen Szenarios im Kontext einer szenario-basierten Bewertung (siehe Kapitel 3.3) die Erstellung von konkreten Szenarios, die auf Basis der allgemeinen Szenarios abgeleitet werden können (siehe Kapitel 3.2.4.3). Die allgemeinen Szenarios unterstützen daneben die Auswahl eines Rahmens zur Analyse der Auswirkungen der Entwurfsentscheidungen auf die Qualitätsmerkmale, der mit „quality attribute reasoning framework“ bezeichnet wird (siehe Abbildung 2-7). Der Rahmen entspricht im Wesentlichen einem detaillierten mathematischen Modell mit einer Menge von unabhängigen und abhängigen Parametern, sowie deren Beziehungen untereinander (vgl. [ZhAJ2004, S. 27]). Der Stimulus eines Szenarios entspricht nach Zhu, Ali Babar und Jeffery einem unabhängigen und das Ausmaß der Reaktion einem abhängigen Parameter des Modells (siehe Abbildung 2-7). Die Auswahl eines derartigen Modells wird weiterhin durch die extrahierten architektur-bezogenen Taktiken unterstützt, wobei bis auf den Hinweis auf die entsprechenden Abschnitte der Pattern-Dokumentation, der Prozess der Identifikation und Extraktion einer architekturbezogenen Taktik – analog zu den allgemeinen Szenarios – nicht weiter beschrieben wird (vgl. [ZhAJ2004, S. 30]). Die architektur-bezogenen Taktiken definieren grundlegende Ent-

38

Grundlagen und Bezugsrahmen des Entwurfs von Softwarearchitekturen

wurfsentscheidungen mit den entsprechenden Auswirkungen auf die Qualitätsmerkmale eines Systems (siehe Kapitel 4.1.3). Sie können daher nach Zhu, Ali Babar und Jeffery Hinweise auf einen geeigneten Rahmen zur Analyse der Entwurfsentscheidungen geben (siehe Abbildung 2-7), da sie im Detail beschreiben, welche und wie die Aspekte eines unabhängigen Parameters beeinflusst werden müssen, damit die Qualitätsmerkmale die gewünschen Ausprägungen annehmen (vgl. [ZhAJ2004, S. 30]). Die Identifikation und Auswahl eines geeigneten Modells wird allerdings bis auf diese Erläuterungen von Zhu, Ali Babar und Jeffery nicht weiter ausgeführt.

Abbildung 2-7: Ansatz nach Zhu, Ali Babar und Jeffery Quelle: in Anlehnung an [ZhAJ2004, S. 28]

Die extrahierten allgemeinen Szenarios und architektur-bezogenden Taktiken können nach Zhu, Ali Babar und Jeffery auch verwendet werden, um die Eignung eines Pattern im jeweiligen Anwendungsfall zu überprüfen (vgl. [ZhAJ2004, S. 31]). Wenn die konkreten Szenarios nicht auf Basis der allgemeinen Szenarios, die aus der Pattern-Dokumentation extrahiert wurden, abgeleitet werden können, kann das Pattern u. U. nicht zur Lösung des Problems geeignet sein (vgl. Abbildung 2-7). Die unabhängigen Parameter, die durch eine architektur-bezogene Taktik beeinflusst werden können, müssen Bestandteil des Modells zur Analyse der Auswirkungen der Entwurfsent-

Verwandte Arbeiten

39

scheidungen auf die Qualitätsmerkmale sein, um sicherzustellen, dass die Taktik und nicht ein anderer Faktor die gewünschten Auswirkungen erzielt (vgl. [ZhAJ2004, S. 31]).

2.6.2.2 Bewertung des Ansatzes im vorliegenden Kontext Das Ziel des Beitrags von Zhu, Ali Babar und Jeffery ist die Unterstützung bei der Erstellung konkreter Szenarios und der Auswahl eines Modells, das die Grundlage für eine detaillierte quantitative Analyse der Auswirkungen von Entwurfsentscheidungen auf die Qualitätsmerkmale bildet. Die Beziehungen zwischen den Entwurfsentscheidungen innerhalb der Softwarearchitektur und deren Auswirkungen auf die Qualität des Systems werden innerhalb dieses Ansatzes nicht extrahiert und dokumentiert. Obwohl der Beitrag Hinweise auf die Positionierung der architektur-relevanten Informationen innerhalb der Pattern-Dokumentation gibt, sind diese Angaben – analog zu den Extraktionsprozessen – oberflächlich beschrieben. Die Validierung des Ansatzes erfolgt lediglich auf Basis einzelner Beispiele, die zur Verdeutlichung des Konzeptes erläutert werden. Eine Wissensbasis ist nicht Bestandteil der Arbeit. Der Ansatz leistet dennoch einen Beitrag für die Beantwortung der in der vorliegenden Arbeit zu untersuchenden Forschungsfrage, wie sich das Konzept der Pattern zur Unterstützung des Entwurfs und der Bewertung von Softwarearchitekturen einsetzen lässt. Die Ergebnisse des Beitrags sind in Bezug auf die im ersten Kapitel erläuterten Forschungsfragen (vgl. Kapitel 1.2) wie folgt einzuordnen: ƒ Einsatz der Konzepte und Modelle der Qualität: Das Konzept und die unterschiedlichen

Modelle der Qualität werden in dem Beitrag nur am Rande erwähnt und innerhalb des Ansatzes nicht berücksichtigt. ƒ Verwendung der Beziehungen zwischen den Entwurfsentscheidungen innerhalb der

Softwarearchitektur und deren Auswirkungen auf die Qualität des Systems im Kontext der Bewertungsmethoden: Der Ansatz fokussiert die Auswahl eines Modells, das im Kontext der Bewertung einer Softwarearchitektur die Grundlage für eine Analyse der Auswirkungen von Entwurfsentscheidungen auf die Qualitätsmerkmale bildet. Die Modelle ermöglichen eine detaillierte und quantitative Analyse der Entwurfsentscheidungen auf Basis eines mathematischen Verfahrens. Zhu, Ali Babar und Jeffery gehen innerhalb ihres Ansatzes davon aus, dass eine qualitative Analyse und Bewertung der Entwurfsentscheidungen nicht ausreichend ist (vgl. [ZhAJ2004, S. 27]). Clements, Kazman und Klein weisen im Zusammenhang mit der Architecture Tradeoff AnalysisMethode jedoch explizit darauf hin, dass eine umfassende und quantitative Analyse

40

Grundlagen und Bezugsrahmen des Entwurfs von Softwarearchitekturen

nicht zwangsläufig notwendig und im Kontext der gesamten Bewertung einer Softwarearchitektur nicht besonders effizient und effektiv ist (vgl. [ClKK2002, S. 56 f.]). ƒ Verwendung des Konzepts der Pattern: Der Ansatz basiert auf der gleichen Annahme,

wie die vorliegende Arbeit, d. h., die Pattern-Dokumentationen enthalten wertvolle Informationen, die innerhalb der Bewertung einer Softwarearchitektur wiederverwendet werden können. Der Beitrag gibt erste Hinweise, aus welchen Abschnitten der PatternDokumentation welche architektur-bezogenen Informationen extrahiert werden können. Die unterschiedlichen Pattern-Schablonen und Abschnitte der Dokumentation werden allerdings nicht im Detail betrachtet und die Extraktionsprozesse werden nicht beschrieben. Die Struktur, die zur Erfassung der extrahierten Informationen verwendet wird, ermöglicht nur die Dokumentation von allgemeinen Szenarios. ƒ Ermittlung und Dokumentation der Beziehungen: Im Vordergrund des Ansatzes stehen

nicht die Beziehungen zwischen den Entwurfsentscheidungen innerhalb der Softwarearchitektur und deren Auswirkungen auf die Qualität des Systems, sondern die Auswahl eines Modells mit dem die Auswirkungen von Entwurfsentscheidungen quantitativ analysiert werden können.

2.6.3 Dokumentation von architektur-relevanten Informationen nach Ali Babar Der Ansatz von Ali Babar wurde als Positionspapier innerhalb eines Konferenz-Workshops veröffentlicht (siehe [AliB2004]). Er beinhaltet im Kern einen Vorschlag, der die Definition von zwei Vorlagen zur Erfassung von architektur-relevanten Informationen umfasst. Die Effektivität der beiden Vorlagen wurde von Ali Babar, Kitchenham und Mehashwari auf Basis einer Beobachtungsstudie und zwei Experimenten überprüft (siehe [AKMJ2005; AlKM2006a; AlKM2006b]). Diese Arbeiten werden allerdings im Folgenden nicht näher betrachtet, da der Ansatz im Kontext der vorliegenden Arbeit nur eine untergeordnete Bedeutung hat (siehe Kapitel 2.6.3.2).

2.6.3.1 Darstellung des Ansatzes Die erste Vorlage soll zur Dokumentation der architektur-relevanten Informationen, die aus der Dokumentation eines Pattern extrahiert wurden, verwendet werden (vgl. [AliB2004, S. 576]). Sie soll innerhalb des Entwurfs einer Softwarearchitektur die Auswahl eines geeigneten Pattern unterstützen, da sie u. a. eine Menge von allgemeinen Szenarios, die durch das Pattern unterstützt werden, und die Qualitätsmerkmale, die durch das Pattern beeinflusst werden, enthält.

Verwandte Arbeiten

41

Die Vorlage enthält mehrere Felder in denen die extrahierten architektur-relevanten Informationen erfasst werden (siehe Abbildung 2-8).

Pattern Name: Name of the software pattern

Pattern Type: Architecture, design, or style

Brief description

A brief description of the pattern.

Context

The situation for which the pattern is recommended.

Problem description

What types of problem the pattern is supposed to address?

Suggested solution

What is the solution suggested by the pattern to address the problem?

Forces

Factors affecting the problem & solution. Justification for using pattern.

Available tactics

What tactics are used by the pattern to implement the solution?

Affected Attributes

Positively Attributes supported

Supported general scenarios

Negatively Attributes hindered

S1 S2 S...n

Usage examples

Some known examples of the usage of the pattern to solve the problems.

Abbildung 2-8: Vorlage zur Dokumentation der architektur-relevanten Informationen eines Pattern Quelle: in Anlehnung an [AliB2004, S. 575]

Die Identifikation und Extraktion der Informationen auf Basis der Pattern-Dokumentation sowie die Erfassung und Aufbereitung der einzelnen Felder werden in dem Positionspapier nicht weiter erläutert. Ali Babar verweist zwar bezüglich der Identifikation und Extraktion der Informationen auf den in der vorliegenden Arbeit zuvor vorgestellten Ansatz, jedoch fokussiert sich dieser Beitrag lediglich auf die Extraktion von allgemeinen Szenarios und architektur-bezogenen Taktiken (vgl. Kapitel 2.6.2). Die übrigen Felder der Vorlage sowie der Prozess zur Identifikation und Extraktion der Informationen werden auch in diesem Beitrag nicht erläutert. Die zweite Vorlage soll die architektur-bezogenen Informationen, die aus einer Pattern-Dokumentation extrahiert wurden, für die Bewertung einer Softwarearchitektur aufbereiten (vgl. [AliB2004, S. 576]). Sie enthält mehrere Felder in denen im Wesentlichen die Bestandteile eines konkreten Szenarios mit weiteren klassifizierenden Merkmalen erfasst werden (siehe Abbildung 2-9). Jedem Szenario wird weiterhin ein Architektur-Pattern bzw. ein ArchitekturStil zugeordnet, um abzubilden, dass das konkrete Szenario durch das Architektur-Pattern bzw. den Architektur-Stil unterstützt wird. Die zweite Vorlage soll die Bewertung einer Softwarearchitektur unterstützen, da der Architekt nach Auffassung von Ali Babar auf Basis der Dokumentation des Szenarios zuverlässig behaupten kann, dass das konkrete Szenario unterstützt wird, wenn das zugehörige Pattern innerhalb der Softwarearchitektur verwendet wird (vgl. [AliB2004, S. 576]).

42

Grundlagen und Bezugsrahmen des Entwurfs von Softwarearchitekturen

Daneben wird zu jedem Szenario eine Menge von architektur-bezogenen Taktiken erfasst, die durch das Architektur-Pattern bzw. den Architektur-Stil umgesetzt werden und daher ebenfalls das konkrete Szenario unterstützen (siehe Abbildung 2-9).

Project Name: Which project needs this scenario? Project domain: Domain of the project

Date: When was proposed? Scenarios No: Serial number assigned to the scenario

Business goals

Which business goals does this scenario achieve?

Stakeholders

Which class of the stakeholders did suggest this scenario?

Attributes

Which quality attributes are required by this scenario?

Description

A brief description of the scenario.

Concrete scenario

Stimulus

A condition that needs to be considered when it arrives at a system.

Context

A system’s condition when a stimulus occurs, e.g. overloaded, running etc.

Response

A measurable action that needs to be undertaken after the arrival of the stimulus.

Complexity

How complex is this scenario to realize? (affect on macro or micro architecture)

Priority

How much important is this scenario?

Pattern/Style

Name of the architectural pattern or style that can support this scenario.

Design tactics

What are the design tactics used by the pattern/style to support the scenarios?

Design rational

What are reasons to use the pattern/tactics? How does the pattern provide the desired quality attributes?

Abbildung 2-9: Vorlage zur Dokumentation von konkreten Szenarios Quelle: in Anlehnung an [AliB2004, S. 576]

Analog zur ersten Vorlage wird die Identifikation und Extraktion der Informationen innerhalb der Pattern-Dokumentation sowie die Erfassung und Aufbereitung der einzelnen Felder in dem Positionspapier nicht weiter erläutert.

Abbildung 2-10: Positionierung von architektur-relevanten Informationen in der Pattern-Dokumentation Quelle: in Anlehnung an [AliB2004, S. 576]

Ali Babar erläutert die Verwendung der ersten Vorlage anhand eines Beispiels und beschreibt auf Basis einer Abbildung in welchen Abschnitten der Pattern-Dokumentation welche Informationen gefunden wurden (vgl. Abbildung 2-10).

Verwandte Arbeiten

43

In dem Positionspapier ist nicht dokumentiert, wie die Ergebnisse der Abbildung 2-10 entstanden sind, d. h., welche und wieviele Pattern-Dokumentationen untersucht worden sind.

2.6.3.2 Bewertung des Ansatzes im vorliegenden Kontext Das Ziel des Beitrags von Ali Babar ist die Unterstützung des Entwurfs und der Bewertung von Softwarearchitekturen durch die Definition von zwei Vorlagen. Die erste Vorlage soll zur Dokumentation der extrahierten Informationen eines Pattern und die zweite Vorlage zur Dokumentation eines konkreten Szenarios innerhalb des Bewertungsprozesses verwendet werden. Die Beziehungen zwischen den Entwurfsentscheidungen innerhalb der Softwarearchitektur und deren Auswirkungen auf die Qualität des Systems werden innerhalb dieses Ansatzes nur am Rande betrachtet. Die erste Vorlage soll der Auswahl eines geeigneten Pattern auf Basis einer Menge von allgemeinen Szenarios, die durch das Pattern unterstützt werden, und den Qualitätsmerkmalen, die durch das Pattern beeinflusst werden, dienen. Die beinflussten Qualitätsmerkmale werden gleichrangig mit den anderen extrahierten Informationen betrachtet und die Auswirkungen werden lediglich in zwei Kategorien (positiv und negativ) klassifiziert. Die Vorlage ermöglicht die Erfassung von nur einem Pattern, so dass bei der Erfassung von mehreren Pattern eine Menge von Dokumenten entsteht, die nur durch eine einheitliche Vorlage miteinander verbunden sind. Die Auswahl und der Vergleich von Pattern werden auf Basis dieser Menge von Dokumenten nur eingeschränkt unterstützt. Darüber hinaus ermöglicht die gleichrangige Betrachtung der beeinflussten Qualitätsmerkmale und die einfache Klassifikation der Auswirkungen keine direkte Auswahl eines Pattern auf Basis eines Qualitätsmerkmals. Die zweite Vorlage fokussiert die Dokumentation von konkreten Szenarios im Kontext einer spezifischen Bewertung einer Softwarearchitektur. Sie kann nicht dazu verwendet werden, Entwurfswissen zu dokumentieren, das unabhängig von einem bestimmten Bewertungsprozess ist. Für beide Vorlagen werden die Identifikation und Extraktion der Informationen auf Basis der Pattern-Dokumentation nicht weiter beschrieben. Die Erfassung und Aufbereitung der einzelnen Felder werden in dem Positionspapier ebenfalls nicht weiter erläutert, d. h., es ist nicht nachvollziehbar, an welchen Stellen der Pattern-Dokumentation die Informationen entnommen wurden. Die Ergebnisse des Beitrags sind in Bezug auf die im ersten Kapitel erläuterten Forschungsfragen (vgl. Kapitel 1.2) wie folgt einzuordnen: ƒ Einsatz der Konzepte und Modelle der Qualität: Das Konzept und die unterschiedlichen

Modelle der Qualität werden in dem Beitrag nicht erwähnt und innerhalb des Ansatzes

44

Grundlagen und Bezugsrahmen des Entwurfs von Softwarearchitekturen

nicht berücksichtigt. Es ist z. B. nicht erkennbar, welche Qualitätsmerkmale in der ersten Vorlage erfasst werden dürfen (Zeile „Affected Attributes“) und welche Semantik die Qualitätsmerkmale haben (vgl. Abbildung 2-8). ƒ Verwendung der Beziehungen zwischen den Entwurfsentscheidungen innerhalb der

Softwarearchitektur und deren Auswirkungen auf die Qualität des Systems im Kontext der Bewertungsmethoden: Die Analyse der Beziehungen zwischen den Entwurfsentscheidungen und deren Auswirkungen auf die Qualitätsmerkmale soll durch die zweite Vorlage unterstützt werden, indem einem konkreten Szenario ein Architektur-Pattern bzw. Architektur-Stil zugeordnet wird (vgl. Abbildung 2-9). Die Zuordnung soll die Unterstützung des konkreten Szenarios durch das Architektur-Pattern bzw. den Architektur-Stil abbilden und den Bewertungsprozess beschleunigen. Die unterschiedlichen Auswirkungen eines Architektur-Pattern bzw. Architektur-Stils (positiv oder negativ) werden aber bei dieser Zuordnung nicht weiter berücksichtigt. Darüber hinaus wird nicht im Detail erläutert wie die zweite Vorlage in den Prozess der Bewertung integriert werden soll. ƒ Verwendung des Konzepts der Pattern: Der Ansatz basiert auf der gleichen Annahme,

wie die vorliegende Arbeit: die Pattern-Dokumentationen enthalten wertvolles Entwurfswissen, das innerhalb des Entwurfs und der Bewertung einer Softwarearchitektur wiederverwendet werden kann. Die unterschiedlichen Pattern-Schablonen und Abschnitte der Dokumentation werden aber nicht im Detail untersucht. Es wird nicht beschrieben, wie zwischen Architektur- und Entwurfs-Pattern sowie Architektur-Stil unterschieden wird. Der Beitrag gibt jedoch Hinweise auf die Positionierung von architektur-relevanten Informationen innerhalb der Pattern-Dokumentation. Er enthält allerdings keine Angaben zur Identifikation und Extraktion der architektur-relevanten Informationen auf Basis einer Pattern-Dokumentation. ƒ Ermittlung und Dokumentation der Beziehungen: Die Beziehungen zwischen den Ent-

wurfsentscheidungen innerhalb der Softwarearchitektur und deren Auswirkungen auf die Qualität des Systems werden zwar in der ersten Vorlage betrachtet, jedoch wird – analog zu den anderen Feldern – die Identifikation und Extraktion der Beziehungen nicht weiter beschrieben. Darüber hinaus werden die Auswirkungen auf die Qualitätsmerkmale auf lediglich zwei einfache Kategorien beschränkt.

2.7

Zusammenfassung

Im vorliegenden Kapitel wurden zunächst die Grundlagen und der Bezugsrahmen dieser Arbeit thematisiert. Die verschiedenen Definitionen des Begriffs der Softwarearchitekturen wurden aus der historischen Perspektive des Konzepts betrachtet und diskutiert (vgl. Kapitel 2.1). Es konnte dargestellt werden, dass für den Begriff der Softwarearchitektur keine einheitliche

Zusammenfassung

45

Definition existiert. Dennoch zeigte sich, dass den verschiedenen Begriffsdefinitionen ein gemeinsamer Kerngedanke zugrunde liegt: Eine Softwarearchitektur ist ein Entwurf eines Systems auf einem Abstraktionsniveau oberhalb einzelner Programme, Module und/oder Komponenten. Dieser Entwurf betrachtet die übergeordnete Struktur des Systems, d. h., es werden die einzelnen Softwareelemente mit ihren Eigenschaften und Beziehungen untersucht. Die Begriffsdefinition von Bass, Clements und Kazman, die in der vorliegenden Arbeit verwendet wird, spiegelt diesen Kerngedanken wieder. Die Relevanz der Softwareelemente, Eigenschaften und Beziehungen für den Entwurf und die Bewertung einer Softwarearchitektur kann nicht direkt, sondern nur über den Kontext eines konkreten Systems bestimmt werden. Dieser Kontext bestimmt, ob ein Softwareelement, eine Eigenschaft oder eine Beziehung architekturbezogen ist oder nicht. Die Diskussion der verschiedenen Begriffsdefinitionen und Aspekte der Softwarearchitekturen bildete den Ausgangspunkt für die Definition eines Bezugsrahmens und die Positionierung des Konzepts der Softwarearchitekturen im Kontext der Unternehmensarchitekturen (vgl. Kapitel 2.2). Die Softwarearchitektur betrachtet ausschließlich Softwareelemente und muss von der Ebene der Hardware abgegrenzt werden. Die Software- und Hardwareebene können grundsätzlich unabhängig voneinander, aber nicht vollständig isoliert, betrachtet werden, da die Softwareelemente auf Basis der Hardwareelemente implementiert bzw. ausgeführt werden. Die Softwarearchitektur kann auf zwei unterschiedlichen Abstraktionsebenen untersucht werden: Die Ebene der Softwarearchitektur fokussiert eine Anwendung und die Ebene der unternehmensweiten Softwarearchitektur alle Anwendungen eines Unternehmens. Die vorliegende Arbeit betrachtet im Wesentlichen die Ebene einer einzelnen Anwendung, d. h. der Softwarearchitektur, wobei die Ansätze und Konzepte i. d. R. auch auf die Ebene der unternehmensweiten Softwarearchitektur angewendet bzw. übertragen werden können. Die Softwarearchitekturen auf beiden Ebenen müssen von der Unternehmensarchitektur abgegrenzt werden, die ein Unternehmen aus einer ganzheitlichen Perspektive betrachtet und neben den Softwareelementen und Anwendungen, weitere Untersuchungsgegenstände, wie z. B. die Unternehmensstrategie, Geschäftsprozesse und Organisationsstrukturen, berücksichtigt. Die Bedeutung der Softwarearchitektur wurde aus einer theoretischen und praktischen Perspektive betrachtet (vgl. Kapitel 2.3). Aufgrund der unterschiedlichen Elemente, Kombinationsregeln und Verhaltensweisen sowie der daraus resultierenden unterschiedlichen Entwurfsprobleme, erhält die Softwarearchitektur aus einer theoretischen Sicht ihre Daseinsberechtigung als eigenständige Abstraktionsebene. In der Praxis der Softwareentwicklung ist sie ein wichtiges Kommunikationsinstrument und ermöglicht die Wiederverwendung von Entwurfsergebnissen auf einem hohen Abstraktionsniveau und in großem Umfang. Sie definiert die frühesten und grundlegenden Entwurfsentscheidungen eines Systems.

46

Grundlagen und Bezugsrahmen des Entwurfs von Softwarearchitekturen

Neben der Bedeutung wurden die Einflussfaktoren einer Softwarerarchitektur untersucht und es wurde erläutert, dass die Softwarearchitektur nicht ausschließlich von den Anforderungen des Systems abhängt (vgl. Kapitel 2.4). Sie wird durch technische, betriebswirtschaftliche und soziale Faktoren beeinflusst, die in der Umgebung entstehen, in der die Softwarearchitektur entworfen und eingesetzt wird. Die Existenz bzw. Umsetzung der Softwarearchitektur beeinflusst wiederum die Umgebung, in der neue Softwarearchitekturen entstehen. Dieser Rückkopplungseffekt wurde anhand des Architecture Business Cycle erläutert, der von einem Unternehmen gezielt gesteuert und kontrolliert werden kann. Die Dokumentation ist die Grundlage für die Nutzung einer Softwarearchitektur (vgl. Kapitel 2.5). Der Problematik, dass die Dokumentation zu verschiedenen Zwecken verwendet wird und die Stakeholder unterschiedliche Informationsanforderungen an die Dokumentation haben, wird mit dem Sichtenkonzept begegnet. Jede Sicht beschreibt auf Basis einer Repräsentation die Softwareelemente, deren Eigenschaften und Beziehungen aus einer bestimmten Perspektive. Die verschiedenen Sichten heben die verschiedenen Qualitätsmerkmale der Softwarearchitektur in unterschiedlichem Ausmaß hervor. Eine Softwarearchitektur kann allerdings nicht ausschließlich auf Basis von Sichten dokumentiert werden, d. h., die einzelnen Sichten müssen um eine sichten-übergreifende Dokumentation ergänzt werden. Zum Abschluss des Kapitels wurden drei Arbeiten vorgestellt, die im Kontext der vorliegenden Arbeit als „verwandt“ klassifiziert wurden (vgl. Kapitel 2.6). Die attribut-basierten Architektur-Stile von Klein, Kazman, Bass et al. erweitern die Architektur-Stile um einen Rahmen zur Analyse der Auswirkungen der Entwurfsentscheidungen innerhalb eines Architektur-Stils auf die Qualitätsmerkmale eines Systems (vgl. Kapitel 2.6.1). Die Bedeutung des ABAS-Konzepts ist im Kontext der vorliegenden Arbeit gering, da das Pattern-Konzept in diesem Zusammenhang nicht detailliert betrachtet wird. Die Differenzierung zwischen einem quantitativen und qualitativen Modell sowie der Ansatz, die variablen Parameter eines Architektur-Stils als Basis für eine Analyse der Auswirkungen zu verwenden, werden jedoch in der vorliegenden Arbeit aufgegriffen. Der Beitrag von Zhu, Ali Babar und Jeffery soll die Erstellung von konkreten Szenarios und die Auswahl eines Modells, das die Grundlage für eine detaillierte quantitative Analyse der Auswirkungen von Entwurfsentscheidungen auf die Qualitätsmerkmale bildet, unterstützen (vgl. Kapitel 2.6.2). Die Ergebnisse des Beitrags spielen für die vorliegende Arbeit nur eine untergeordnete Rolle, da die Beziehungen zwischen den Entwurfsentscheidungen innerhalb der Softwarearchitektur und deren Auswirkungen auf die Qualität des Systems nicht extrahiert und dokumentiert werden. Der Beitrag von Ali Babar soll den Entwurf und die Bewertung von Softwarearchitekturen durch die Definition von zwei Vorlagen unterstützen (vgl. Kapitel 2.6.3). Die Ergebnisse des Beitrags geben zur Beantwortung der Forschungsfragen lediglich einige Hinweise, so dass der Beitrag für die vorliegende Arbeit keine große Bedeutung hat.

3 Bewertung von Softwarearchitekturen Aufgrund der hohen Relevanz der Softwarearchitektur erhält die Bewertung einer Softwarearchitektur einen besonderen Stellenwert. Sie ermöglicht Aussagen bezüglich der Qualität einer Softwarearchitektur zu machen und davon ausgehend Aussagen bezüglich der Qualität des gesamten Systems abzuleiten. In Kapitel 3.1 werden die Ziele und Annahmen der Bewertung von Softwarearchitekturen diskutiert, indem, ausgehend von den unterschiedlichen Betrachtungsebenen des Entwurfs und deren Abhängigkeiten untereinander, die Auswirkungen der Entwurfsentscheidungen untersucht werden. Die Qualität von Softwareprodukten und -architekturen wird detailliert in Kapitel 3.2 beschrieben, indem verschiedene Konzepte und Modelle der Qualität vorgestellt und diskutiert werden. Das Kapitel 3.3 betrachtet Methoden, auf deren Basis die Qualität einer Softwarearchitektur ermittelt werden kann. Dieses Kapitel enthält u. a. auch eine Vorstellung einer derartigen Bewertungsmethode, um die Vorgehensweise und das Zusammenspiel der unterschiedlichen Konzepte und Modelle detailliert anhand eines Beispiels zu verdeutlichen.

3.1

Ziele und Annahmen der Bewertung

Die Softwarearchitektur eines Systems bzw. einer Anwendung ist eine Abstraktion, die ausschließlich die architektur-bezogenen Softwareelemente und Beziehungen zwischen diesen Elementen betrachtet (vgl. Kapitel 2.1). Durch diese Abstraktion entsteht eine neue Entwurfsebene, die aufgrund ihrer besonderen Problemstellungen von der Ebene des Quellcodes und der ausführbaren Programme abgegrenzt werden muss (vgl. [ShGa1996, S. 4]). Jede dieser Ebenen beschreibt unterschiedliche Elemente, Beziehungen und Verhaltensweisen, weshalb unterschiedliche Notationen, Entwurfsprobleme und Analysetechniken auf jeder Ebene existieren. Die Ebene der Softwarearchitektur untersucht aus einer systemweiten Perspektive die Komponenten bzw. Module einer Anwendung und deren Beziehungen, wohingegen sich die Ebene des Quellcodes primär mit Datenstrukturen und Algorithmen beschäftigt. Die Ebene der ausführbaren Programme dagegen betrachtet z. B. Hardwareregister, Speicherbereiche und -operationen. Aufgrund des unterschiedlichen Fokus der verschiedenen Ebenen können diese grundsätzlich unabhängig voneinander behandelt werden, obwohl auch Abhängigkeiten zwischen den Ebenen existieren. Einerseits basieren die grundlegenden Elemente einer Ebene auf den Konstrukten und Diensten, die durch die unmittelbar untergeordnete Ebene bereitgestellt werden. Andererseits definieren die höheren Ebenen im Fall eines konkreten Systems einen Rahmen,

48

Bewertung von Softwarearchitekturen

der den Gestaltungsspielraum der niedrigeren Ebenen einschränkt. Die Ebene der Softwarearchitektur basiert auf den Konzepten, die eine Programmiersprache bzw. eine Entwicklungsplattform zur Strukturierung des Systems bereitstellt. Dementsprechend kann es sich bei den Softwareelementen z. B. um Java-Schnittstellen (siehe z. B. [GJSB2005]) oder Enterprise JavaBeans (siehe z. B. [Sun2005]) handeln. Darüber hinaus definiert sie bestimmte Randbedingungen, die z. B. die Nutzung von Enterprise JavaBeans innerhalb der Datenhaltung vorschreiben und andere Technologien und/oder Konzepte verbieten. Die Softwarearchitektur definiert somit Einschränkungen, die auf der Ebene des Quellcodes bzw. der Implementierung berücksichtigt werden müssen und den Gestaltungsspielraum verkleinern. Die Definition von derartigen Randbedingungen und Einschränkungen stellen Entwurfsentscheidungen auf der Ebene der Softwarearchitektur dar. Die Softwarearchitektur umfasst die Menge der frühesten Entwurfsentscheidungen eines Systems bzw. einer Anwendung (vgl. Kapitel 2.3). Der große Einfluss dieser Entwurfsentscheidungen auf die Qualität eines umfangreichen und komplexen Systems wurde bereits von Dijkstra, Parnas sowie Perry und Wolf beobachtet (vgl. Kapitel 2.1) und ist noch heute Kern der wichtigsten Annahme im Kontext der Bewertung von Softwarearchitekturen: Die Entwurfsentscheidungen, die innerhalb der Softwarearchitektur getroffen werden, unterstützen oder behindern die Erreichung nahezu aller Qualitätsmerkmale einer nicht-trivialen Anwendung (vgl. [ClKK2002, S. 11, 20]). Wenn diese Entwurfsentscheidungen die Qualität eines Systems maßgeblich beeinflussen, ist es möglich, die Entscheidungen im Hinblick auf ihre konkrete Auswirkung auf die Qualitätsmerkmale zu bewerten, um so eine Vorhersage der Qualität eines gesamten Systems zu ermöglichen – auch wenn dieses noch nicht implementiert ist (vgl. [ClKK2002, S. 21]). Dabei ist allerdings zu beachten, dass die Softwarearchitektur eine notwendige, aber keine hinreichende Voraussetzung für die Qualität des gesamten Systems ist. Die Qualität eines Systems hängt demnach nicht ausschließlich von der Softwarearchitektur ab, da jede Entwurfsentscheidung auf der Ebene der Architektur durch „schlechte“ Entwurfsentscheidungen und/ oder eine „schlechte“ Implementierung auf der Ebene des Quellcodes „untergraben“ werden kann (vgl. [BaCK2003, S. 30 f.]). Obwohl die Annahme, dass die Qualität eines Systems maßgeblich durch die Softwarearchitektur beeinflusst wird, die wesentliche Motivation der Bewertung von Softwarearchitekturen ist, konnte eine Literaturrecherche keine Arbeiten identifizieren, die diese Annahme empirisch untermauert. Die Annahme basiert stattdessen auf den Erfahrungen, die zahlreiche Architekten und Softwareentwickler über Jahre gesammelt und dokumentiert haben (vgl. Kapitel 2.1). Clements, Kazman und Klein weisen in diesem Kontext explizit darauf hin, dass die vorgestellten Methoden und Techniken von ihnen selbst oder von anderen Wissenschaftlern des

Qualität von Softwareprodukten und -architekturen

49

Software Engineering-Instituts entwickelt und innerhalb von zahlreichen praktischen Projekten angewendet worden sind (vgl. [ClKK2002, S. xviii f.]). Die ungenaue Formulierung und Validierung der Aussage ist aus wissenschaftstheoretischer Sichtweise – insbesondere aus der Sichtweise des kritischen Rationalismus (vgl. z. B. [Albe1975]) – kritisierbar, da die intersubjektive Nachprüfbarkeit nicht gewährleistet ist. Dennoch wird in der vorliegenden Arbeit von der Wahrheit dieser Annahme ausgegangen. Das übergreifende Ziel der Bewertung von Softwarearchitekturen ist, die Beziehungen zwischen den Entwurfsentscheidungen innerhalb der Architektur und deren Auswirkungen auf die Qualität eines Systems systematisch zu untersuchen, zu verstehen und zu bewerten, um die Analyse und den Entwurf einer Softwarearchitektur zu erleichtern (vgl. [ClKK2002, S. 110]). Die Kenntnis dieser Beziehungen ermöglicht einen gezielten Entwurf und die Bewertung einer Softwarearchitektur im Hinblick auf die spezifizierten Qualitätsanforderungen. Darüber hinaus ermöglicht die strukturierte Dokumentation der Beziehungen eine explizite Wiederverwendung des Wissens, das bisher ausschließlich in den Köpfen von erfahrenen Softwarearchitekten existiert (vgl. [ClKK2002, S. 110]). Eine Softwarearchitektur kann aber – analog zu einem Produkt (vgl. [ISIE2001, S. 4]) – nur im Kontext der spezifizierten Anforderungen bewertet werden. Es existiert deshalb per se keine „gute“ oder „schlechte“ Softwarearchitektur, sondern eine Softwarearchitektur ist für einen definierten Einsatzbereich, der durch die jeweiligen Anforderungen spezifiziert wird, mehr oder weniger geeignet (vgl. [BaCK2003, S. 15; ClKK2002, S. 29]). Die Bewertung einer Softwarearchitektur beabsichtigt daher, eine Aussage über den Grad der Erfüllung der spezifizierten Anforderungen zu treffen.

3.2

Qualität von Softwareprodukten und -architekturen

Die folgende Diskussion der Qualität von Softwareprodukten und -architekturen umfasst die Beschreibung der verschiedenen grundlegenden Ansätze der Qualität, um die verschiedenen Sichtweisen der Qualität zu verdeutlichen (Kapitel 3.2.1). Die Beurteilung der Qualität eines Softwareprodukts und einer Softwarearchitektur erfolgt auf Basis der Konzepte, Methoden und Techniken, die als Teil eines Qualitätsmodells definiert sind. Das Kapitel 3.2.2 beschreibt daher den grundlegenden Aufbau der Qualitätsmodelle und charakterisiert die Eigenschaften eines Softwareprodukts bzw. einer Softwarearchitektur. Darüber hinaus werden die allgemeinen Probleme diskutiert, die bei der Anwendung eines derartigen Modells auftreten können. Zur Verdeutlichung der grundlegenden Konzepte der Qualitätsmodelle werden in Kapitel 3.2.3 das Qualitätsmodell des ISO/IEC15 9126-Standards und in Kapitel 3.2.4 das Qualitäts15

International Electrotechnical Commission (IEC)

50

Bewertung von Softwarearchitekturen

modell des Software Engineering-Instituts vorgestellt und kritisch analysiert. Die Auswahl der beiden Modelle erfolgte aufgrund ihrer großen Verbreitung im Kontext der Bewertung von Softwareprodukten und -architekturen. Darüber hinaus ist die Untersuchung der beiden Qualitätsmodelle eine Vorbereitung auf die Entwicklung des Wissensmodells und der Vorgehensweise, die ausgewählte Konzepte der beiden Modelle wiederverwenden (siehe Kapitel 1).

3.2.1 Bezugsrahmen der Softwarequalität Der Begriff der Qualität beschreibt im Allgemeinen eine Eigenschaft eines Produkts oder einer Dienstleistung. Das Konzept der Qualität ist grundsätzlich komplex und vielfältig, was dazu geführt hat, dass verschiedene Diziplinen, wie z. B. Philosophie, Volkswirtschaft, Marketing oder Unternehmensführung, unterschiedliche Perspektiven, Terminologien und Bezugssysteme entwickelt haben (vgl. [Garv1984]). Die unterschiedlichen Sichtweisen führen häufig dazu, dass zwischen Vertretern der unterschiedlichen Disziplinen Kommunikationsprobleme entstehen, die insbesondere auf die unterschiedlichen Terminologien zurückzuführen sind. Garvin hat aus diesem Grund verschiedene Diziplinen analysiert und fünf grundlegende Ansätze zur Definition des Qualitätsbegriffs identifiziert (vgl. [Garv1984]): ƒ Der transzendente Ansatz kommt aus der Philosophie und beschreibt Qualität als eine

absolute, universell erkennbare und kompromislose Größe, die allerdings nicht genau definiert oder gemessen werden kann. Die Bewertung der Qualität kann nach diesem Ansatz nur nach der eigenen Erfahrung mit einem Produkt oder einer Dienstleistung erfolgen. ƒ Der produkt-bezogene Ansatz wurde zunächst in der Volkswirtschaft verwendet und

unterscheidet sich wesentlich vom transzendenten Ansatz: Qualität wird innerhalb dieses Ansatzes als eine genaue und messbare Variable verstanden, die dazu verwendet werden kann, eine Rangordnung zwischen verschiedenen Produkten herzustellen. Die Unterschiede in der Qualität spiegeln dabei die Qualitätsunterschiede der Bestandteile des Produkts oder einer Eigenschaft des Produkts wider. Dabei berücksichtigt dieser Ansatz nur das Produkt, d. h., der Kunde mit seiner subjektiven Wahrnehmung wird nicht betrachtet. ƒ Der benutzer-bezogene Ansatz kommt aus dem Bereich des Marketings und betrachtet

die Qualität eines Produkts ausschließlich aus der Sicht des Kunden bzw. Benutzers. Dieser hat unterschiedliche Wünsche und Bedürfnisse und entscheidet über die Qualität eines Produkts, indem er darüber entscheidet, wie gut das Produkt seinen Wünschen und Bedürfnissen entspricht.

Qualität von Softwareprodukten und -architekturen

51

ƒ Der prozess-bezogene Ansatz betrachtet die Qualität aus der Perspektive des Unter-

nehmensbereichs der Produktion. Er geht davon aus, dass die Entwurfsphase eines Produkts abgeschlossen ist und dass jede Abweichung vom Entwurf innerhalb der Produktion zu einer Reduktion der Qualität führt, da Produkte, die vom Entwurf abweichen, wahrscheinlich unzuverlässig und fehlerhaft sind und daher die Bedürfnisse des Kunden weniger befriedigen. ƒ Der wert-bezogene Ansatz betrachtet Qualität als eine Funktion von Kosten und Preisen.

Demnach kennzeichnet sich ein qualitativ hochwertiges Produkt dadurch aus, dass es die Bedürfnisse zu einem akzeptablen Preis befriedigt. Im Kontext der Betrachtung der Qualität eines Softwareprodukts bzw. einer Softwarearchitektur ist der transzendente Ansatz nicht geeignet, da die Qualität als eine nicht genau definierbare und messbare Größe gesehen wird. Darüber hinaus kann nach diesem Ansatz die Qualität nur durch die eigene Erfahrung des Produkts bzw. der Dienstleistung bewertet werden, was im Kontext von Softwareprodukten bzw. -architekturen eine Implementierung voraussetzt. Die ausschließliche Bewertung eines Entwurfs ist daher innerhalb dieses Ansatzes nicht vorgesehen. Der produkt-bezogene Ansatz kann grundsätzlich in diesem Kontext verwendet werden, wobei dessen ausschließliche Verwendung dazu führen kann, dass die Kundeninteressen nicht ausreichend berücksichtigt werden. Wenn in Anlehnung an den benutzer-bezogenen Ansatz aber ausschließlich die Kundeninteressen bei der Entwicklung eines Produkts berücksichtigt werden, kann dies wiederum dazu führen, dass die produkt-spezifischen Qualitätseigenschaften vernächlässigt werden. Der prozess-bezogene Ansatz ist zwar bei der Entwicklung von Softwareprodukten bzw. -architekturen relevant, jedoch kann auf Basis dieses Ansatzes nur ein Teilaspekt der Qualitätsproblematik betrachtet werden, d. h., die Fragestellung, wie der Entwurf eines Softwareprodukts ohne Abweichungen und unter Gewährleistung der Qualität in den Quellcode transformiert werden kann. Der Aspekt der Qualität des eigentlichen Entwurfs wird nach diesem Ansatz nicht berücksichtigt. Der wert-bezogene Ansatz könnte grundsätzlich im Kontext von Softwareprodukten und Softwarearchitekturen verwendet werden, jedoch werden innerhalb dieses Ansatzes zwei verschiedene Konzepte vermischt: die Qualität ist ein Maß der Güte, wohingegen der Preis ein Maß der Wertschätzung darstellt (vgl. [Garv1984]). Betrachtet man diesen Ansatz insbesondere im Kontext der Softwarearchitektur, ist er nicht geeignet, da die Architektur i. d. R. nicht mit einem dedizierten Preis ausgestattet ist. Zusammengefasst lässt sich festhalten, dass nur der produkt- und der benutzer-bezogene Ansatz für den Einsatz im Kontext der Entwicklung von Softwareprodukten und -architekturen geeignet sind.

52

Bewertung von Softwarearchitekturen

3.2.2 Konzept der Qualitätsmodelle Die Diskussion der unterschiedlichen Ansätze zur Definition des Qualitätsbegriffs hat gezeigt, dass im Kontext der Entwicklung eines Softwareprodukts bzw. einer Softwarearchitektur nur die Ansätze geeignet sind, die die Qualität als eine messbare Größe betrachten und darüber hinaus neben den Produkteigenschaften auch die Wünsche und Bedürfnisse des Nutzers betrachten. Insbesondere die Messbarkeit ist im Kontext der Software notwendig, um vor dem Beginn der Entwicklung entsprechend detaillierte Qualitätsanforderungen an ein Produkt zu spezifizieren und während bzw. nach der Entwicklung auch überprüfen zu können, ob diese Anforderungen erreicht worden sind. Die Spezifikation und Überprüfung der Qualitätsanforderungen ermöglicht es, das Konzept der Qualität anwendbar zu machen.

3.2.2.1 Aufbau von Qualitätsmodellen Im Kontext der Softwareprodukte und -architekturen wird die Anwendbarkeit des Qualitätskonzepts durch sog. Qualitätsmodelle unterstützt, die ausgehend vom allgemeinen Begriff der Softwarequalität sog. Qualitätsmerkmale16 und -indikatoren ableiten (vgl. [Balz1998, S. 257 f.]). Die Eigenschaft der Qualität wird dadurch mess- und bewertbar gemacht. Unter dem Begriff der Softwarequalität wird die Gesamtheit der Merkmale eines Softwareprodukts verstanden, die eine Aussage bezüglich der Eignung des Produkts ermöglichen, spezifizierte Anforderungen zu erfüllen (vgl. [Balz1998, S. 257]). Erst der Einsatz eines Qualitätsmodells ermöglicht die Formulierung von aussagekräftigen Anforderungen, die innerhalb der Entwicklung eines Produkts berücksichtigt werden können. Die praktische Erfahrung zeigt allerdings, dass die fachlichen Anforderungen innerhalb eines Softwareentwicklungsprozesses häufig pauschale Anforderungen bezüglich der Qualität einer Anwendung enthalten, wie das folgende Beispiel verdeutlicht: „Die Anwendung soll pflegeleicht, wartbar und erweiterbar sein.“. Diese Anforderung ist nicht verwendbar, da sie nicht detailliert genug spezifiziert ist, um sie innerhalb des Softwareentwicklungsprozesses berücksichtigen und überprüfen zu können. Eine detaillierte Spezifikation würde eine genaue Definition der Merkmale „pflegeleicht“, „wartbar“ und „erweiterbar“ voraussetzen, um darauf basierend eine Methode zu definieren, die es ermöglicht die Erreichung der Merkmale zu messen und zu beurteilen.

16

Die englischsprachige Literatur verwendet unterschiedliche Begriffe, wie z. B. „quality attribute“ (vgl. z. B. [BaCK2003, S. 71 ff.; ClKK2002, S. 109 ff.]) oder „quality characterization“ (vgl. z. B. [ISIE2001, S. 1 ff.]. Da die unterschiedlichen Begriffe sehr gut mit dem deutschen Begriff „Merkmal“ übersetzt werden können, wird in der vorliegenden Arbeit der Begriff des „Qualitätmerkmals“ verwendet.

Qualität von Softwareprodukten und -architekturen

53

Die Qualitätsmodelle definieren zur Lösung dieser Problematik Qualitätsmerkmale, die durch Teilmerkmale verfeinert werden. Die Teilmerkmale wiederum werden durch Indikatoren bzw. Metriken verfeinert, die mess- und bewertbar sind (siehe Abbildung 3-1).

Abbildung 3-1: Aufbau von Qualitätsmodellen Quelle: in Anlehnung an [Balz1998, S. 257]

Die Indikatoren bzw. Metriken können auf Basis von sog. Qualitätsmaßen Eigenschaften quantitativ oder qualitativ messen. Dabei können die Eigenschaften des Softwareprodukts als Ganzes und auch die Eigenschaften der Zwischenprodukte gemessen werden, die innerhalb des Softwareentwicklungsprozesses zur Herstellung des Endprodukts verwendet werden (vgl. z. B. [ISIE2001, S. 3, S. 19; Balz1998, S. 271]). Das Ergebnis einer Messung ist ein Meßwert, der auf einer Skala abgebildet und in eine Rangfolge eingeordnet werden kann. Die Softwarearchitektur ist in diesem Kontext als ein Zwischenprodukt zu verstehen, d. h., ein Qualitätsmodell kann auch verwendet werden, um eine Softwarearchitektur zu bewerten. Ein derartig aufgebautes Qualitätsmodell wird in Anlehnung an die englischen Begriffe, die in Abbildung 3-1 in Klammern dargestellt sind, als sog. Factor-Criteria-Metrics-Modell (FCMModell) bezeichnet (vgl. [Balz1998, S. 258]). Da mehrere Qualitätsmerkmale gemeinsame Teilmerkmale besitzen können, kann die grundlegende Struktur eines FCM-Modells einen Baum oder ein Netz bilden. Die Teilmerkmale können in weitere Teilmerkmale verfeinert werden, so dass das Modell mehr als drei Ebenen enthalten kann. Daneben existieren sog. Goal-Question-Metrics-Modelle (GQM-Modelle), die Vorgehensmodelle darstellen und den Aufbau eines projekt- oder unternehmensspezifischen Qualitätsmodells unterstützen (vgl. [Balz1998, S. 263]). Balzert hat auf Basis dieser Klassifikation und zehn weiteren Kriterien acht ausgewählte Qualitätsmodelle verglichen (siehe [Balz1998, S. 274]). Im Kontext der vorliegenden Arbeit ist

54

Bewertung von Softwarearchitekturen

aus dieser Klassifikation lediglich das Qualitätsmodell relevant, das innerhalb des ISO/IEC 9126-Standards definiert wird (siehe Kapitel 3.2.3).

3.2.2.2 Eigenschaften eines Softwareprodukts Die Eigenschaften eines Softwareprodukts lassen sich in zwei grundsätzliche Mengen klassifizieren: funktionale und nicht-funktionale Eigenschaften. Die funktionalen Eigenschaften beschreiben die Fähigkeit eines Systems bzw. einer Anwendung, die Funktionen bereitzustellen, die die Ausführung der vorgesehenen Aufgaben ermöglichen (vgl. [ISIE2001, S. 7]). Diese Eigenschaften beziehen sich auf die Frage, welche Funktionen die Software zur Erreichung der Anforderungen beiträgt. Die nicht-funktionalen Eigenschaften spezifizieren, wie die Funktionen bereitgestellt werden. Entsprechend dieser Klassifkation wird zwischen funktionalen und nicht-funktionalen Anforderungen sowie funktionalen und nicht-funktionalen Qualitätsmerkmalen differenziert. Die funktionalen und nicht-funktionalen Eigenschaften sind nicht direkt voneinander abhängig, d. h., die Auswahl einer Funktion beeinflusst nicht direkt, wie die Funktion bereitgestellt wird (vgl. [BaCK2003, S. 72]). Die Frage, ob z. B. ein Online-Shop die Bezahlung auf Basis von Kreditkarten ermöglicht, ist somit grundsätzlich unabhängig von der Frage, wie sicher oder schnell diese Funktion ist, da die Funktionalität eines Systems bzw. einer Anwendung grundsätzlich unabhängig von der internen Struktur ist. Jede Funktion kann durch eine Vielzahl von Kombinationen der Softwareelemente (vgl. Kapitel 2.1) realisiert werden, die einzeln und insgesamt eine Menge von Eigenschaften besitzen, die die funktionalen Eigenschaften nicht direkt beeinflussen. Die Funktionalität eines Systems bzw. einer Anwendung kann daher auf Basis von verschiedenen Softwarearchitekturen realisiert werden, die unterschiedliche nicht-funktionale Eigenschaften besitzen. Das bedeutet allerdings nicht, dass jede Funktion mit jeder beliebigen Qualität realisiert werden kann (vgl. [BaCK2003, S. 72]). Die Verarbeitung und Analyse von z. B. einem Terabyte Bewegungsdaten auf Basis eines Datenbankmanagementsystems zum Zweck des sog. Data Minings ist inhärent komplex und aufwändig; sie kann i. d. R. nicht im Bereich von Millisekunden erfolgen. Dennoch kann durch die Entwurfsentscheidungen innerhalb der Softwarearchitektur die relative Qualität dieser Verarbeitung beeinflusst und gesteuert werden, ob die Verarbeitung z. B. 12 Stunden oder zwei Tage benötigt (vgl. [BaCK2003, S. 72]). Die Softwarearchitektur definiert die Randbedingungen und Entwurfsentscheidungen, die primär die nicht-funktionalen Qualitätsmerkmale eines Systems bzw. einer Anwendung beeinflussen und somit die relative Qualität der Funktionen bestimmen. Die Unabhängigkeit der funktionalen und nicht-funktionalen Eigenschaften erleichtert die Untersuchung und Entwicklung von Konzepten, Modellen, Methoden und Werkzeugen im Bereich der Bewertung von Softwarearchitekturen, da von spezifischen funktionalen Anforderungen abstrahiert wer-

Qualität von Softwareprodukten und -architekturen

55

den kann, d. h., diese werden bei der Analyse der Beziehungen zwischen den Entwurfsentscheidungen innerhalb der Architektur und deren Auswirkungen auf die Qualität eines Systems (vgl. Kapitel 3.1) nicht berücksichtigt.

3.2.2.3 Probleme bei der Anwendung von Qualitätsmodellen In der Wissenschaft und Praxis existieren zahlreiche Qualitätsmodelle, die aufgrund von unterschiedlichen Konzepten, Modellen, Qualitätsmerkmalen und Metriken nicht direkt miteinander vergleichbar sind. Bass, Clements und Kazman schlagen zur Lösung dieses Problems vor, dass jedes Qualitätsmodell eine kurze Beschreibung der verwendeten Qualitätsmerkmale enthalten soll, so dass die wesentlichen Konzepte des Modells deutlich und nachvollziehbar werden (vgl. [BaCK2003, S. 74 f.]). Der ISO/IEC 9126-Standard dagegen hat als internationaler Standard das Ziel, eine einheitliche Terminologie für die Qualität von Softwareprodukten zu definieren (vgl. [ISIE2001, S. 1 f.]). Bei der Verwendung des Standards fordert er darüber hinaus, die Vernachlässigung von bestimmten Qualitätsmerkmalen zu begründen. Wird ein anderes Qualitätsmodell verwendet, fordert der Standard sogar die Dokumentation der Transformationen in die Qualitätsmerkmale des Standards. Da der Standard nicht konsequent genutzt wird bzw. keine entsprechenden Transformationsregeln dokumentiert werden, bleibt die mangelnde Vergleichbarkeit ein Problem bei der Anwendung von Qualitätsmodellen. Ein weiteres Problem ist die (noch) mangelnde detaillierte Kenntnis der Beziehungen zwischen den Qualitätsmerkmalen und den Metriken, d. h., die Frage, welche Menge von Metriken verwendet werden muss und wie die Ergebnisse interpretiert werden müssen, um eine bestimmte Aussage bezüglich eines Qualitätsmerkmal treffen zu können (vgl. z. B. [Zuse1999, S. 14 f.]). Aus diesem Grund umfasst der eigentliche ISO/IEC 9126-Standard keine Metriken (siehe [ISIE2001]). Diese sind in drei weiteren Teilen – sog. technischen Berichten (technical reports) des sog. Typs „2“ – ausgelagert, die veröffentlicht werden können, wenn sich ein Themenfeld z. B. noch in der Entwicklung befindet und noch keine Einigung auf einen internationalen Standard erzielt werden kann (vgl. [ISIE2003a, S. vi; ISIE2003b, S. vi; ISIE2004, S. iv]). Diese drei Teile sind im Gegensatz zum ersten Teil keine internationalen Standards im eigentlichen Sinne, sondern sie ergänzen den Standard und ermöglichen insbesondere ein vertieftes Verständnis des Qualitätsmodells, das im ersten Teil definiert wird. Darüber hinaus stellt die mangelnde Anwendbarkeit der Qualitätsmerkmale und Metriken ein Problem dar (vgl. [BaCK2003, S. 74; BELS2003, S. 3]). Diese entsteht dadurch, dass die Qualitätsmodelle keinen Kontext berücksichtigen und deshalb keine aussagekräftigen Anforderungen spezifiziert werden können. Die Aussage, dass eine Anwendung wartbar und erweiterbar sein soll, ist nichtssagend, denn jede Anwendung ist im Hinblick auf eine Menge von

56

Bewertung von Softwarearchitekturen

Änderungen mit weniger Aufwand und für eine andere Menge von Änderungen mit mehr Aufwand modifizierbar. Erst durch den Bezug zu einem Kontext entsteht eine Aussagekraft, die z. B. durch eine Aufwandschätzung detailliert werden kann. So könnte z. B. eine bestimmte Anwendung im Hinblick auf ihre Benutzeroberfläche mit wenig Aufwand änderbar sein, wohingegen die Änderung ihres Datenmodells mit viel Aufwand verbunden ist. Je detaillierter der Kontext spezifiziert wird, desto genauer kann eine Aufwandschätzung erfolgen. Die Änderungen einer Benutzeroberfläche könnten z. B. bis auf die Ebene der einzelnen Oberflächenelemente spezifiziert werden, um eine möglichst genaue Aufwandschätzung durchzuführen. Weiterhin ist zu beachten, dass die Qualitätsmodelle, wie z. B. das Modell des ISO/IEC 9126Standards, zwischen quantitativen und qualitativen Metriken bzw. Indikatoren unterscheiden. Die quantitativen Metriken können nur für (Zwischen-)Produkte erhoben werden, die bereits erstellt worden sind. Das Zeitverhalten einer Anwendung kann quantitativ nur erhoben werden, wenn die Anwendung vollständig implementiert ist. Insbesondere im Kontext der Bewertung sind allerdings Metriken bzw. Indikatoren relevant, die Aussagen bezüglich der Qualität vor der Fertigstellung des Produkts ermöglichen, um bei einer Abweichung von den geforderten Qualitätsanforderungen frühzeitig Gegenmaßnahmen einleiten zu können. Die quantitativen Metriken benötigen daher Methoden, die eine sichere und genaue Vorhersage der Qualitätsmaße ermöglichen. Analog zu der mangelnden detaillierten Kenntnis der Beziehungen zwischen den Qualitätsmerkmalen und den Metriken, sind derartige Prognosemodelle noch Gegenstand der Forschung (vgl. [Zuse1999, S. 14 f.]), so dass noch keine exakten quantitativen Vorhersagen möglich sind. Vor der Fertigstellung eines Produkts sind deshalb nur qualitative Vorhersagen möglich.

3.2.3 Qualitätsmodell des ISO/IEC 9126-Standards Der ISO/IEC 9126-Standard besteht aus vier Teilen, wobei es sich lediglich bei dem ersten Teil, der zwei Hierarchien von Qualitätsmerkmalen beschreibt, um einen internationalen Standard im eigentlichen Sinn handelt (siehe [ISIE2001]). Die anderen drei Teile, die Metriken beschreiben, sind als technische Berichte (technical reports) klassifiziert, da sich der Bereich der Metriken z. Z. noch in der Entwicklung befindet bzw. noch keine Einigung auf einen internationalen Standard erzielt werden konnte (vgl. Kapitel 3.2.2.3). Die erste Version des Standards von 1991 (siehe [ISIE1991]) wurde überarbeitet und beschreibt im Gegensatz zu der ersten Version keine Aspekte eines Bewertungsprozesses (vgl. [ISIE2001, S. v]). Diese wurden in den Standard ISO/IEC 14598 (siehe z. B. [ISIE1999]17) ausgelagert, um das Qualitätsmodell und den Bewertungsprozess zu entkoppeln und beide 17

Der Standard ISO/IEC 14598 besteht aus insgesamt sechs Teilen. Hier wird stellvertretend nur der erste Teil referenziert.

Qualität von Softwareprodukten und -architekturen

57

Standards unabhängig voneinander nutzen zu können. Auf Basis der überarbeiteten Version ist es z. B. möglich, dass Qualitätsmodell des ISO/IEC 9126-Standards innerhalb von anderen Bewertungsprozessen zu nutzen. Der Standard wird aufgrund seines Status als internationaler Standard und der dadurch unterstützten Vergleichbarkeit und Nachvollziehbarkeit im Kontext der vorliegenden Arbeit detailliert vorgestellt. Darüber hinaus bildet das Qualitätsmodell des Standards eine Grundlage bei der Entwicklung des Wissensmodells in Kapitel 5.1.

3.2.3.1 Anwendungsbereiche und Ziele Der ISO/IEC 9126-Standard kann für die Spezifikation von funktionalen und nicht-funktionalen Anforderungen (vgl. Kapitel 3.2.2.2) von Kunden und Benutzern verwendet werden (vgl. [ISIE2001, S. 1]). Er ist nicht auf eine bestimmte Art von Software limitiert, sondern kann für alle software-intensiven Systeme verwendet werden. Er ermöglicht die Spezifikation und Bewertung der Softwareprodukt-Qualität aus unterschiedlichen Perspektiven, die innerhalb des Lebenszyklus eines Softwareprodukts relevant sind (Anforderungsanalyse, Kauf, Entwicklung, Benutzung, Wartung usw.) (vgl. [ISIE2001, S. 1]). Die wesentlichen Ziele des Standards sind die Definition einer einheitlichen Terminologie für die Softwareprodukt-Qualität und die Beschreibung eines Rahmens, der zur Orientierung bei der Spezifikation von Qualitätsanforderungen verwendet werden kann (vgl. [ISIE2001, S. 1]). Der Rahmen ermöglicht die Vollständigkeit der Qualitätsanforderungen zu validieren und Abwägungen zwischen den Fähigkeiten eines Softwareprodukts zu treffen.

3.2.3.2 Qualitätsansätze Der ISO/IEC 9126-Standard unterscheidet zwischen vier Ansätzen der Qualität (siehe Abbildung 3-2): ƒ Prozessqualität, ƒ interne Qualitätseigenschaften, ƒ externe Qualitätseigenschaften und ƒ Qualitätseigenschaften der Nutzung.

Im Kontext der Qualität des Softwareprodukts differenziert der Standard explizit zwischen den internen und externen Qualitätseigenschaften. Die internen Eigenschaften sind Eigenschaften der Zwischenprodukte, die direkt oder indirekt in das Softwareendprodukt einfließen, und werden typischerweise durch statische Kennzahlen der Zwischenprodukte bewertet (vgl. [ISIE2001, S. 3]). Die externen Eigenschaften sind Eigenschaften des Softwareprodukts als

58

Bewertung von Softwarearchitekturen

Ganzes und bewerten typischerweise das Verhalten der gesamten Anwendung (vgl. [ISIE2001, S. 3]).

Abbildung 3-2: Qualitätsansätze des ISO/IEC 9126-Standards Quelle: in Anlehnung an [ISIE2001, S. 1]

Die Qualität der Prozesse, die den Lebenszyklus eines Softwareprodukts gestalten, beeinflusst die Produktqualität, indem sie auf die internen Qualitätseigenschaften einer Software einwirken. Dieser Einfluss entsteht z. B. durch die Definition eines verbindlichen Prozessschrittes, der eine Überprüfung jedes Zwischenprodukts vor der weiteren Verwendung vorsieht. Die internen Qualitätseigenschaften einer Software hängen widerum von der Qualität der Prozesse ab, da z. B. die Zwischenprodukte vor der weiteren Verwendung nur überprüft werden, sofern der Entwicklungsprozess dies vorsieht. Die Qualität der Lebenszyklusprozesse eines Softwareprodukts ist allerdings nicht Bestandteil des ISO/IEC 9126-Standards (vgl. Abbildung 3-2). Die internen Qualitätseigenschaften beeinflussen die externen Qualitätseigenschaften. Eine geringe Anzahl von Fehlern in den einzelnen Modulen bzw. Komponenten wirkt sich z. B. positiv auf die Fehleranfälligkeit der gesamten Anwendung aus. Analog hängen die externen Qualitätseigenschaften von den internen Qualitätseigenschaften ab, d. h. die Qualität des gesamten Softwareprodukts kann nur so gut wie die Qualität der einzelnen Zwischenprodukte sein. Ein einziges fehlerhaftes Modul kann z. B. zum Absturz einer Anwendung führen und deshalb die Stabilität der gesamten Anwendung gefährden. Die externen Qualitätseigenschaften beeinflussen die Qualität der Nutzung des Softwareprodukts im jeweiligen Kontext. Die Qualität der Nutzung beschreibt den zusammengefassten Effekt der sechs Qualitätsmerkmale für die interne und externe Qualität, die im folgenden Kapitel erläutert werden. Ist z. B. eine Anwendung mit Fehlern behaftet und daher instabil, ist die Qualität der Nutzung reduziert. Analog hängt die Qualität der Nutzung von den externen Qualitätseigenschaften der

Qualität von Softwareprodukten und -architekturen

59

Anwendung ab, d. h. die Nutzung eines Softwareprodukts kann nur erfolgreich sein, wenn die externen Qualitätseigenschaften der Anwendung dies zulassen.

3.2.3.3 Qualitätsmodell Das Qualitätsmodell des ISO/IEC 9126-Standards besteht aus zwei Teilen, die zum einen die interne und externe Qualität des Softwareprodukts und zum anderen die Qualität der Nutzung des Softwareproduktes betrachten (vgl. [ISIE2001, S. 1]). Der erste Teil beschreibt sechs Qualitätsmerkmale, die in weitere Teilmerkmale verfeinert werden. Die Teilmerkmale werden sowohl für die Bewertung der internen als auch externen Qualitätseigenschaften verwendet (siehe Abbildung 3-3).

Abbildung 3-3: Qualitätsmerkmale für die interne und externe Qualität Quelle: in Anlehnung an (vgl. [ISIE2001, S. 7])

Der Standard enthält für jedes Qualitäts- und Teilmerkmal eine entsprechende Definition, die die Fähigkeiten des Softwareprodukts in Bezug auf das jeweilige Merkmal beschreibt.

Abbildung 3-4: Qualitätsmerkmale für die Qualität der Nutzung Quelle: in Anlehnung an (vgl. [ISIE2001, S. 12])

Der zweite Teil des Qualitätsmodells spezifiziert vier Qualitätsmerkmale, die für die Bewertung der Qualität der Nutzung verwendet werden. Diese Merkmale werden nicht in weitere Teilmerkmale verfeinert (vgl. Abbildung 3-4).

60

Bewertung von Softwarearchitekturen

Analog zu dem ersten Teil des Qualitätsmodells enthält der Standard entsprechende Definitionen und eine Beschreibung der Fähigkeiten des Softwareprodukts. Die technischen Berichte mit den Referenznummern ISO/IEC 9126-2 und ISO/IEC 9126-3, die den Standard ergänzen, enthalten Metriken mit denen die Teilmerkmale gemessen werden können (vgl. [ISIE2003a; ISIE2003b]).

3.2.3.4 Metriken Die technischen Berichte dokumentieren für jedes Qualitäts- bzw. Teilmerkmal eine Menge von Metriken, die zur Messung der internen und externen Qualitätseigenschaften sowie der Qualität der Nutzung verwendet werden können. Alle drei Berichte weisen allerdings explizit darauf hin, dass die Menge der beschriebenen Metriken nicht vollständig und nicht validiert worden ist (vgl. [ISIE2003a, S. 4; ISIE2003b, S. 4; ISIE2004, S. 4]). Daher ist die Auswahl, Anpassung und Erweiterung der Metriken bewusst vorgesehen. Die Berichte umfassen im Wesentlichen eine Beschreibung der Anwendung der Metriken, eine Menge von grundlegenden Metriken für jedes Teilmerkmal und ein Beispiel, das beschreibt, wie die Metriken innerhalb des Softwarelebenszyklus angewendet werden (vgl. [ISIE2003a, S. 1]18). Die grundsätzliche Anwendung der Metriken ist kurz beschrieben und in die folgenden Schritte strukturiert (vgl. [ISIE2003a, S. 3]): ƒ Auswahl der Qualitäts- und Teilmerkmale des ISO/IEC 9126-Qualitätsmodells, die be-

wertet werden sollen, ƒ Identifikation der geeigneten direkten und indirekten Qualitätsmaße, ƒ Auswahl der relevanten Metriken und ƒ objektive Interpretation des Maßes.

Die internen Metriken sollen frühzeitig innerhalb des Entwicklungsprozesses verwendet werden, um verschiedene Zwischenprodukte zu bewerten und auf dieser Basis die Qualität des gesamten Softwareprodukts vorherzusagen. Die externen Metriken können erstmalig in der Testphase eines Entwicklungsprozesses, d. h., wenn das Softwareprodukt erstmalig vollständig ausführbar vorliegt, verwendet werden. Die Qualität der Nutzung kann erst bestimmt werden, wenn das Produkt im vorgesehenen Einsatzbereich verwendet wird.

18

Da der grundsätzliche Aufbau der drei technischen Berichte gleich ist, wird im folgenden Kapitel stellvertretend nur der erste Bericht referenziert.

Qualität von Softwareprodukten und -architekturen

61

Die Menge der Metriken, die für jedes Teilmerkmal beschrieben werden, werden innerhalb einer einheitlichen Tabellenstruktur dokumentiert (vgl. [ISIE2003a, S. 4]). Der Aufbau dieser Struktur wird in Tabelle 3-1 zusammengefasst.

Bezeichnung der Spalte

Beschreibung der Spalte

Name der Metrik

Der Name der Metrik. Korrespondierende interne und externe Metriken haben ähnliche Namen.

Ziel bzw. Zweck der Metrik

Das Ziel bzw. der Zweck der Metrik wird in Form einer Frage formuliert, die auf Basis der Anwendung beantwortet werden muss.

Anwendung der Metrik

Eine Kurzfassung der Anwendung der Metrik.

Messung, Formeln und Berechnung der Elemente

Die Formel zur Berechnung inklusive einer Beschreibung der Bedeutung der einzelnen Elemente der Formel.

Interpretation des gemessenen Werts

Der Wertebereich der Metrik und die bevorzugten Werte.

Skalenniveau

Das zugrunde liegende Skalenniveau der Metrik. Es wird zwischen Nominal-, Ordinal-, Intervall-, Verhältnis- und Absolutskala unterschieden.

Maßeinheit

Die Maßeinheit unterscheidet zwischen Größe, Zeit und Anzahl.

Eingabedaten der Messung

Die Daten, die innerhalb der Messung verwendet werden.

ISO/IEC 12207 SCLP Referenz

Die Projektphase(n), in der die Metrik anwendbar ist/sind. Als Referenz wird der ISO/IEC 12207-Standard verwendet, der eine einheitliche Terminologie für die Phasen, Aktivitäten und Aufgaben eines Softwarelebenszyklusprozesses definiert (siehe [ISIE1995]).

Zielpersonen

Die Zielpersonen der Metrik. Tabelle 3-1: Tabellenstruktur der Dokumentation der Metriken

Zusätzlich beschreibt ein Beispiel auf einem hohen Abstraktionsniveau die Anwendung des Qualitätsmodells und der Metriken (vgl. [ISIE2003a, S. 73 ff.]). Auf Basis der Phasen eines Entwicklungsprozesses wird verdeutlicht, dass die internen und externen Eigenschaften erstmalig gemessen werden können, wenn die entsprechenden Zwischenprodukte erstellt bzw. das Softwareendprodukt implementiert ist (vgl. [ISIE2003a, S. 73]). Anderenfalls können die Werte einer Metrik nur vorausgesagt werden. Im Kontext dieses Beispiels wird veranschaulicht, dass die Softwarearchitektur eines Systems bzw. einer Anwendung das erste Zwischenprodukt innerhalb des Softwareentwicklungsprozesses ist, das auf Basis des ISO/IEC 9126-Standards bewertet werden kann (vgl. [ISIE2003a, S. 73]).

62

Bewertung von Softwarearchitekturen

3.2.3.5 Identifikation der Rangfolge der Qualitätsmerkmale Das Qualitätsmodell, das im ersten Teil des ISO/IEC 9126-Standards beschrieben wird, dokumentiert für die Qualitätsmerkmale bzw. Teilmerkmale keine Rangfolge, die spezifiziert, ob z. B. eine Erhöhung der Ausprägungen eines Teilmerkmals grundsätzlich als eine Verbesserung oder Verschlechterung interpretiert werden muss (vgl. [ISIE2001]). Diese Unterscheidung ist relevant, da die Teilmerkmale des Qualitätsmodells durchaus unterschiedliche Rangfolgen besitzen und eine Interpretation der Ausprägungen der Teilmerkmale erfordert, dass die Rangfolgen bekannt sind. So ist z. B. eine Erhöhung der Fehlertoleranz (vgl. [ISIE2001, S. 9]) grundsätzlich positiv zu bewerten, wohingegen eine Erhöhung des Zeitverhaltens (vgl. [ISIE2001, S. 10]) grundsätzlich als negativ zu bewerten ist. Darüber hinaus werden die unterschiedlichen Rangfolgen im Kontext der Entwicklung des Wissensmodells aus dem gleichen Grund benötigt (siehe Kapitel 1). Die drei technischen Berichte beschreiben innerhalb der Dokumentation einer Metrik indirekt die Rangfolge, indem in der Spalte „Interpretation des gemessenen Werts“ (vgl. Tabelle 3-1) erläutert wird, wie die Werte zu interpretieren sind. Die Inhalte der Spalte können verwendet werden, um eine entsprechende Rangfolge für die Teilmerkmale abzuleiten. Dabei ist zu beachten, dass die verschiedenen Metriken unterschiedliche Rangfolgen verwenden, da sie die Teilmerkmale des Qualitätsmodells aus unterschiedlichen Perspektiven betrachten. Das Teilmerkmal des Zeitverhaltens (time behaviour) enthält z. B. die externe Metrik der Antwortzeit (response time), die aus der Differenz zwischen der Zeit des Erhalts des Ergebnisses und der Zeit des Auslösens eines Befehls ermittelt wird (vgl. [ISIE2003a, S. 42]). Je kürzer die Antwortzeit eines Systems bzw. einer Anwendung ist, desto besser ist das Zeitverhalten. Darüber hinaus enthält das Teilmerkmal die Metrik des Durchsatzes (throughput), die ermittelt, wie viele Aufgaben innerhalb eines Zeitraums bearbeitet werden konnten (vgl. [ISIE2003a, S. 44]). Je mehr Aufgaben in einem bestimmten Zeitraum von einem System bzw. einer Anwendung verarbeitet werden können, desto besser ist das Zeitverhalten. Obwohl die verschiedenen Metriken unterschiedliche Rangfolgen aufweisen, können die unterschiedlichen Perspektiven der Metriken in einer grundsätzlichen Rangfolge des Teilmerkmals wie folgt konsolidiert werden: Das Zeitverhalten eines Systems bzw. einer Anwendung ist umso besser, je kürzer die Reaktionszeiten sind und je mehr Anfragen innerhalb einer Zeiteinheit verarbeitet werden können. Die Dokumentation der Rangfolge erfolgt in einer einfachen Textform und enthält die wesentlichen Dimensionen der Metriken eines Teilmerkmals. Die Rangfolgen, die in den Tabellen 3-2 und 3-3 dokumentiert sind, ergeben sich häufig direkt aus der Semantik der Teilmerkmale, jedoch wird diese Interpretation durch die Analyse der verschiedenen Metriken untermauert.

Qualität von Softwareprodukten und -architekturen

Qualitätsmerkmal Functionality (Funktionalität)

Reliability (Zuverlässigkeit)

Usability (Benutzbarkeit)

Teilmerkmal

63

Rangfolge

Suitability (Angemessenheit)

Je präziser und korrekter die Menge der Funktionen implementiert ist, desto besser ist die Angemessenheit.

Accuracy (Genauigkeit)

Je genauer und präziser die Funktionen implementiert sind, desto besser ist die Genauigkeit.

Interoperability (Interoperabilität)

Je korrekter die Funktionen zum Austausch von Daten und die Austauschformate implementiert sind, desto besser ist die Interoperabilität.

Security (Sicherheit)

Je vollständiger die Benutzerzugriffe auf das System und die Daten kontrolliert und protokolliert werden und je geringer die Häufigkeit von korrupten Daten ist, desto besser ist die Sicherheit.

Functionality compliance (Konformität bzgl. der Funktionalität)

Je mehr Regulierungen, Standards und Konventionen der Funktionalität eingehalten werden, desto besser ist die Konformität bzgl. der Funktionalität.

Maturity (Reife)

Je weniger Fehler in der Anwendung existieren, desto besser ist die Reife.

Fault tolerance (Fehlertoleranz)

Je weniger Ausfälle aufgrund von Fehlern in einer Anwendung auftreten, desto besser ist die Fehlertoleranz.

Recoverability (Wiederherstellbarkeit)

Je länger eine Anwendung verfügbar ist und je kürzer die Wiederanlaufzeiten bei einem Ausfall sind, desto besser ist die Wiederherstellbarkeit.

Reliability compliance (Konformität bzgl. der Zuverlässigkeit)

Je mehr Regulierungen, Standards und Konventionen der Zuverlässigkeit eingehalten werden, desto besser ist die Konformität bzgl. der Zuverlässigkeit.

Understandability (Verständlichkeit)

Je vollständiger die Produktdokumentation ist und je besser sich die Funktionen selbst erklären bzw. nachzuvollziehen sind, desto besser ist die Verständlichkeit.

Learnability (Erlernbarkeit)

Je vollständiger die Produktdokumentation bzw. die Hilfe-Funktion ist, desto besser ist die Erlernbarkeit.

Operability (Bedienbarkeit)

Je komfortabler und besser nachvollziehbar die Interaktion mit dem Produkt ist, desto besser ist die Bedienbarkeit.

Attractiveness (Attraktivität)

Je ansprechender und anpassbarer die Benutzeroberfläche des Produkts ist, desto besser ist die Attraktivität.

Usability compliance (Konformität bzgl. der Benutzbarkeit)

Je mehr Regulierungen, Standards und Konventionen der Benutzbarkeit eingehalten werden, desto besser ist die Konformität bzgl. der Benutzbarkeit.

Tabelle 3-2: Rangfolgen der Qualitätsmerkmale (Teil 1)

64

Qualitätsmerkmal Efficiency (Effizienz)

Maintainability (Wartbarkeit)

Portability (Übertragbarkeit)

Bewertung von Softwarearchitekturen

Teilmerkmal

Rangfolge

Time behaviour (Zeitverhalten)

Je kürzer die Reaktionszeiten sind und je mehr Anfragen innerhalb einer Zeiteinheit verarbeitet werden können, desto besser ist das Zeitverhalten.

Resource utilization (Verbrauchsverhalten)

Je weniger Ressourcen benötigt werden, desto besser ist das Verbrauchsverhalten.

Efficiency compliance (Konformität bzgl. der Effizienz)

Je mehr Regulierungen, Standards und Konventionen der Effizienz eingehalten werden, desto besser ist die Konformität bzgl. der Effizienz.

Analyzability (Analysierbarkeit)

Je leichter Fehler identifiziert und Auswirkungen von Änderungen bzgl. der Anforderungen analysiert werden können, desto besser ist die Analysierbarkeit.

Changeability (Veränderlichkeit)

Je leichter Fehler behoben oder Änderungen bzgl. der Anforderungen umgesetzt werden können, desto besser ist die Modifizierbarkeit.

Stability (Stabilität)

Je erfolgreicher Fehler behoben und Änderungen bzgl. der Anforderungen umgesetzt werden können und je weniger Seiteneffekte im Kontext dieser Aktivitäten auftreten, desto besser ist die Stabilität.

Testability (Prüfbarkeit)

Je einfacher die Ausführung von Tests ist, desto besser ist die Prüfbarkeit.

Maintainability compliance (Konformität bzgl. der Wartbarkeit)

Je mehr Regulierungen, Standards und Konventionen der Wartbarkeit eingehalten werden, desto besser ist die Konformität bzgl. der Wartbarkeit.

Adaptability (Anpassbarkeit)

Je einfacher eine Anwendung an andere Einsatzbedingungen (z. B. veränderte Hardware, Betriebssystem, organisatorische Einheiten, Benutzerzahlen) angepasst werden kann, desto besser ist die Anpassbarkeit.

Installability (Installierbarkeit)

Je einfacher eine Anwendung innerhalb einer Systemumgebung installiert werden kann, desto besser ist die Installierbarkeit.

Co-existance (Koexistenz)

Je weniger Einschränkungen sich bei dem Einsatz mit anderen Softwareprodukten innerhalb einer Systemumgebung ergeben, desto besser ist die Koexistenz.

Replaceability (Austauschbarkeit)

Je leichter eine Anwendung gegen eine andere Anwendung ausgetauscht werden kann bzw. Teile einer Anwendung durch andere Teile ausgetauscht werden können, desto besser ist die Austauschbarkeit.

Portability compliance (Konformität bzgl. der Übertragbarkeit)

Je mehr Regulierungen, Standards und Konventionen der Übertragbarkeit eingehalten werden, desto besser ist die Konformität bzgl. der Übertragbarkeit.

Tabelle 3-3: Rangfolgen der Qualitätsmerkmale (Teil 2)

Qualität von Softwareprodukten und -architekturen

65

3.2.3.6 Bewertung des Qualitätsmodells Der erste Teil des ISO/IEC 9126-Standards definiert als internationaler Standard eine einheitliche Terminologie für die Qualität von Softwareprodukten, die grundsätzlich positiv zu beurteilen ist, da sie die Kommunikation im Kontext der Softwareprodukt-Qualität wesentlich vereinfacht, indem ein homogenes Qualitätsmodell mit einer entsprechenden Semantik definiert wird. Weiterhin ist positiv hervorzuheben, dass durch das Qualitätsmodell ein Rahmen definiert wird, der zur Orientierung bei der Spezifikation von Qualitätsanforderungen und bei dem Vergleich von Softwareprodukten verwendet werden kann. Auf Basis dieses Rahmens kann die Vollständigkeit der Qualitätsanforderungen überprüft werden. Im Kontext eines Vergleichs von Softwareprodukten definiert der Rahmen einheitliche Kritierien, die einen strukturierten Vergleich unterstützen. Die Anwendung des Qualitätsmodells ist nicht auf das Softwareprodukt als Ganzes beschränkt, sondern die Bewertung von direkten und indirekten Zwischenprodukten ist ebenfalls möglich. Da die Softwarearchitektur ein Zwischenprodukt in diesem Sinn ist, kann das Qualitätsmodell zur Bewertung von Softwarearchitekturen verwendet werden (vgl. Kapitel 3.2.3.4). Nach einer Analyse der Vollständigkeit und Granularität des Qualitätsmodells ist kritisch anzumerken, dass insbesondere das Teilmerkmal der Sicherheit als eigenes Qualitätsmerkmal positioniert werden könnte, da die Softwareelemente von Anwendungen zunehmend verteilt werden und daher die sichere Übertragung und Verwaltung von Daten einen besonderen Stellenwert erhält. Darüber hinaus besitzt die Sicherheit einer Anwendung im Kontext der Nutzung im Intra- oder Internet einen besonderen Stellenwert. Weiterhin lässt sich das Qualitätsmerkmal der Sicherheit weiter verfeinern, indem auf Basis der Klassifikation von Sicherheitsdiensten, wie z. B. der Authentifikation, Vertraulichkeit oder Verbindlichkeit, entsprechende Teilmerkmale abgeleitet werden. In Bezug auf die Metriken, die in den drei technischen Berichten dokumentiert werden, ist kritisch zu beurteilen, dass diese nicht vollständig und nicht validiert worden sind (vgl. Kapitel 3.2.3.4). Insbesondere die Beziehungen zwischen den Metriken und die Rolle der Metriken als Indikator für die Teilmerkmale sind noch nicht vollständig bekannt bzw. verstanden, d. h., werden auf Basis der Metriken eines Teilmerkmals ausschließlich positive Werte ermittelt, so lässt sich hierdurch nicht unmittelbar auf die positive Ausprägung des Teilmerkmals schließen. Die Metriken können allerdings u. a. dazu verwendet werden, die grundsätzliche Rangfolge der Teilmerkmale abzuleiten, denn diese ist nicht Bestandteil des Qualitätsmodells (vgl. Kapitel 3.2.3.5). Weiterhin ist kritisch anzumerken, dass die Dokumentation der Metriken das Konzept des Kontexts nicht explizit berücksichtigt und daher die Formulierung von aussagekräftigen Anforderungen erschweren (vgl. Kapitel 3.2.2.3). Dem Teilmerkmal der Modifizierbarkeit sind z. B. verschiedene Metriken zugeordnet, die den Aufwand zur Behebung eines Problems bzw.

66

Bewertung von Softwarearchitekturen

Umsetzung einer Änderung aus verschiedenen Perspektiven messen. Die Probleme und Änderungen werden nicht weiter klassifiziert, so dass kein Bezug zu einem bestimmten Kontext entsteht, der die Anforderungen überprüfbar macht. Eine Anwendung kann z. B. in Bezug auf die Benutzeroberfläche leicht, aber in Bezug auf die Datenhaltung nur schwer modifizierbar sein (vgl. Kapitel 3.2.2.3). Bei der Anwendung des Qualitätsmodells innerhalb eines Softwareentwicklungsprozesses muss zwischen der Messung und Voraussage einer Metrik differenziert werden, denn Eigenschaften können erstmalig gemessen werden, wenn die entsprechenden Zwischenprodukte erstellt worden sind bzw. das Softwareendprodukt implementiert worden ist. Im anderen Fall müssen die Werte der Metriken auf Basis entsprechender Modelle und Methoden vorausgesagt werden. Diese Modelle und Methoden sind aber nicht im Standard enthalten. Er spezifiziert z. B. nicht, wie Komplexität der Modifizierbarkeit (vgl. [ISIE2003a, S. 56]) einer Anwendung bereits innerhalb der Entwurfsphase ermittelt werden kann.

3.2.4 Qualitätsmodell des Software Engineering-Instituts Die Arbeiten aus dem Umfeld des Software Engineering-Instituts basieren ebenfalls auf dem Konzept der Qualitätsmodelle (vgl. Kapitel 3.2.2). Bass, Clements und Kazman beschreiben innerhalb der Diskussion der Qualitätseigenschaften von Softwarearchitekturen Qualitätsmerkmale, Konzepte und Modelle (vgl. [BaCK2003]19), die u. a. von Clements, Kazman und Klein im Kontext der Bewertung von Softwarearchitekturen verwendet werden (vgl. [ClKK2002]). Diese werden nicht explizit als ein Qualitätsmodell bezeichnet, aber sie entsprechen dem in Kapitel 3.2.2 vorgestellten allgemeinem Konzept der Qualitätsmodelle. Aufgrund des besonderen Fokus auf die Softwarearchitektur sowie der weiterführenden Konzepte und Modelle, wird das Qualitätsmodell in der vorliegenden Arbeit detailliert vorgestellt. Insbesondere die von Bass, Clements und Kazman beschriebenen Konzepte und Modelle werden innerhalb der Entwicklung des Wissensmodells in Kapitel 5.1 wiederverwendet.

3.2.4.1 Anwendungsbereiche und Ziele Bei der Beschreibung der Qualitätsmerkmale, Konzepte und Modelle fokussieren sich Bass, Clements und Kazman ausschließlich auf die Ebene der Softwarearchitektur (vgl. [BaCK2003, S. 71 ff.]). Der Aspekt der Funktionalität wird im Gegensatz zum Qualitätsmodell des ISO/IEC 9126-Standards nicht berücksichtigt, d. h., es werden nur nicht-funktionale Anforderungen betrachtet. Das primäre Ziel des Modells ist die Spezifikation der Qualitätsanforderungen an ein System, so dass auf Basis dieser Anforderungen eine Bewertung der Soft19

Diese Referenz bezieht sich auf die zweite Auflage der Quelle und ist deshalb jünger als die Quelle von Clements, Kazman und Klein.

Qualität von Softwareprodukten und -architekturen

67

warearchitektur erfolgen kann (vgl. [BaCK2003, S. 72]). In diesem Kontext wurden weitere Konzepte und Modelle entwickelt, die insbesondere die Anwendbarkeit der Qualitätsmerkmale gewährleisten sollen (vgl. [BaCK2003, S. 74]). Clements, Kazman und Klein verwenden diese Konzepte und Modelle im Kontext der Bewertung von Softwarearchitekturen (vgl. [ClKK2002]).

3.2.4.2 Qualitätsmodell Das Qualitätsmodell von Bass, Clements und Kazman unterscheidet drei Klassen von Qualitätsmerkmalen (vgl. [BaCK2003, S. 74]): ƒ Qualitätsmerkmale des Systems (qualities of the system), ƒ betriebswirtschaftliche Qualitätsmerkmale (business qualities) und ƒ architektur-bezogene Qualitätsmerkmale (architecture quality).

Die Qualitätsmerkmale des Systems beziehen sich auf die Eigenschaften einer Anwendung bzw. eines Systems. Diese Klasse kann – mit Ausnahme der Funktionalität – mit den internen und externen Qualitätsmerkmalen des ISO/IEC 9126-Standards verglichen werden. Die Terminologie und Semantik der Merkmale sind jedoch unterschiedlich. Das Qualitätsmodell definiert keine Teilmerkmale, sondern beschränkt sich auf eine Hierarchie mit zwei Ebenen (siehe Abbildung 3-5).

Abbildung 3-5: Qualitätsmerkmale des Systems

Bass, Clements und Kazman beschreiben die Semantik der Merkmale, da eine Vielzahl von unterschiedlichen Definitionen und Taxonomien in diesem Umfeld existiert (vgl. [BaCK2003, S. 74]). Sie identifizieren die wesentlichen Konzepte, die im Kontext des jeweiligen Qualitätsmerkmals verwendet werden, ohne dabei andere Quellen zu referenzieren (vgl. [BaCK2003, S. 79 ff.]). Eine Positionierung und Abgrenzung zu anderen Taxonomien ist deshalb nicht möglich. Die einzigen Quellen, die bei der Beschreibung der Qualitätsmerkmale referenziert werden, sollen eine Vertiefung von einzelnen Merkmalen ermöglichen (vgl. [BaCK2003, S. 97]).

68

Bewertung von Softwarearchitekturen

Die betriebswirtschaftlichen Qualitätsmerkmale umfassen verschiedene Qualitätsmerkmale aus der Sicht eines Unternehmens und betrachten die Softwarearchitektur im Wesentlichen aus einer betriebswirtschaftlichen Perspektive, indem Aspekte wie die Kosten, der Markt und das Marketing analysiert werden (vgl. [BaCK2003, S. 95]). Diese Qualitätsmerkmale beeinflussen ebenfalls die Gestaltung der Softwarearchitektur (siehe Abbildung 3-6).

Abbildung 3-6: Betriebswirtschaftliche Qualitätsmerkmale

Im Gegensatz zu den Qualitätsmerkmalen des Systems werden diese Merkmale von Bass, Clements und Kazman nur knapp diskutiert und die Konzepte, die innerhalb jedes Merkmals verwendet werden, sind nicht so umfangreich, wie die Konzepte, die den Qualitätsmerkmalen des Systems zugrunde liegen (vgl. [BaCK2003, S. 95 f.]). Die architektur-bezogenen Qualitätsmerkmale sind direkt der Softwarearchitektur zuzuordnen (vgl. [BaCK2003, S. 96]). Sie beziehen sich auf die Eigenschaften der Softwarearchitektur als Ganzes (siehe Abbildung 3-7).

Abbildung 3-7: Architektur-bezogene Qualitätsmerkmale

Analog zu den betriebswirtschaftlichen Qualitätsmerkmalen werden die architektur-bezogenen Merkmale nur kurz diskutiert (vgl. [BaCK2003, S. 96 f.]). Insbesondere die zugrunde liegenden Konzepte und Modelle werden nicht erwähnt. Es ist jedoch anzumerken, dass derartige Konzepte und Modelle im Bereich der Softwarearchitekturen z. Z. noch Gegenstand der Forschung sind (vgl. [ShCl2006a; ShCl2006b; Shaw2001]).

Qualität von Softwareprodukten und -architekturen

69

3.2.4.3 Modell der Qualitätsmerkmal-Szenarios Das Modell der Qualitätsmerkmal-Szenarios entstand ursprünglich im Kontext der sog. Software Architecture Analysis-Methode (SAAM) (vgl. [KBAW1994; KABC1996]), die erste am Software Engineering-Institut dokumentierte und veröffentlichte Methode zur Bewertung von Softwarearchitekturen (vgl. [ClKK2002, S. 211]). Bei der Entwicklung der Methode identifizierten Kazman, Bass, Abowd und Webb die Problematik, dass bestimmte Behauptungen bezüglich der Qualitätsmerkmale von Softwarearchitekturen nicht überprüfbar waren (vgl. [KBAW1994]). Diese Problematik entsteht dadurch, dass die Behauptungen keine aussagekräftigen Anforderungen darstellen (vgl. Kapitel 3.2.2.3), die die Grundlage für eine Überprüfung bilden. Sie entwickelten deshalb das Modell der Qualitätsmerkmal-Szenarios als einen neuen Rahmen für die Formulierung von Qualitätsanforderungen (vgl. [ClKK2002, S. 111]). Dieser Rahmen soll bei der Spezifikation der Anforderungen verwendet werden und insbesondere die Problematik der nicht aussagekräftigen bzw. überprüfbaren Qualitätsmerkmale lösen (vgl. [BaCK2003, S. 72, 74]). Der Rahmen, der die Grundlage für die Spezifikation einer Anforderung bildet, besteht aus den folgenden sechs Teilen (vgl. [BaCK2003, S. 75]): ƒ Quelle des Stimulus: Eine Entität, wie z. B. ein Mensch oder ein IT-System, die einen

Stimulus generiert. ƒ Stimulus: Ein Impuls, der innerhalb des Systems beachtet werden muss. ƒ Umgebung: Der Stimulus trifft auf ein System, das sich in einem bestimmten Zustand

befindet. ƒ Artefakt: Innerhalb der Umgebung trifft der Stimulus auf ein bestimmtes Artefakt.

Dieses Artefakt kann das ganze System sein oder sich nur auf Teile davon beziehen. ƒ Reaktion: Die Reaktion ist die Aktivität, die beim Eintreffen des Stimulus ausgeführt

wird. ƒ Ausmaß der Reaktion: Die Reaktion auf das Eintreffen des Stimulus soll messbar sein,

damit die Anforderung überprüfbar ist. Die Spezifikation einer Anforderung muss nicht zwangsweise alle sechs Teile enthalten (vgl. [BaCK2003, S. 76]). Die verbindlichen Teile ergeben sich aus der Art und Weise, wie ein Szenario verwendet und überprüft wird. Ist z. B. der Zustand des Systems zur Validierung einer Anforderung nicht relevant, muss die Umgebung nicht zwangsweise spezifiziert werden.

70

Bewertung von Softwarearchitekturen

Abbildung 3-8 zeigt den Aufbau des Modells und die Beziehungen zwischen den sechs Teilen des Rahmens20.

Abbildung 3-8: Modell der Qualitätsmerkmal-Szenarios Quelle: in Anlehnung am [BaCK2003, S. 75]

Die Quelle des Stimulus, der Stimulus, das Artefakt, die Umgebung und die Reaktion definieren einen Kontext, der die Definition und Überprüfung von aussagekräftigen Anforderungen ermöglicht (vgl. Kapitel 3.2.2.3). Auf Basis des Modells können zwei grundsätzliche Klassen von Szenarios erstellt werden: allgemeine Szenarios (general scenarios) und konkrete Szenarios (concrete scenarios) (vgl. [BaCK2003, S. 75]). Allgemeine Szenarios sind unabhängig von einer Anwendung bzw. einem System und können sich potenziell auf mehrere Anwendungen bzw. Systeme beziehen. Sie beschreiben die grundlegende Richtung und das wesentliche Ausmaß einer Reaktion in Bezug auf ein Qualitätsmerkmal. Ein konkretes Szenario dagegen stellt den Bezug zu einer bestimmten Anwendung bzw. einem bestimmten System her. Es verfeinert die einzelnen Teile des Szenarios und verfeinert insbesondere das Ausmaß der Reaktion, das innerhalb der Bewertung überprüft werden kann. Innerhalb der Anforderungsanalyse der nicht-funktionalen Anforderungen spielen die konkreten Szenarios die gleiche Rolle wie sog. Use Cases21 innerhalb der Spezifikation der funktionalen Anforderungen (vgl. [BaCK2003, S. 78]). In Bezug auf das Konzept der Qualitätsmodelle verfeinern die Szenarios die Anforderungen zu aussagekräftigen und überprüfbaren Aussagen, indem sie auf Basis des definierten Rahmens einen Kontext spezifizieren, der bei der Interpretation der Ergebniswerte eines Indikators bzw. einer Metrik berücksichtigt werden muss (siehe Abbildung 3-9).

20

21

Wenn es sich bei der Entität um ein IT-System handelt, ist das von Bass, Clements und Kazmann gewählte Symbol des Männchens eher irritierend. Es liegt aber die Vermutung nahe, dass Bass, Clements und Kazmann das Symbol in Anlehnung an die UML entworfen haben, die ein Strichmännchen als Symbol für einen sog. Akteur (actor) verwendet. Ein Akteur ist im Kontext der UML als eine Rolle zu verstehen, die sowohl von einem Menschen als auch von einem IT-System gespielt werden kann (siehe [OMG2005a, S. 570 ff.]). Use Cases sind im Kontext der UML ein Konzept zur Spezifikation der Art und Weise, wie ein System genutzt werden soll (vgl. [OMG2005a, S. 641 ff.]).

Qualität von Softwareprodukten und -architekturen

71

Darüber hinaus fördert das Modell das Verständnis der Wirkungszusammenhänge innerhalb der Softwarearchitektur und unterstützt dadurch die Voraussage von Reaktionen sowie Ergebniswerten der Indikatoren bzw. Metriken (siehe Abbildung 3-9, Pfeil 1)

Abbildung 3-9: Positionierung des Modells der Qualitätsmerkmal-Szenarios Quelle: in Anlehnung am [BaCK2003, S. 75]

Diese sind insbesondere relevant, wenn die zu bewertenden (Zwischen-) Produkte noch nicht erstellt bzw. implementiert worden sind (vgl. Kapitel 3.2.2.3). Das Modell unterstützt somit auch den Entwurf von Softwarearchitekturen im Hinblick auf spezifizierte Qualitätsanforderungen.

3.2.4.4 Erstellung von Szenarios Neben dem Modell der Qualitätsmerkmal-Szenarios beschreiben Bass, Clements und Kazman wie im Kontext der Anforderungsanalyse Szenarios erstellt werden (vgl. [BaCK2003, S. 78]). Da in der Praxis die Qualitätsanforderungen i. d. R. nicht so detailliert, wie im Modell vorgesehen, spezifiziert werden, soll der Architekt bei der Erhebung von aussagekräftigen Anforderungen weiter unterstützt werden. Bass, Clements und Kazman definieren dafür sog. qualitätsmerkmal-spezifische Tabellen (quality-attribute-specific tables), die für alle Qualitätsmerkmale des Systems (vgl. Abbildung 3-5) die wesentlichen Ausprägungen der sechs Teile eines Szenarios identifizieren und beschreiben. Sie werden verwendet, um generelle Szenarios zu erstellen, die keinen Bezug zu einem bestimmten System haben und lediglich die grundlegende Richtung und das wesentliche Ausmaß der Reaktion in Bezug auf das Qualitätsmerkmal beschreiben (vgl. Kapitel 3.2.4.3).

72

Bewertung von Softwarearchitekturen

Tabelle 3-4 zeigt – stellvertretend für die von Bass, Clements und Kazman dokumentierten qualitätsmerkmal-spezifischen Tabellen – die Tabelle für das Merkmal der Modifizierbarkeit (modifiability).

Teil des Szenarios

Mögliche Ausprägungen

Quelle des Stimulus

Benutzer, Entwickler, Administrator

Stimulus

Möchte Funktionalität, Qualitätsmerkmale und/oder Kapazität hinzufügen, löschen, ändern und/oder variieren

Artefakt

Benutzeroberfläche, Plattform, Umgebung

Umgebung

Zur Entwurfszeit, Entwicklungszeit, Übersetzungszeit, Laufzeit

Reaktion

Die anzupassenden Stellen innerhalb der Softwarearchitektur werden lokalisiert; die Änderungen durchgeführt, ohne dass andere Funktionen beeinflusst werden; die Änderungen werden getestet und installiert.

Ausmaß der Reaktion

Kosten in Bezug auf die beeinflussten Elemente; Aufwand für die Durchführung; Ausmaß, in dem die Qualitätsmerkmale anderer Funktionen beeinflusst werden

Tabelle 3-4: Beispiel für eine qualitätsmerkmal-spezifische Tabelle Quelle: in Anlehnung an [BaCK2003, S. 83]

Die Tabellen stellen keinen expliziten Mechanismus zur Erstellung von Szenarios dar; sie dienen primär zur Überprüfung, ob alle Kombinationen der Bestandteile eines Szenarios berücksichtigt worden sind (vgl. [BaCK2003, S. 78]). Sie erheben keinen Anspruch auf Vollständigkeit bezüglich der Menge der möglichen Ausprägungen. Die generellen Szenarios werden erstellt, indem für jedes Teil eines Szenarios eine Ausprägung selektiert wird. Abbildung 3-10 zeigt beispielhaft ein generelles Szenario für das Qualitätsmerkmal der Modifizierbarkeit, das auf Basis der Tabelle 3-4 erstellt wurde.

Abbildung 3-10: Beispiel für ein generelles Szenario

Die Dokumentation der Szenarios ist nicht auf das Format beschränkt, das in der Abbildung 3-10 ausgewählt wurde. Szenarios können z. B. auch in Tabellen- oder Textform dokumentiert werden. Die generellen Szenarios dienen insbesondere der Orientierung innerhalb der

Qualität von Softwareprodukten und -architekturen

73

Anforderungsanalyse, indem z. B. die Anforderungen ausgehend von diesen Szenarios erhoben werden. Auf Basis der generellen Szenarios können für einen bestimmten Anwendungsfall konkrete Szenarios erstellt werden, indem die einzelnen Ausprägungen in Bezug auf das System bzw. die Anwendung weiter verfeinert werden und schließlich die spezifischen Anforderungen des Systems darstellen. Auf Basis eines einzelnen generellen Szenarios können ein oder mehrere konkrete Szenarios erstellt werden. Die Abbildung 3-11 stellt beispielhaft ein abgeleitetes konkretes Szenario dar.

Abbildung 3-11: Beispiel für ein konkretes Szenario

Ein konkretes Szenario ist auf Basis des Modells so detailliert beschrieben, dass es innerhalb des Entwurfs bzw. der Bewertung als aussagekräftige Anforderung verwendet werden kann. Das Szenario der Abbildung 3-11 kann auch in der Textform wie folgt dokumentiert werden: Ein Entwickler möchte die Benutzeroberfläche der Kundenstammdatenmaske zur Entwicklungszeit um neue Kontaktdaten erweitern. Er benötigt weniger als 3 Manntage, um die Oberflächenbeschreibung der Maske um die neuen Kontaktdaten zu erweitern und die Änderungen zu testen. Die Unterstützung der Erstellung von Szenarios durch entsprechende qualitätsmerkmal-spezifische Tabellen erfolgt lediglich für die Qualitätsmerkmale des Systems. Für die Klassen der betriebswirtschaftlichen und architektur-bezogenen Qualitätsmerkmale (vgl. Kapitel 3.2.4.2) werden von Bass, Clements und Kazman keine entsprechenden Tabellen erstellt.

3.2.4.5 Bewertung des Qualitätsmodells Das Qualitätsmodell, das von Bass, Clements und Kazman im Umfeld des Software Engineering-Instituts beschrieben wird, fokussiert ausschließlich die Abstraktionsebene der Softwarearchitektur. Dieser spezielle Fokus spiegelt sich in den Qualitätsmerkmalen und deren Konzepten wider, die ausgehend von drei Klassen von Merkmalen dokumentiert werden.

74

Bewertung von Softwarearchitekturen

Aufgrund dieses spezialisierten Qualitätsmodells lässt sich das Modell nicht direkt mit dem ISO/IEC 9126-Qualitätsmodell vergleichen. Es ist aber festzuhalten, dass das Modell des ISO/IEC 9126-Standards eine feinere Klassifikation der Qualitätsmerkmale auf Basis von drei Ebenen bietet (vgl. Kapitel 3.2.3.3) und eine größere Menge von Qualitätsbegriffen innerhalb des Modells definiert. Bass, Clements und Kazman dagegen definieren keine Teilmerkmale innerhalb des Modells. Einige im Kontext der Qualität benutzte Qualitätsbegriffe, die nicht in ihrem Modell enthalten sind, werden explizit innerhalb des eigenen Modells eingeordnet, um Unklarkeiten und Missverständnisse zu vermeiden (vgl. [BaCK2003, S. 78]). Diese Positionierungen sind aber sehr knapp gehalten, so dass u. U. nicht alle geläufigen Qualitätsbegriffe in ihrem Modell eingeordnet werden können. Die Konzepte und Modelle, die einem Merkmal zugrunde liegen, sind aber, insbesondere für die Qualitätsmerkmale des Systems, wesentlich detaillierter erläutert als die Beschreibungen im ISO/IEC 9126-Standard. Darüber hinaus ermöglicht das Modell der QualitätsmerkmalSzenarios in Verbindung mit dem Konzept des Kontexts – im Gegensatz zum ISO/IEC 9126Qualitätsmodell (vgl. Kapitel 3.2.3.6) – die Spezifikation von aussagekräftigen und überprüfbaren Anforderungen. Die qualitätsmerkmal-spezifischen Tabellen, die für jedes Qualitätsmerkmal des Systems dokumentiert werden, unterstützen – in Kombination mit dem Konzept der generellen und konkreten Szenarios – die Erstellung von Qualitätsanforderungen. Entsprechende Metriken, die zur Überprüfung der Szenarios verwendet werden könnten, werden – im Gegensatz zum ISO/IEC 9126-Qualitätsmodell – nicht betrachtet. Dementsprechend werden – analog zum ISO/IEC 9126-Qualitätsmodell – auch keine Modelle und Methoden definiert, die eine Voraussage von Ergebniswerten unterstützen, obwohl Bass, Clements und Kazman in diesem Kontext explizit zwischen quantitativen und qualitativen Metriken differenzieren. Die Erstellung von Szenarios für die betriebswirtschaftlichen und architektur-bezogenen Qualitätsmerkmale wird von Bass, Clements und Kazman nicht weiter betrachtet. Insbesondere werden für diese Qualitätsmerkmale keine qualitätsmerkmal-spezifischen Tabellen als Grundlage für die Erstellung der Szenarios dokumentiert.

3.3

Bewertungsmethoden für Softwarearchitekturen

Die Bewertung einer Softwarearchitektur erfordert die systematische Analyse der Beziehungen zwischen den Entwurfsentscheidungen innerhalb der Architektur und deren Auswirkungen auf die Qualitätsmerkmale eines Systems (vgl. Kapitel 3.1). Zur Strukturierung dieses Analyseprozesses wurden sog. Bewertungsmethoden für Softwarearchitekturen entwickelt,

Bewertungsmethoden für Softwarearchitekturen

75

die die Untersuchung, das Verständnis und die Bewertung dieser Beziehungen durch entsprechende Konzepte, Modelle und Vorgehensweisen unterstützen. In Kapitel 3.3.1 werden die wesentlichen existierenden Bewertungsmethoden im Überblick dargestellt und die Beziehungen zwischen den Methoden analysiert. Zur Verdeutlichung der Konzepte, Modelle und Vorgehensweisen einer derartigen Bewertungsmethode wird in Kapitel 3.3.2 die sog. Architecture Tradeoff Analysis-Methode vorgestellt. Diese Methode wurde zur detaillierten Diskussion ausgewählt, da sie in der Wissenschaft und Praxis vergleichsweise weit verbreitet ist (siehe Kapitel 3.3.1.4). Sie enthält darüber hinaus Konzepte und Modelle, die bei der Entwicklung des Wissensmodells und der Vorgehensweise wiederverwendet werden (siehe Kapitel 1).

3.3.1 Überblick der existierenden Bewertungsmethoden In der Wissenschaft und Praxis wurde eine Vielzahl von Bewertungsmethoden für Softwarearchitekturen entwickelt, die unterschiedliche Anforderungen, Schwerpunkte und Ziele besitzen. Die Vielzahl der vorhandenen Methoden und deren unterschiedliche Eigenschaften waren die Motivation für mehrere Arbeiten, die durch den Vergleich auf Basis von bestimmten Kriterien, eine ausgewählte Menge von Bewertungsmethoden gegenübergestellt haben. Clements, Kazman und Klein haben einen Vergleich der am Software Engineering-Institut entwickelten Bewertungsmethoden auf Basis von fünf Kriterien durchgeführt (siehe [ClKK2002, S. 255 ff.]). Andere Methoden, die außerhalb des SEI entwickelt worden sind, werden aber nicht berücksichtigt. Dobrica und Niemelä haben eine Klassifizierung entwickelt, in der sie insgesamt acht Bewertungsmethoden gegenübergestellt haben (siehe [DoNi2002]). Insgesamt wurden sieben Kriterien identifiziert, wobei nur vier Kriterien zur Klassifizierung der Bewertungsmethoden verwendet werden (vgl. [DoNi2002, S. 648 f.]). Ali Babar, Zhu und Jeffrey haben auf der Basis der zuvor genannten Arbeiten einen Vergleich von acht Bewertungsmethoden durchgeführt und hierzu fünfzehn Kriterien verwendet (siehe [AlZJ2004]). Das Ziel des Vergleichs war eine ausführliche Beschreibung der Merkmale einer Methode und die Erfassung der Aspekte einer Methode, die im Allgemeinen bekannt, jedoch nur unzureichend oder informell beschrieben worden sind (vgl. [AlZJ2004, S. 309 f.]). Mit Ausnahme der szenario-spezifischen Kriterien sind alle Kriterien von Dobrica und Niemelä auch in diesem Vergleich zu finden. Ali Babar, Zhu und Jeffrey verwenden zehn weitere Kriterien, wie z. B. das Ziel und die Prozessunterstützung der Methode (vgl. [AlZJ2004, S. 310 ff.]). Der unterschiedliche Umfang und die variierenden Vergleichskriterien erschweren den Überblick über die Eigenschaften der existierenden Methoden. Darüber hinaus wird durch diese Arbeiten die strukturierte Auswahl einer geeigneten Bewertungsmethode nicht unterstützt

76

Bewertung von Softwarearchitekturen

(vgl. [EiHM2007]). Aus diesem Grund wird in der vorliegenden Arbeit auf die Beziehungen zwischen den einzelnen Methoden zurückgegriffen, die von Eicker, Hegmanns und Malich auf Basis der zuvor genannten Arbeiten und den Originalquellen identifiziert wurden (vgl. [EiHM2007]). Die Beziehungen ermöglichen einen konsolidierten Überblick über die Bewertungsmethoden, indem die wesentlichen Teilaspekte der Methoden betrachtet werden. Darüber hinaus kann die Auswahl der Architecture Tradeoff Analysis-Methode, die in dem folgenden Kapitel 3.3.2 dargestellt wird, aufgrund der besonderen Positionierung der Methode begründet werden. Innerhalb einer Literaturanalyse wurden von Eicker, Hegmanns und Malich achtzehn Methoden für die Bewertung von Softwarearchitekturen untersucht (vgl. [EiHM2007]). Zur Analyse der Beziehungen zwischen den Bewertungsmethoden wurden zwei grundsätzliche Beziehungstypen identifiziert: die Assoziation und die Vererbung (vgl. [EiHM2007]). Die Assoziation beschreibt, dass lediglich einige Teilaspekte einer Methode in einer anderen Methode eingeflossen sind und durch die Kombination von mehreren Teilaspekten eine neue, eigenständige Methode entstanden ist. Die Vererbung beschreibt dagegen eine Spezialisierung, bei der der Charakter der vererbenden Methode weitestgehend erhalten bleibt und nur wenige Teilaspekte modifiziert bzw. erweitert wurden.

3.3.1.1 Assoziationen zwischen den Methoden Der Beziehungstyp der Assoziation konnte zwischen sechs Methoden identifiziert werden und wird in Abbildung 3-12 im Überblick dargestellt. Die Beschriftungen der Verbindungen beschreiben die Teilaspekte, die jeweils innerhalb der assoziierten Methode übernommen worden sind. Die kursiven Beschriftungen neben den Methoden identifizieren die innerhalb einer Methode neu entwickelten Konzepte und Modelle. Die sog. Software Architecture Analysis-Methode (vgl. [KBAW1994; KABC1996]) ist die erste am Software Engineering-Institut entwickelte und dokumentierte Bewertungsmethode für Softwarearchitekturen (vgl. [ClKK2002, S. 211]). Innerhalb der Entwicklung der Methode wurde auch das Modell der Qualitätsmerkmal-Szenarios entwickelt, das bereits in Kapitel 3.2.4.3 vorgestellt wurde. Die SAAM bildete die Grundlage für die Entwicklung der Architecture Tradeoff AnalysisMethode, die ebenfalls am SEI entwickelt wurde (vgl. [ClKK2002, S. 43 f.]). Diese Bewertungsmethode stellt eine Assoziation zur SAAM dar, da bei der Entwicklung der ATAM auf Analyseverfahren und -techniken der SAAM zurückgegriffen wurde (siehe Abbildung 3-12). Die ATAM ist allerdings als eine eigenständige, neue Methode zu betrachten, da die Beziehungen zwischen den Entwurfsentscheidungen und den beeinflussten Qualitätsmerkmalen

Bewertungsmethoden für Softwarearchitekturen

77

wesentlich detaillierter untersucht werden und neue Konzepte, wie die sog. Sensitivity und Tradeoff Points sowie der Utility-Baum, entwickelt wurden (vgl. [EiHM2007]).

SAAM

QualitätsmerkmalSzenarios

Utility-Baum, Sensitivity und Tradeoff Points

QualitätsmerkmalSzenarios, ausgewählte Aktivitäten Kostenmodell, ROI

CBAM

QualitätsmerkmalSzenarios

ATAM

Qualitätsmerkmalszenarios ScoringModell

SBAR

Iterationen,Simulationen, mathematische Modelle

Qualitätsmerkmalszenarios

SACAM

Active Design Reviews

ARID

Abbildung 3-12: Assoziationen zwischen den Bewertungsmethoden Quelle: [EiHM2007]

Die sog. Cost Benefit Analysis-Methode (CBAM) betrachtet neben den Qualitätsmerkmalen innerhalb der Analyse auch wirtschaftliche Aspekte einer Softwarearchitektur (vgl. [KaAK2001]). Sie stellt eine Assoziation zur ATAM dar, da lediglich ausgewählte Aktivitäten der ATAM verwendet werden, um darauf basierend eine Analyse hinsichtlich der wirtschaftlichen Auswirkungen der Entwurfsentscheidungen durchzuführen (vgl. [BaCK2003, S. 310]). Für diese Methode wurde das Modell der Qualitätsmerkmal-Szenarios erweitert, um die Auswirkungen und Relevanz der Entwurfsentscheidungen innerhalb der Softwarearchitektur zu analysieren und zu fixieren. Die Relevanz wird verwendet, um auf Basis eines Kostenmodells den sog. Return on Investment (ROI) zu bestimmen, der das Verhältnis der Relevanz der Entwurfsentscheidungen zu den Kosten der Implementierung reflektiert (vgl. [BaCK2003, S. 310-316]). Eine weitere Bewertungsmethode aus dem Umfeld des Software Engineering-Instituts ist die sog. Software Architecture Comparison Analysis-Methode (SACAM), die für den Vergleich von mehreren Architekturalternativen verwendet werden kann (vgl. [StBV2003]). Sie stellt eine Assoziation zur ATAM dar, weil das Modell der Qualitätsmerkmals-Szenarios die Grundlage für den Vergleich von verschiedenen Softwarearchitekturen bildet. Die Szenarios werden bei SACAM „Kriterien“ genannt und mit Werten erweitert, die den Grad der Erfüllung eines Szenarios widerspiegeln. Auf Basis dieses Grads werden potenzielle Softwarearchitekturen verglichen, was innerhalb der SACAM „Architektur-Scoring“ genannt wird (vgl. [StBV2003, S. 21 f.]). Die SACAM ist eine eigenständige Methode, da lediglich das Modell der Qualitätsmerkmal-Szenarios wiederverwendet und erweitert wird. Daneben wur-

78

Bewertung von Softwarearchitekturen

den innerhalb der Methode neue Konzepte, wie z. B. Taktiken und Metriken, entwickelt, die in dieser Form nicht in anderen Bewertungsmethoden enthalten sind (vgl. [StBV2003, S. 20]). Die sog. Active Reviews for Intermediate Design (ARID) stellen eine weitere Assoziation der ATAM dar (vgl. [Clem2000; ClKK2002, S. 241 ff.]). Das Modell der QualitätsmerkmalSzenarios wurde innerhalb der Methode mit den sog. Active Design Reviews (ADR) von Parnas und Weiss (vgl. [PaWe1985]) kombiniert, weshalb Clements die ARID-Methode als ADR/ATAM-Hybrid beschreibt (vgl. [Clem2000, S. 13]). Die Methode ist ausschließlich für die Bewertung von Teilentwürfen einer Architektur innerhalb der frühen Entwicklungsphase konzipiert. Die sog. Scenario-Based Architecture Reengineering-Methode (SBAR) basiert ebenfalls auf dem Modell der Qualitätsmerkmal-Szenarios. Sie stellt aus diesem Grund eine Assoziation zur SAAM dar. Zusätzlich werden weitere Analysetechniken, wie z. B. mathematische Modelle und Simulationen, verwendet, die nicht Bestandteil der SAAM sind. Die Auswahl der Analysetechnik erfolgt in Abhängigkeit von dem zu analysierenden Qualitätsmerkmal (vgl. [DoNi2002]). Im Gegensatz zur SAAM sieht die SBAR-Methode innerhalb der Bewertung mehrere Iterationen vor und berücksichtigt – analog zur ATAM – mehrere Qualitätsmerkmale gleichzeitig (vgl. [AlZJ2004]).

3.3.1.2 Vererbungen zwischen den Methoden Der Beziehungstyp der Vererbung konnte in sieben Fällen bezüglich der SAAM und in einem Fall bezüglich der ATAM identifiziert werden (siehe Abbildung 3-13).

Abbildung 3-13: Vererbungen der Software Architecture Analysis- und der Architecture Tradeoff Analysis-Methode Quelle: [EiHM2007]

Da bei einer Spezialisierung der wesentliche Charakter der vererbenden Methode erhalten bleibt und nur wenige Teilaspekte verändert bzw. erweitert werden, werden die einzelnen Bewertungsmethoden im Folgenden nicht detailliert diskutiert.

Bewertungsmethoden für Softwarearchitekturen

79

Die identifizierten Spezialisierungen werden jedoch mit einer kurzen Beschreibung in Tabelle 3-5 zusammengefasst.

Bewertungsmethode

Beschreibung der Spezialisierung

Software Architecture Analysis Method for Complex Scenarios (SAAMCS)

Das Ziel dieser Methode ist die Flexibilität eines Systems zu bewerten (vgl. [LaRV1999]). Die Komplexität bei den Szenarios bezieht sich dabei auf die Schwierigkeit der Realisierung des jeweiligen Szenarios.

Extending SAAM by Integration in the Domain (ESAAMI) / Integrating SAAM in Domain-centric and Reuse-based Development Processes (ISAAMCR)

Der Unterschied zur SAAM besteht darin, dass die Evaluation um Aspekte der Wiederverwendung erweitert ist, d. h., es werden spezielle Szenarios mit einem Fokus auf die Wiederverwendung entwickelt (vgl. [Molt1999, S. 4]).

Software Architecture Analysis Method for Evolution and Reusability (SAAMER)

Die SAAMER ist eine Spezialisierung mit dem Fokus auf die beiden Qualitätsmerkmale „Evolution“ und „Wiederverwendung“ (vgl. [LBKK1997]). Der eigentliche Ablauf der SAAM bleibt jedoch erhalten.

Familiy Architecture AssessmentMethode (FAAM)

Das Ziel der FAAM ist die Evaluation von Informationssystemen, indem die strategischen Aspekte von ganzen Klassen (Familien) von Systemen berücksichtigt werden. Der Fokus bei der Evaluation liegt dabei auf den Qualitätsmerk-malen der „Interoperabilität“ und der „Erweiterbarkeit“. Die Methode basiert auf der SAAM und setzt die gleiche Evaluationstechnik ein (vgl. [Thie2005, S. 65]).

Architecture Level Prediction of Software Maintenance (ALPSM)

Die ALPSM-Methode stellt eine Spezialisierung der SAAM dar, da sie ein System auf der Architekturebene im Hinblick auf das Qualitätsmerkmal der „Wartbarkeit“ evaluiert. Der SAAM-Einfluss ist nicht explizit formuliert; er ist jedoch an den Merkmalen des Ablaufs, der Generierung von sog. Change Cases und der Architekturbeschreibung erkennbar (vgl. [DoNi2002, S. 647]).

Performance Assessment of Software Architecture (PASA)

Die PASA-Methode ist eine Anpassung der SAAM-Methode auf das Qualitätsmerkmal der „Performanz“, insbesondere der „Skalierbarkeit“ und „Ansprechbarkeit“. Auch der typische Verlauf einer szenario-basierten Evaluation ist bei PASA erkennbar (vgl. [Thie2005, S. 63 f.]), weshalb PASA als SAAMSpezialisierung klassifiziert wird.

Architecture-Level Modifiability Analysis (ALMA)

Die ALMA-Methode ist eine Methode, die auch auf dem Modell der Qualitätsmerkmal-Szenarios basiert. Darüber hinaus weist sie ein sehr ähnliches Vorgehensmodell wie die SAAM auf. Sie fokussiert sich dabei auf die „Modifizierbarkeit“, berücksichtigt jedoch nicht den Aspekt der „Wartung“ (vgl. [BLBV2004, S. 130]).

Quality Attribute Workshop (QAW)

Die QAW-Methode basiert auf der ATAM (vgl. [BELS2003]). Sämtliche Techniken der QAW-Methode sind Teil der ATAMMethode. Beim Verlauf wird deutlich, dass die QAW nur die letzten beiden Phasen einer ATAM-Evaluation, d. h. die sog. Testing- und Reporting-Phase, beschreibt (vgl. [ClKK2002, S. 45, S. 59-70]).

Tabelle 3-5: Beschreibung der Spezialisierung der Software Architecture Analysis- und der Architecture Tradeoff Analysis-Methode

80

Bewertung von Softwarearchitekturen

3.3.1.3 Eigenständige Methoden Vier der achtzehn untersuchten Methoden stellen eigenständige Entwicklungen dar, d. h., sie basieren auf keiner anderen Bewertungsmethode oder -technik und vererben keine Teilaspekte an andere Methoden (siehe Abbildung 3-14).

Abbildung 3-14: Unabhängige Bewertungsmethoden

Die sog. Attribute-Based Architectural Styles (ABAS) stellen keine Bewertungsmethoden im engeren Sinn dar, sondern ein Konzept, das die Dokumentation der Beziehungen zwischen einer Entwurfsentscheidung und einem Architektur-Stil (vgl. [PeWo1992; ShGa1996, S. 19 ff.]) ermöglicht und die Formulierung bzw. Überprüfung von Aussagen bezüglich der Auswirkungen auf ein Qualitätsmerkmal unterstützt (vgl. [KlKa1999; ClKK2002, S. 124 f.]). Hierdurch soll der Entwurf und die Bewertung einer Softwarearchitektur unterstützt werden (vgl. Kapitel 2.6.1). Die sog. Architecture Quality Assessment-Methode (AQA) basiert ausschließlich auf Metriken und Maßen (vgl. [HiKL1997]). Die Methode definiert sechs eigene Qualitätsmerkmale (“understandability”, “feasibility”, “openness”, “maintainability”, “evolvability” und “client satisfaction”) und ordnet diesen über 200 Maße zu, die auf Basis von Fragen überprüft werden. Die sog. Software Architecture Evaluation-Methode (SAE) wurde 1993 innerhalb des Telekommunikationsunternehmens AT&T für die Bewertung von Softwarearchitekturen entwickelt und basiert auf Fragen und Checklisten, die innerhalb der Bewertung beantwortet bzw. abgearbeitet werden (vgl. [Thie2005, S. 59 f.]). Das sog. Software Architecture Evaluation Model (SAEM) basiert auf Metriken, die aus dem ISO/IEC 9126-Standard (vgl. Kapitel 3.2.3) abgeleitet worden sind und eine Überprüfung der Anforderungen ermöglichen sollen (vgl. [DoNi2002]). Die Bewertung der Softwarearchitektur besteht im Wesentlichen aus einer Analyse der durch die Anwendung der Metriken ermittelten Daten und dem Wissen der entsprechenden Experten.

3.3.1.4 Positionierung und Auswahl der Architecture Tradeoff AnalysisMethode Die Untersuchung der Assoziationen und Vererbungen zwischen den Bewertungsmethoden hat gezeigt, dass zwei Methoden im Mittelpunkt der Entwicklungen stehen: die Software Architecture Analysis-Methode und die Architecture Tradeoff Analysis-Methode. Eine Analyse der Assoziationen verdeutlicht, dass insbesondere das Modell der Qualitätsmerkmal-Sze-

Bewertungsmethoden für Softwarearchitekturen

81

narios in vielen anderen Methoden übernommen wurde. Die ATAM, die als Nachfolger der SAAM am Software Engineering-Institut entwickelt worden ist (vgl. [ClKK2002, S. 43 f.]), basiert im Kern auf dem Modell der Qualitätsmerkmal-Szenarios und kombiniert dieses mit weiteren Konzepten und Modellen sowie einer Vorgehensweise. Die zahlreichen Spezialisierungen der SAAM zeigen, dass das Modell der Qualitätsmerkmal-Szenarios der SAAM von vielen anderen Bewertungsmethoden übernommen und darüber hinaus nur wenige Teilaspekte geändert bzw. erweitert wurden. Weiterhin werden die SAAM und die ATAM als ausgereifte und validierte Bewertungsmethoden klassifiziert (vgl. [EiHM2007; DoNi2002; AlZJ2004]). Insbesondere die ATAM wurde in zahlreichen Projekten validiert und es existiert eine Vielzahl von Fallstudien, die den Einsatz der Methode verdeutlicht (vgl. z. B. [ClKK2002, S. 87 ff., S. 127 ff.]). Sie unterstützt die frühe Bewertung einer Softwarearchitektur, d. h., eine Überprüfung der Eignung einer Softwarearchitektur bevor sie implementiert worden ist. Aufgrund der besonderen Positionierung und Verbreitung der ATAM wird diese Bewertungsmethode im folgenden Kapitel 3.3.2 im Detail erläutert. Sie enthält Konzepte und Modelle, die bei der Entwicklung des Wissensmodells (vgl. Kapitel 5.1) und der Vorgehensweise (vgl. Kapitel 5.2) wiederverwendet werden. Stellvertretend für die szenario-basierten Bewertungsmethoden dient sie zur Verdeutlichung der Verwendung der Wissensbasis im Kontext der Bewertung von Softwarearchitekturen (vgl. Kapitel 5.4).

3.3.2 Architecture Tradeoff Analysis-Methode Die Architecture Tradeoff Analysis-Methode wurde innerhalb des Software EngineeringInstituts auf Basis der Software Architecture Analysis-Method (vgl. [KBAW1994; KABC1996]) entwickelt (vgl. [ClKK2002, S. 43 f.; KKBL1998, S. 68]). Bei der Entwicklung der ATAM wurde auf Analyseverfahren und -techniken der SAAM zurückgegriffen. Es wurden neue Konzepte, wie die sog. Sensitivity und Tradeoff Points sowie der sog. UtilityBaum, entwickelt und integriert (vgl. Kapitel 3.3.1.1). In Kapitel 3.3.2.1 werden zunächst die Ziele und Annahmen der Methode vorgestellt. Die zugrunde liegenden Konzepte werden – mit Ausnahme des Konzepts der Qualitätsmerkmal-Szenarios, das bereits in Kapitel 3.2.4.3 erläutert wurde – in den nachfolgenden drei Kapiteln dargestellt. Im Anschluss werden die Phasen und Arbeitsschritte (siehe Kapitel 3.3.2.5) und die Ergebnisse der Methode zusammenfassend vorgestellt (siehe Kapitel 3.3.2.6). Eine kritische Bewertung der Methode (siehe Kapitel 3.3.2.7) schließt das vorliegende Kapitel ab.

82

Bewertung von Softwarearchitekturen

3.3.2.1 Ziele und Annahmen Das wesentliche Ziel der Architecture Tradeoff Analysis-Methode ist es, zu überprüfen, ob eine Softwarearchitektur im Kontext von definierten Anforderungen für ein bestimmtes System geeignet ist oder nicht (vgl. [ClKK2002, S. 27]). Existieren zwei oder mehrere alternative Entwürfe einer Softwarearchitektur, kann die Methode auch dazu verwendet werden, den Entwurf zu identifizieren, der besser für ein bestimmtes System geeignet ist. Zur Überprüfung der Eignung einer Softwarearchitektur definieren Clements, Kazman und Klein zwei Kriterien (vgl. [ClKK2002, S. 27]): ƒ Die Softwarearchitektur unterstützt die Erreichung der gewünschten Qualitätsanforde-

rungen und ƒ das Zielsystem kann mit den zur Verfügung stehenden Ressourcen erstellt werden.

Dabei ist zu beachten, dass die Eignung einer Softwarearchitektur ausschließlich im Kontext von definierten Anforderungen ermittelt werden kann (vgl. Kapitel 3.1). Eine Klassifikation einer Softwarearchitektur in die Kategorien „gut“ oder „schlecht“ ist nicht möglich (vgl. [BaCK2003, S. 15; ClKK2002, S. 27]). Die Anforderungen umfassen zusätzlich die Ressourcen, die zur Entwicklung bzw. Anpassung eines Systems zur Verfügung stehen. Eine Architektur, die mit dem primären Ziel der Effizienz (vgl. Kapitel 3.2.3.3) entworfen wurde, könnte z. B. zu einem System führen, das sehr kurze Antwortzeiten und einen hohen Durchsatz ermöglicht, aber sehr viele Ressourcen, in Form von Hardwareelementen und hoch-qualifizierten Entwicklern, benötigt. Stehen diese Ressourcen aber nicht zur Verfügung, ist die Softwarearchitektur im Kontext dieser Anforderungen nicht geeignet. Analog wäre die Softwarearchitektur ebenfalls nicht geeignet, wenn z. B. in den Anforderungen eine sehr gute Wartbarkeit des Systems verlangt würde (vgl. Kapitel 3.2.3.3). Der Kern einer Bewertung auf Basis der Architecture Tradeoff Analysis-Methode ist die Identifikation der Beziehungen zwischen den Entwurfsentscheidungen innerhalb der Softwarearchitektur und den Qualitätsmerkmalen, die durch diese Entscheidungen beeinflusst werden. Die Kenntnis dieser Beziehungen wird genutzt, um die Entwurfsentscheidungen im Hinblick auf die spezifizierten Qualitätsanforderungen zu überprüfen bzw. zu testen und die Entscheidungen zu identifizieren, die kritisch für die Erreichung der Anforderungen sind. Hierzu gehören auch Entwurfsentscheidungen, die u. U. noch nicht getroffen wurden. Diese Entscheidungen stellen potenzielle Risiken dar, da die Erreichung der spezifizierten Qualitätsmerkmale gefährdet und die Eignung der Softwarearchitektur für ein bestimmtes System u. U. nicht gegeben ist. Die Menge der Entwurfsentscheidungen wird innerhalb der ATAM auf Basis des Konzepts der sog. architektur-bezogenen Ansätze strukturiert und untersucht. Ein architektur-be-

Bewertungsmethoden für Softwarearchitekturen

83

zogener Ansatz entspricht einem Architektur-Stil nach Shaw und Garlan (vgl. Kapitel 2.1) und beschreibt eine bestimmte Anordnung und Zusammenarbeit von Softwareelementen in Kombination mit den Auswirkungen dieser Struktur auf die Qualitätsmerkmale eines Systems (vgl. [ClKK2002, S. 13]). Ein architektur-bezogener Ansatz ist daher auch ein Synonym für das Konzept des Architektur-Pattern oder Architektur-Idioms (vgl. Kapitel 2.1). Clements, Kazman und Klein verwenden den Begriff des architektur-bezogenen Ansatzes, da ihrer Meinung nach der Begriff des Architektur-Stils nicht besonders weit verbeitet ist und zu Mißverständnissen führen kann. Aus heutiger Sicht wäre der Begriff des Architektur-Pattern für das Konzept besser geeignet, da der Begriff des Pattern im Kontext des Software Engineerings sehr verbreitet ist. Die ATAM betrachtet die Entwurfsentscheidungen im Kontext von architektur-bezogenen Ansätzen, da diese die wesentlichen Strukturen eines Systems beschreiben und einen maßgeblichen Einfluss auf die Qualitätsmerkmale des Systems haben (vgl. [ClKK2002, S. 48]). Die architektur-bezogenen Ansätze stellen eine neue Abstraktionsebene dar, durch die die Menge der Entwurfsentscheidungen strukturiert und klassifiziert wird. Sie unterstützen die Analyse der Beziehungen zwischen den Entwurfsentscheidungen und Qualitätsmerkmalen, da die Beschreibung eines Architektur-Stils bzw. Architektur-Pattern die jeweiligen qualitativen Auswirkungen auf die Qualitätsmerkmale umfasst (siehe Kapitel 1). Das Konzept der architektur-bezogenen Ansätze kann daher verwendet werden, um innerhalb der Bewertung auf Basis der Architektur-Stile bzw. Architektur-Pattern bestimmte Beziehungen und Auswirkungen zu begründen und vorherzusagen.

architektur-bezogener Ansatz 1 Qualitätsanforderung 1 Qualitätsanforderung 2 Qualitätsanforderung 3

Qualitätsanforderung n

kritisch

Überprüfung

architektur-bezogener Ansatz 2 architektur-bezogener Ansatz 3 architektur-bezogener Ansatz 4 offene Entwurfsentscheidung

architektur-bezogener Ansatz m

Abbildung 3-15: Kerngedanke der Architecture Tradeoff Analysis-Methode

Abbildung 3-15 zeigt schematisch den Kerngedanken der ATAM: die architektur-bezogenen Ansätze werden im Hinblick auf die Unterstützung der Qualitätsanforderungen analysiert.

84

Bewertung von Softwarearchitekturen

Die potenziellen Risiken sind beispielhaft durch den kritischen architektur-bezogenen Ansatz 2 in Bezug auf die Qualitätsanforderung 1 und durch eine noch offene Entwurfsentscheidung dargestellt. Clements, Kazman und Klein vergleichen die Anwendung der ATAM mit einer Aktivität zur Reduzierung des Projektrisikos, d. h. dem Risikomanagement (vgl. [ClKK2002, S. 29]). Die Bewertung einer Softwarearchitektur auf Basis der ATAM kann durch die Analyse der Beziehungen auch darlegen, dass die Architektur im Hinblick auf eine Teilmenge von Qualitätsanforderungen geeignet und im Hinblick auf eine andere Teilmenge problematisch ist (vgl. [ClKK2002, S. 29]). Die Qualitätsanforderungen können zudem im Konflikt zueinander stehen oder zumindest unterschiedliche Prioritäten aufweisen. Die Bewertung mit der ATAM unterstützt die Auflösung dieser Konflikte und die Sortierung der Prioritäten.

3.3.2.2 Konzept der Sensitivitäts- und Abwägungspunkte Die ATAM unterscheidet zwei wesentliche Klassen von Architekturentscheidungen: Sensitivitätspunkte (sensitivity points) und Abwägungspunkte (tradeoff points) (vgl. [ClKK2002, S. 36]). Ein Sensitivitätspunkt ist eine Eigenschaft eines oder mehrerer Softwareelemente22 und/oder deren Beziehungen untereinander, die kritisch für die Erreichung eines Qualitätsmerkmals ist. In Bezug auf das Modell der Qualitätsmerkmal-Szenarios (vgl. Abschnitt 3.2.4.3) ist dies eine Eigenschaft des stimulierten Artefakts (siehe Abbildung 3-16).

Abbildung 3-16: Konzept der Sensitivitätspunkte

Aufgrund der hohen Relevanz für die Erreichung des Qualitätsmerkmals, hat die Eigenschaft aus der Sicht des Architekten bzw. Designers eine besondere Bedeutung: Sie beeinflusst maßgeblich die Richtung und das Ausmaß der Reaktion im Hinblick auf das Qualitätsmerkmal. Der Architekt bzw. Designer sollte diese Eigenschaft deshalb nur mit äußerster Umsicht ver22

In Anlehnung an die von Bass, Clements und Kazman in der zweiten Ausgabe aktualisierte Definition des Begriffs der Softwarearchitektur (siehe [BaCK2003, S. 21]), wird hier nicht der in der Quelle verwendete Begriff der „Komponente“, sondern der allgemeinere Begriff des „Softwareelements“ verwendet. Dieser Begriff wurde von Bass, Clements und Kazman in der aktuellen Definition verwendet, um Missverständnisse mit anderen Bereichen der Software-Technik, wie z. B. der komponenten-basierten Softwareentwicklung, zu vermeiden.

Bewertungsmethoden für Softwarearchitekturen

85

ändern und sich über die entsprechenden Auswirkungen der Änderung bewusst sein. Clements, Kazman und Klein bezeichnen deshalb die Sensitivitätspunkte als sog. „yellow flags“ (siehe [ClKK2002, S. 36]). So könnte z. B. der Grad der Kapselung von Dateiformaten in einer Anwendung sensibel auf den durchschnittlichen Aufwand zur Wartung reagieren (vgl. [ClKK2002, S. 36]). Denn sind die Dateiformate nicht ausreichend gekapselt, werden bei der Änderung eines Dateiformats zahlreiche Änderungen an verschiedenen Stellen im Quellcode der Anwendung notwendig und der Wartungsaufwand erhöht sich entsprechend. Ein Abwägungspunkt ist eine Eigenschaft eines oder mehrerer Softwareelemente und/oder deren Beziehungen untereinander, die kritisch für die Erreichung mehrerer Qualitätsmerkmale ist und der einen Sensitivitätspunkt für mehrere Qualitätsmerkmale darstellt. Analog zu den Sensitivitätspunkten sind diese Eigenschaften im Kontext des Modells der Qualitätsmerkmal-Szenarios innerhalb des Artefakts positioniert (siehe Abbildung 3-17).

Abbildung 3-17: Konzept der Abwägungspunkte

Die Abwägungspunkte sind die kritischsten Entscheidungen, die innerhalb einer Softwarearchitektur getroffen werden (vgl. [ClKK2002, S. 36]). Die ATAM konzentriert sich aus diesem Grund auf genau diese Entscheidungen. Sie können daher in Anlehnung an die Sensitivitätspunkte als sog. „red flags“ bezeichnet werden. Der Grad der Vertraulichkeit innerhalb eines sog. Virtual Private Network (VPN) ist sensibel im Hinblick auf die Größe des Schlüssels, der zur Verschlüsselung der Daten verwendet wird (vgl. [ClKK2002, S. 36]). Gleichzeitig wirkt sich die Größe des Schlüssels negativ auf den Durchsatz und somit das Zeitverhalten (d. h. die Geschwindigkeit) aus. Ist innerhalb der Anforderungen eine maximale Reaktionszeit für eine bestimmte Funktion der Anwendung spezifiziert, kann die Größe des Schlüssels einen Abwägungspunkt darstellen, d. h., es muss zwischen dem Grad der Vertraulichkeit und dem Zeitverhalten der Anwendung ein Kompromiss gefunden werden.

86

Bewertung von Softwarearchitekturen

3.3.2.3 Konzept der Risiken und Sicherheiten Das Konzept der Sensitivitäts- und Abwägungspunkte betrachtet Eigenschaften, die einen direkten Einfluss auf ein bzw. mehrere Qualitätsmerkmal(e) haben. Das Konzept der Risiken (risks) und Sicherheiten23 (non-risks) befasst sich mit konkreten Ausprägungen dieser Eigenschaften im Kontext der Bewertung einer Softwarearchitektur. Bestimmte Werte eines Sensitivitätspunkts können zu einem Risiko werden, sofern diese Werte zu unerwünschten Reaktionen führen [ClKK2002, S. 36]. Risiken sind somit Entwurfsentscheidungen, die im Kontext der gesamten Softwarearchitektur potenzielle Probleme darstellen (vgl. [ClKK2002, S. 34]). Die Identifikation dieser Risiken ist ein wesentliches Ziel der ATAM. Im Gegensatz zu den Risiken beziehen sich Sicherheiten auf Entwurfsentscheidungen, die die Anforderungen erfüllen, d. h., die Art und Weise wie die Softwarearchitektur entworfen ist, entspricht den Anforderungen bezüglich der Qualitätsmerkmale [ClKK2002, S. 96]. Sie repräsentieren die Stärken der Architektur (vgl. [ClKK2002, S. 69]). Innerhalb der ATAM werden auch die Sicherheiten explizit dokumentiert, denn wenn sich diese Entwurfsentscheidungen innerhalb des Lebenszyklus der Architektur (vgl. Kapitel 2.4) ändern, müssen die Reaktionen, die durch die geänderten Werte hervorgerufen werden, erneut überprüft werden [ClKK2002, S. 96]. Diese erneute Überprüfung kann u. a. auf Basis der Dokumentation der Sicherheiten erfolgen und umfasst eine Analyse, ob es sich weiterhin um eine Sicherheit handelt oder durch die Änderung der Werte ein neues Risiko entstanden ist. Risiken und Sicherheiten werden als ein wesentliches Ergebnis der Bewertung einer Softwarearchitektur mit der ATAM dokumentiert. Die Dokumentation umfasst für jedes Risiko bzw. jede Sicherheit die entsprechenden Entwurfsentscheidung, die vorhergesagte Reaktion in Bezug auf ein oder mehrere Qualitätsmerkmale, die erwarteten Konsequenzen der Reaktion und eine Begründung für die positive bzw. negative Reaktion (vgl. [ClKK2002, S. 34 f.]). Es werden auch Entwurfsentscheidungen dokumentiert, die noch nicht getroffen worden sind, denn die Tatsache, dass noch keine Entscheidung vorliegt, kann ebenfalls ein Risiko darstellen (vgl. Kapitel 3.3.2.1).

3.3.2.4 Konzept des Nutzwert-Baums Der Nutzwert-Baum (utility tree) ist ein Konzept zur strukturierten Erfassung und Priorisierung der Qualitätsanforderungen (vgl. [ClKK2002, S. 50-56]). Die system-spezifischen Qualitätsanforderungen werden auf Basis eines Baums strukturiert und verfeinert, indem ausgehend von der Wurzel des Baums, die den gesamten Nutzen des Systems (utility) darstellt, die Qualitätsanforderungen auf Basis von Qualitätsmerkmalen klassifiziert und verfeinert werden. Die Blätter des Baums beschreiben Szenarios, die auf Basis des Modells der Qualitätsmerkmal23

Der englische Begriff „non-risk“ wurde frei mit „Sicherheit“ übersetzt, da nach der Einschätzung des Autors keine sinnvolle direkte Übersetzung möglich ist („Nicht-Risiko“).

Bewertungsmethoden für Softwarearchitekturen

87

Szenarios beschrieben werden, und daher aussagekräftige und überprüfbare Qualitätsanforderungen darstellen (vgl. Kapitel 3.2.4.3). Die Szenarios beziehen sich jeweils auf das übergeordnete Qualitätsmerkmal und können zur Gewährleistung der Übersichtlichkeit in der Textform (vgl. Kapitel 3.2.4.4) spezifiziert werden. Abbildung 3-18 verdeutlicht den grundsätzlichen Aufbau eines Nutzwert-Baums anhand eines Beispiels.

Antwortzeit einer Bestandsanfrage durch den Kunden < 1 Sek. Zeitverhalten Durchführung des Tagesabschlusses < 2 Std.

Effizienz

Verbrauchsverhalten

Modifizierbarkeit

Nutzwert (utility)

Auslastung der CPUs innerhalb der Hochlastzeiten < 75% Erstellung einer neuen Lieferantenschnittstelle < 20 PT

Wartbarkeit

...

Sicherheit

...

...

Abbildung 3-18: Aufbau eines Nutzwert-Baums Quelle: in Anlehnung an [ClKK2002, S. 51]

Die exakte Struktur und die einzelnen Knoten des Baums werden im Rahmen des Konzepts nicht definiert. Um Missverständnisse zu vermeiden empfehlen Clements, Kazman und Klein innerhalb des Baums Qualitätsmerkmale zu verwenden, die im Bewertungsteam bekannt sind und einheitlich interpretiert werden (vgl. [ClKK2002, S. 51]). Die Strukturierung des Baums kann – obwohl Clements, Kazman und Klein diese Option nicht explizit erwähnen – auf Basis eines Qualitätsmodells, wie es z. B. innerhalb des ISO/IEC 9126-Standards definiert wird (vgl. Kapitel 3.2.3), erfolgen. Die Verwendung eines derartigen Qualitätsmodells bietet den Vorteil, dass – neben einer einheitlichen Struktur und Terminologie für die Qualitätsmerkmale – auch die Vollständigkeit der Qualitätsanforderungen überprüft werden kann (vgl. Kapitel 3.2.3.1). Der Nutzwert-Baum kann im Rahmen einer Bewertung eine Vielzahl von Qualitätsmerkmalen und eine entsprechend große Anzahl von Szenarios enthalten, deren Unterstützung durch die Softwarearchitektur im Verlauf der Bewertung überprüft werden muss. Darüber hinaus enthält ein konkreter Nutzwert-Baum zahlreiche Qualitätsanforderungen in der Form

88

Bewertung von Softwarearchitekturen

von Szenarios, die untereinander konkurrieren. Neben der Strukturierung und Verfeinerung der Szenarios müssen diese priorisiert werden, um die Bewertung auf die wesentlichen Qualitätsanforderungen zu fokussieren und Konflikte zwischen den Qualitätsanforderungen aufzulösen (vgl. [ClKK2002, S. 50 f., 55 f.]). Die Priorisierung der relativen Wichtigkeit der Szenarios erfolgt dabei in zwei Dimensionen: die Wichtigkeit der Szenarios für den Erfolg bzw. die Eignung des Systems und die Schwierigkeit der Erreichung des Szenarios, die aus der subjektiven Sicht des Architekten bestimmt wird (vgl. [ClKK2002, S. 55]). Die beiden Priorisierungen können auf Basis einer beliebigen Klassifikation erfolgen, wobei Clements, Kazman und Klein aus eigener Erfahrung die Kategorien „hoch (H)“, „mittel (M)“ und „niedrig (N)“ empfehlen (vgl. [ClKK2002, S. 51]). Die beiden Dimensionen der Priorisierung werden innerhalb des Nutzwert-Baums zu jedem Szenario erfasst, wobei in runden Klammern die abgekürzte Kategorie zunächst für die Wichtigkeit der Szenarios für den Erfolg bzw. die Eignung des Systems und anschließend – durch ein Komma getrennt – die Schwierigkeit der Erreichung des Szenarios erfasst wird (siehe Abbildung 3-19).

(H, H) Antwortzeit einer Bestandsanfrage durch den Kunden < 1 Sek. Zeitverhalten (H, M) Durchführung des Tagesabschlusses < 2 Std.

Effizienz

Nutzwert (utility)

Verbrauchsverhalten

(M, N) Auslastung der CPUs innerhalb der Hochlastzeiten < 75%

Modifizierbarkeit

(N, N) Erstellung einer neuen Lieferantenschnittstelle < 20 PT

Wartbarkeit

...

Sicherheit

...

...

Abbildung 3-19: Erfassung von Prioritäten innerhalb des Nutzwert-Baums Quelle: in Anlehnung an [ClKK2002, S. 51]

Die Prioritäten ermöglichen die Sortierung der Szenarios und die Reduktion einer großen Menge von Szenarios, indem zunächst die Szenarios mit einer hohen Priorität in beiden Dimensionen, d. h. „(H, H)“, analysiert werden (vgl. [ClKK2002, S. 55]). Im Anschluss werden entweder die Szenarios der Kategorie „(M, H)“ oder „(H, M)“ untersucht. Die Auswahl einer

Bewertungsmethoden für Softwarearchitekturen

89

Kategorie sollte auf Basis eines Konsenses erfolgen, der zwischen den Teilnehmern der Bewertung zu ermitteln ist. Ist anschließend noch Zeit verfügbar, wird mit der Kategorie „(M, M)“ usw. fortgefahren. Das Ergebnis der Erstellung eines Nutzwert-Baums ist eine priorisierte Liste der Szenarios, die zur Planung und Strukturierung der Vorgehensweise innerhalb der Bewertung verwendet wird (vgl. [ClKK2002, S. 55]).

3.3.2.5 Phasen und Arbeitsschritte Die Architecture Tradeoff Analysis-Methode besteht aus insgesamt neun Arbeitsschritten, die in vier Phasen eingeteilt werden. Abbildung 3-20 zeigt die Phasen und Arbeitsschritte im Überblick.

Abbildung 3-20: Phasen und Arbeitsschritte der Architecture Tradeoff Analysis-Methode

Obwohl die Pfeile zwischen den Arbeitsschritten und die Nummerierung der Arbeitsschritte eine strikt lineare Ausführung der einzelnen Schritte vermuten lassen, weisen Clements, Kazman und Klein darauf hin, dass es sich bei der ATAM nicht um einen Wasserfallprozess handelt, sondern die Vorgehensweise – in Abhängigkeit von z. B. der Verfügbarkeit der Mitarbeiter oder der Architekturdokumentation – auch dynamisch angepasst werden kann (vgl. [ClKK2002, S. 45]). Arbeitsschritt 1: Präsentation der ATAM Der erste Schritt innerhalb der ATAM umfasst eine Vorstellung der einzelnen Phasen und Arbeitsschritte der Methode und eine Erläuterung der innerhalb der Methoden angewendeten Techniken und Konzepte durch den Leiter der Bewertung (vgl. [ClKK2002, S. 45 f.]). Das wesentliche Ziel dieses Arbeitsschrittes ist es, die Teilnehmer der Bewertung mit der Methode vertraut zu machen, eine angemessene Erwartungshaltung aufzubauen und offene Fragen zu klären. Clements, Kazman und Klein merken an, dass sie hierzu eine Menge standardisierter

90

Bewertung von Softwarearchitekturen

Folien verwenden, deren grundlegende Struktur auch beschrieben wird (vgl. [ClKK2002, S. 46, 151]). Arbeitsschritt 2: Präsentation der Geschäftsziele Die Teilnehmer der Bewertung, d. h. die Stakeholder des Systems und das Bewertungsteam, müssen den Kontext und die primären Geschäftsziele des Systems verstehen (vgl. [ClKK2002, S. 46]). Der Projektverantwortliche präsentiert deshalb innerhalb dieses Arbeitsschrittes das System aus einer betriebswirtschaftlichen bzw. fachlichen Perspektive. Analog zum ersten Schritt skizzieren Clements, Kazman und Klein die grundlegende Struktur und Inhalte einer derartigen Präsentation, die die folgenden Punkte enthalten sollte (vgl. [ClKK2002, S. 46 f.]): ƒ die wichtigsten Funktionen des Systems, ƒ technische, innerbetriebliche, betriebswirtschaftliche oder politische Einschränkungen,

die auf das System einwirken, ƒ die betriebswirtschaftlichen Ziele und der Kontext der Anwendung, ƒ die wesentlichen Stakeholder und ƒ die wesentlichen Qualitätsmerkmale, die die Architektur prägen.

Arbeitsschritt 3: Präsentation der Architektur Der dritte Arbeitsschritt umfasst die Präsentation der Architektur durch den leitenden Architekten oder das gesamte Architekturteam (vgl. [ClKK2002, S. 47]). Diese Präsentation soll die Architektur auf einem „angemessenen“ Abstraktionsniveau vorstellen, wobei Clements, Kazman und Klein anmerken, dass dieses Niveau von vielen Faktoren abhängt. Zu diesen Faktoren gehört z. B. wie umfangreich die Architektur dokumentiert wurde, wieviel Zeit für die Bewertung zur Verfügung steht und wie die Qualitätsanforderungen im Detail ausgeprägt sind. Clements, Kazman und Klein weisen explizit darauf hin, dass sich die vorgestellten Informationen bezüglich der Architektur direkt auf die Möglichkeiten und die Qualität der Bewertung beziehen, d. h., ohne entsprechende Informationen ist die Bewertung überhaupt nicht oder nur in geringer Qualität möglich. Innerhalb dieses Schrittes werden deshalb auch häufig weitere architektur-bezogene Informationen nachgefragt und ermittelt. Die Präsentation sollte u. a. die folgenden Punkte enthalten (vgl. [ClKK2002, S. 47]): ƒ technische Einschränkungen, wie z. B. Hardware oder Betriebssysteme, ƒ andere Systeme, mit denen das System integriert werden muss und

Bewertungsmethoden für Softwarearchitekturen

91

ƒ die architektur-bezogenen Ansätze, die zur Erreichung der Qualitätsmerkmale einge-

setzt werden. Innerhalb der Präsentation sollte der leitende Architekt oder das Architekturteam auf das Sichtenkonzept (vgl. Kapitel 2.5) zurückgreifen und die Sichten der Architektur erläutern, die am besten geeignet sind, um die Architektur vorzustellen. Analog zu den ersten beiden Schritten skizzieren Clements, Kazman und Klein die grundlegende Struktur und die Inhalte einer derartigen Präsentation (vgl. [ClKK2002, S. 47 f.]). Arbeitsschritt 4: Identifikation der Architekturansätze Auf Basis der Präsentation der Architektur werden im vierten Arbeitsschritt die architekturbezogenen Ansätze vom Bewertungsteam identifiziert, indem der leitende Architekt oder das gesamte Architekturteam aufgefordert wird, diese Ansätze explizit zu nennen (vgl. [ClKK2002, S. 48]). Die Architekturansätze bilden das Abstraktionsniveau, auf dem die Architektur untersucht wird (vgl. Kapitel 3.3.2.1). Unter Verwendung von bekannten Architektur-Stilen bzw. Architektur-Pattern unterstützen sie die Identifikation, Interpretation und Vorhersage der Auswirkungen auf die Qualitätsmerkmale des Systems. Zu diesem Zeitpunkt erfolgt lediglich die Identifikation der architektur-bezogenen Ansätze, d. h., eine Analyse der Auswirkungen erfolgt noch nicht (vgl. [ClKK2002, S. 48]). Arbeitsschritt 5: Erstellung des Nutzwert-Baums Das Ziel dieses Schrittes ist die Identifikation, Strukturierung und Priorisierung der wesentlichen Qualitätsanforderungen des Systems durch das Bewertungsteam, den leitenden Architekten bzw. das Architekturteam und die Projektleiter (vgl. [ClKK2002, S. 50]). Die konzeptuelle Grundlage bildet der sog. Nutzwert-Baum (vgl. Kapitel 3.3.2.4), der zur Erstellung, Klassifikation und Priorisierung der Anforderungen auf Basis von Szenarios verwendet wird. Clements, Kazman und Klein heben die hohe Relevanz dieses Arbeitsschrittes hervor, denn die ermittelten Anforderungen sind für die weiteren Arbeitsschritte von elementarer Bedeutung (vgl. [ClKK2002, S. 50]). Werden die Qualitätsanforderungen nicht vollständig erfasst und/oder nicht korrekt priorisiert, besteht die Gefahr, dass wertvolle Zeit in die Bewertung investiert wird, ohne dass die wesentlichen Anforderungen der Stakeholder berücksichtigt werden. Das Ergebnis des Arbeitsschrittes ist eine priorisierte Liste der Szenarios, die im Folgenden zur Planung und Strukturierung der Vorgehensweise innerhalb der Bewertung verwendet wird (vgl. [ClKK2002, S. 55]). Sie zeigt dem Bewertungsteam, für welche Szenarios die Zeit einer

92

Bewertung von Softwarearchitekturen

Bewertung sinnvollerweise verwendet werden sollte und unterstützt deshalb die Effizienz und Effektivität des Bewertungsprozesses. Arbeitsschritt 6: Analyse der Architekturansätze Der sechste Arbeitsschritt basiert auf zwei wesentlichen Ergebnissen der vorherigen Schritte (vgl. [ClKK2002, S. 56]): ƒ der Liste der architektur-bezogenen Ansätze, die innerhalb der Architektur verwendet

werden (Ergebnis des vierten Arbeitsschrittes) und ƒ der Liste der priorisierten Qualitätsanforderungen, die auf Basis des Nutzwert-Baums

und der Szenarios strukturiert und aussagekräftig formuliert wurden (Ergebnis des fünften Arbeitsschrittes). Das wesentliche Ziel dieses Schrittes ist es, zu überprüfen, wie gut die Architekturansätze zu den Qualitätsanforderungen passen (siehe Abbildung 3-21).

. . .

. . .

Abbildung 3-21: Überprüfung der Architekturansätze

Der Nutzwert-Baum zeigt dem Bewertungsteam durch die Priorisierung der Szenarios, wo die Architektur überprüft werden muss (vgl. [ClKK2002, S. 56]).

Bewertungsmethoden für Softwarearchitekturen

93

Im besten Fall antwortet der Architekt bzw. das Architekturteam mit dem architektur-bezogenen Ansatz, der die jeweilige Anforderung umsetzt (siehe Abbildung 3-22, Pfeil 1).

. . .

Abbildung 3-22: Vorgehensweise innerhalb der Analyse der Architekturansätze

Das Bewertungsteam kann auf Basis von Fragen, die sich auf ein Qualitätsmerkmal beziehen, den Architekturansatz detaillierter analysieren (vgl. Abbildung 3-22, Pfeil 2). Die Fragen bezüglich eines Architekturansatzes unterstützen das Bewertungsteam in mehreren Bereichen (vgl. [ClKK2002, S. 57]): ƒ Aufbau eines detaillierten Verständnisses des Architekturansatzes und wie dieser im

konkreten Kontext des Systems eingesetzt wurde, ƒ Untersuchung der bekannten Schwächen des Architekturansatzes (vgl. Abbildung 3-22,

Pfeil 3), ƒ Untersuchung der Sensitivitäts- und Abwägungspunkte des Architekturansatzes (vgl.

Abbildung 3-22, Pfeil 3) und ƒ Identifikation der Interaktionen und Abwägungen mit anderen Architekturansätzen (vgl.

Abbildung 3-22, Pfeil 4). Die einzelnen Fragen dienen als Ausgangspunkt für eine Diskussion und die Identifikation von Sensitivitäts- und Abwägungspunkten (vgl. Kapitel 3.3.2.2) sowie potenziellen Risiken und Sicherheiten (vgl. Kapitel 3.3.2.3). Bei Bedarf können die Fragen weiter verfeinert werden, z. B. wenn der Architekt nicht genügend Informationen über einen Architekturansatz zur Verfügung stellen kann (vgl. [ClKK2002, S. 56 f.]). Das Ziel dieser Fragen ist, genügend Informationen für eine rudimentäre Analyse des Architekturansatzes zu erhalten, so dass sich

94

Bewertung von Softwarearchitekturen

das Bewertungsteam davon überzeugen kann, dass der gewählte Architekturansatz zur Erreichung der relevanten Qualitätsanforderungen ausreichend ist (vgl. [ClKK2002, S. 56 f.]). Eine umfassende und detaillierte Analyse der architektur-bezogenen Ansätze ist daher nicht zwingend notwendig. Im Wesentlichen sollen ausreichend Informationen ermittelt werden, um zwischen den Entwurfsentscheidungen, die u. a. durch die Auswahl des Architekturansatzes getroffen wurden, und den Qualitätsanforderungen des Systems eine Verbindung herzustellen (vgl. [ClKK2002, S. 58]). Der Arbeitsschritt der Analyse der Architekturansätze umfasst auch die kontinuierliche Dokumentation der folgenden ermittelten Informationen (vgl. [ClKK2002, S. 56 f.]): ƒ die architektur-bezogenen Ansätze oder Entwurfsentscheidungen, die zur Unterstützung

der hoch-priorisierten Szenarios relevant sind, ƒ die Analysefragen, die zu einem Architekturansatz gestellt wurden und über ein oder

mehrere Szenarios innerhalb des Nutzwert-Baums einem Qualitätsmerkmal zugeordnet werden können, ƒ die Antworten des Architekten zu diesen Fragen und ƒ die identifizierten Sensitivitäts- und Abwägungspunkte sowie Risiken und Sicherheiten,

die über die zugrunde liegende Analysefrage einem Qualitätsmerkmal zugeordnet werden können. Das Bewertungsteam sollte grundsätzlich davon ausgehen, dass alle architektur-bezogenen Ansätze bzw. Entwurfsentscheidungen im vierten Arbeitsschritt dokumentiert worden sind, so dass alle hoch-priorisierten Szenarios durch mindestens einen dokumentierten Ansatz unterstützt werden (vgl. [ClKK2002, S. 56]). Falls zu einem oder mehreren hoch-priorisierten Szenarios kein Architekturansatz in der Liste existiert, muss das Bewertungsteam diese Unstimmigkeit klären und u. U. zum vierten Arbeitsschritt zurückkehren. Die Analysefragen sollen nach Clements, Kazman und Klein auf Basis von dokumentierten Erfahrungen mit den Ansätzen, Büchern zum Themenkomplex der Softwarearchitekturen sowie den individuellen Erfahrungen und Kenntnissen der Bewertungsteilnehmer generiert werden (vgl. [ClKK2002, S. 57]). Arbeitsschritt 7: Szenario-Brainstorming Die Erstellung des Nutzwert-Baums innerhalb des fünften Arbeitsschrittes erfolgte, um zu verstehen, wie der Architekt und das Architekturteam die Qualitätsanforderungen verstanden und interpretiert haben (vgl. [ClKK2002, S. 60]). Das Ziel des siebten Arbeitsschrittes ist es, auf Basis der Brainstorming-Methode weitere Szenarios zu generieren und zu priorisieren, die die Anforderungen aus der Perspektive einer größeren Gruppe der Stakeholder reflektieren (vgl. [ClKK2002, S. 60]).

Bewertungsmethoden für Softwarearchitekturen

95

Die Methode des Brainstormings wird verwendet, um die Kommunikation und Kreativität der Stakeholder bei der Erstellung von Szenarios zu fördern und ein gemeinsames Verständnis der Anforderungen und deren Prioritäten aufzubauen. Die Stakeholder werden aufgefordert, Szenarios zu den folgenden drei Kategorien zu generieren (vgl. [ClKK2002, S. 60]): ƒ anwendungsfall-bezogene Szenarios (use case scenarios), ƒ wachstums-bezogene Szenarios (growth scenarios) und ƒ erforschende Szenarios (exploratory scenarios).

Die anwendungsfall-bezogenen Szenarios geben wieder, wie sich die Stakeholder die Nutzung des Systems vorstellen, d. h., die Stakeholder nehmen die Rolle eines Benutzers ein, der die Anwendung bzw. das System verwendet. Die wachstums-bezogenen Szenarios reflektieren die kurzfristig erwarteten Änderungen der Anforderungen im Hinblick auf die Qualitätsmerkmale der Effizienz, Modifizierbarkeit usw., um die Stärken und Schwächen der Architektur aufzuzeigen. Die erforschenden Szenarios dienen der Untersuchung von extremen Formen der Weiterentwicklung des Systems, wie z. B. wesentliche Änderungen der Effizienzanforderungen oder der zugrunde liegenden Infrastruktur. Diese Szenarios werden generiert, um weitere Sensitivitäts- und Abwägungspunkte zu identifizieren, die durch die besondere „Belastung“ des Systems entstehen. Darüber hinaus erhalten die Stakeholder Gelegenheit, die Szenarios, die auf Basis des Nutzwert-Baums generiert wurden, aber im sechsten Arbeitsschritt aufgrund der Priorisierung nicht weiter untersucht wurden, zu berücksichtigen (vgl. [ClKK2002, S. 60]). Die erneute Betrachtung der Ergebnisse des fünften und sechsten Arbeitsschrittes ermöglicht eine Validierung und kritische Überprüfung der bisher erfassten, aber noch nicht getesteten Szenarios. Die Szenarios, die aus Sicht der größeren Stakeholder-Gruppe bisher nicht ausreichend berücksichtigt wurden, können hierzu auch in die Liste der Szenarios aufgenommen werden. Nachdem die finale Liste der Szenarios erstellt worden ist, müssen die Szenarios erneut priorisiert werden (vgl. [ClKK2002, S. 60]). Zuvor wird die Liste im Hinblick auf redundante Szenarios untersucht, die ein gleiches Verhalten oder eine gleiche Qualitätsanforderung darstellen. Diese Szenarios werden konsolidiert. Die anschließende Priorisierung erfolgt auf Basis einer öffentlichen Abstimmung: jeder Stakeholder erhält die aufgerundete Anzahl von Stimmen, die einem relativen Anteil von 30% der generierten Szenarios entspricht (vgl. [ClKK2002, S. 60 f.]). Wurden z. B. insgesamt 18 Szenarios erfasst, so erhält jeder Stakeholder sechs Stimmen. Der Leiter der Bewertung sammelt, addiert und sortiert die einzelnen Stimmen in absteigender Folge. Anschließend untersucht er diese Liste hinsichtlich einer Grenze, die einen starken Abfall der Stimmen aufweist (vgl. [ClKK2002, S. 61]). Nur die Stimmen oberhalb dieser Grenze werden im Folgenden weiter betrachtet.

96

Bewertung von Softwarearchitekturen

Die auf Basis der Abstimmung identifizierten hoch-priorisierten Szenarios werden mit in den Nutzwert-Baum aufgenommen. Da hierzu jeweils ein entsprechender Knoten im Baum identifiziert werden muss, analysiert das Bewertungsteam zunächst das Qualitätsmerkmal, das durch das jeweilige Szenario beeinflusst wird. Nach der Aufnahme eines Szenarios innerhalb des Nutzwert-Baums, können drei Fälle auftreten (vgl. [ClKK2002, S. 61 f.]): ƒ das Szenario entspricht einem bereits existierenden Szenario, d. h. einem Blatt im

Baum, ƒ das Szenario wird – unter der Berücksichtigung von Synonymen der Qualitätsmerk-

male – als neues Blatt unterhalb eines bereits existierenden Knotens aufgenommen oder ƒ das Szenario passt zu keinem existierenden Knoten des Baums, weil es ein Qualitäts-

merkmal beeinflusst, dass zuvor noch nicht berücksichtigt wurde. Die beiden ersten Fälle zeigen, dass die größere Gruppe der Stakeholder und der Architekt bzw. das Architekturteam ein gemeinsames oder zumindest ähnliches Verständnis hinsichtlich der relevanten Qualitätsmerkmale haben. Der dritte Fall deutet aber darauf hin, dass der Architekt bzw. das Architekturteam ein wichtiges Qualitätsmerkmal nicht berücksichtigt hat (vgl. [ClKK2002, S. 62]). Innerhalb der anschließenden Überprüfung dieser Szenarios können neue, d. h. bisher noch nicht dokumentierte, Risiken identifiziert werden. Clements, Kazman und Klein weisen darauf hin, dass der Vergleich der hoch-priorisierten Szenarios aus dem fünften und siebten Arbeitsschritt sehr oft Inkonsistenzen bezüglich der Priorisierung der Szenarios aufdeckt, d. h. die Qualitätsmerkmale, die der Architekt bzw. das Architekturteam als wichtig erachtet, stimmen nicht mit der Sichtweise der größeren Gruppe der Stakeholder überein (vgl. [ClKK2002, S. 62]). Diese Inkonsistenz stellt ein potenzielles Risiko der Architektur dar, da offensichtlich bestimmte Qualitätsmerkmale nicht ausreichend berücksichtigt wurden. Arbeitsschritt 8: Analyse der Architekturansätze Der achte Arbeitsschritt stimmt im Wesentlichen mit dem fünften Schritt überein, d. h., für die hoch-priorisierten Szenarios des aktualisierten Nutzwert-Baums werden die jeweiligen Architekturansätze durch den Architekten bzw. das Architekturteam identifiziert und untersucht (vgl. [ClKK2002, S. 68]). Falls innerhalb des siebten Schrittes keine neuen hoch-priorisierten Szenarios erstellt wurden, d. h. Szenarios, die noch nicht im Nutzwert-Baum enthalten waren, erhält dieser Arbeitsschritt im Wesentlichen einen testenden Charakter und es werden keine neuen wesentlichen Informationen erwartet.

Bewertungsmethoden für Softwarearchitekturen

97

Arbeitsschritt 9: Präsentation der Ergebnisse Die Methode endet mit der Präsentation der ermittelten Ergebnisse der Bewertung. Die Präsentation kann verbal und durch Folien unterstützt erfolgen. Sie kann durch einen ausführlichen Bericht in Textform, der im Anschluss an die Ausführung der Methode erstellt wird, ergänzt werden (vgl. [ClKK2002, S. 68]). Der Leiter der Bewertung wiederholt kurz die Vorgehensweise innerhalb der Methode, den geschäftlichen Kontext, die wesentlichen Anforderungen und Rahmenbedingungen. Darüber hinaus wird die Softwarearchitektur kurz skizziert und die Ergebnisse der Bewertung werden dargestellt. Neben der Präsentation erstellt das Bewertungsteam innerhalb dieses Arbeitsschrittes ein weiteres neues Ergebnis: sog. Risikothemen (risk themes) (vgl. [ClKK2002, S. 68]). Clements, Kazman und Klein weisen darauf hin, dass sich die Risiken i. d. R. auf Basis einer allgemeinen Schwäche des Systems oder eines allgemeinen Bedenkens gruppieren lassen. Das Bewertungsteam identifiziert für jedes Risikothema die betriebswirtschaftlichen Ziele, die durch ein Thema beeinflusst werden. Diese Zuordnung schließt zum einen den Kreis der Bewertung, indem die finalen Ergebnisse in Bezug zu der Präsentation der Geschäftsziele (Arbeitsschritt 2) gesetzt werden. Zum anderen werden die Risiken, die zunächst nur auf der technischen Ebene der Architektur identifiziert wurden, auf die betriebswirtschaftliche Ebene gehoben. Die Risiken rücken daher in den Fokus des Managements, da bestimmte betriebswirtschaftliche Ziele u. U. gefährdet sind.

3.3.2.6 Ergebnisse der Bewertung Nach Abschluss des neunten Arbeitsschrittes liegen die finalen Ergebnisse der Bewertung vor. Diese umfassen die folgenden Listen und Elemente (vgl. [ClKK2002, S. 68]): ƒ die Liste der dokumentierten architektur-bezogenen Architekturansätze, ƒ eine Menge von priorisierten Szenarios, ƒ eine Menge von Analysefragen in Bezug auf die Qualitätsmerkmale, ƒ den Nutzwert-Baum, ƒ identifizierte Risiken, ƒ dokumentierte Sicherheiten, ƒ entdeckte Sensitivitäts- und Abwägungspunkte und ƒ Risikothemen und deren Zuordnung zu betriebswirtschaftlichen Themen.

Clements, Kazman und Klein merken an, dass innerhalb der Analyseschritte sehr häufig Verbesserungsvorschläge und -empfehlungen ausgesprochen werden, die entsprechende Gegenmaßnahmen zur Begegnung der Risiken darstellen (vgl. [ClKK2002, S. 70]). Die Identifi-

98

Bewertung von Softwarearchitekturen

kation dieser Gegenmaßnahmen ist allerdings nicht integraler Bestandteil der Architecture Tradeoff Analysis-Methode und nicht als ein direktes Ergebnis der Methode vorgesehen.

3.3.2.7 Bewertung der Methode Die Architecture Tradeoff Analysis-Methode beschreibt eine Vorgehensweise zur Bewertung von Softwarearchitekturen. Ausgehend von dem Kontext und den zugrunde liegenden Geschäftszielen eines Systems werden die Qualitätsanforderungen systematisch erfasst und den Ansätzen, die innerhalb der Architektur verwendet wurden, gegenübergestellt. Obwohl Clements, Kazman und Klein die Methode dokumentierten (vgl. [ClKK2002, 43 ff.]), wurde sie nicht ausschließlich von ihnen, sondern von einem größeren Team des Software Engineering-Instituts sukzessive entwickelt. Aufgrund der Tatsache, dass die Methode in vielen Projekten eingesetzt worden ist, zahlreiche Fallstudien der Anwendung dokumentiert worden sind (vgl. z. B. [ClKK2002, S. 87 ff., S. 128 ff.]) und das SEI mittlerweise kommerzielle Schulungen24 und Zertifizierungen25 zur ATAM anbietet, kann die Methode als „ausgereift“ klassifiziert werden. Die Dokumentation der Methode erfolgt durch Clements, Kazman und Klein größtenteils sehr detailliert. Die Arbeitsschritte der Präsentationsphase enthalten z. B. konkrete Vorschläge für die Struktur, Inhalte und Dauer der Präsentationen. Andere Arbeitsschritte, wie z. B. die Erstellung des Nutzwert-Baums, werden indirekt durch die zugrunde liegenden Konzepte detailliert strukturiert und beschrieben. Die konsequente Priorisierung der Anforderungen – zum einen aus der Sichtweise der Architekten bzw. des Architekturteams auf Basis des Nutzwert-Baums und zum anderen aus der Sichtweise einer größeren Gruppe von Stakeholdern auf Basis der Brainstorming-Methode – bildet die Grundlage für eine gezielte Betrachtung und Überprüfung der Szenarios, die durch eine geeignete Architektur unterstützt werden müssen. Die Priorisierung der Szenarios ermöglicht einen effizienten Umgang mit den zur Verfügung stehenen Projektressourcen, indem sich das Bewertungsteam ausschließlich auf die hoch-priorisierten Szenarios konzentriert. Das Konzept, die Architektur auf dem Abstraktionsniveau der einzelnen Architekturansätze, d. h. der Architektur-Stile und -pattern zu betrachten, trägt dazu bei, die Bewertung effizient zu gestalten, da nicht jede grundlegende Fragestellung und Auswirkung eines Architekturansatzes erneut im Detail analysiert werden muss. Es ermöglicht, qualitative Aussagen bezüglich der grundsätzlichen Auswirkungen eines Ansatzes auf die Qualitätsmerkmale zu treffen. Diese Auswirkungen sind für einen Architekturansatz, d. h. einen Architektur-Stil bzw. ein Architektur-Pattern, bekannt, da die zugrunde liegenden Lösungsansätze in einer Vielzahl von Systemen eingesetzt und erprobt worden sind. Die Architekturansätze können die Grundlage 24 25

Siehe http://www.sei.cmu.edu/products/courses/aet.html Siehe http://www.sei.cmu.edu/architecture/certificate_program.html

Bewertungsmethoden für Softwarearchitekturen

99

für eine Vorhersage der Qualitätsmerkmalsausprägungen eines konkreten Systems bilden. Die Architecture Tradeoff Analysis-Methode kann deshalb – im Gegensatz zu den quantitativen Bewertungsmethoden für Softwarearchitekturen – auch verwendet werden, wenn ausschließlich der Entwurf einer Softwarearchitektur vorliegt und quantitative Messungen noch nicht möglich sind. Kritisch anzumerken ist, dass die Anwendbarkeit und der Erfolg der Methode – obwohl sie größtenteils sehr detailliert dokumentiert ist – sehr stark von den Kenntnissen und Erfahrungen der beteiligten Architekten bzw. des Bewertungsteams abhängt. Das wesentliche Ziel der Methode, d. h. die Überprüfung, ob eine Softwarearchitektur im Kontext von definierten Anforderungen für ein bestimmtes System geeignet ist oder nicht (vgl. Kapitel 3.3.2.1), ist daher gefährdet, wenn die Teilnehmer des Bewertungsteams bzw. die Architekten nicht ausreichend qualifiziert sind. Die Abhängigkeit von den Kenntnissen und Fähigkeiten, der an der Bewertung beteiligten Personen, wird insbesondere im sechsten und achten Arbeitsschritt der Methode deutlich. Innerhalb dieser Schritte werden die Architekturansätze im Hinblick auf die Qualitätsanforderungen und auf Basis von Analysefragen untersucht (vgl. Kapitel 3.3.2.5). Die Analysefragen sollen das Bewertungsteam bei der Erarbeitung eines gemeinsamen Verständnisses eines Architekturansatzes im Kontext des Systems unterstützen. Sie werden verwendet, um anschließend die Sensitivitäts- und Abwägungspunkte, Abhängigkeiten sowie Schwächen des Ansatzes zu untersuchen. Diese Untersuchungen bilden die Basis für die Identifikation von Risiken und Sicherheiten innerhalb der Architektur. Die Analysefragen sind der Ausgangspunkt für eine Diskussion der Architekturansätze und können bei Bedarf verfeinert werden. Das Ziel der Diskussion bzw. Analysefragen ist, genügend Informationen für eine rudimentäre Analyse des Architekturansatzes zu erhalten, so dass sich das Bewertungsteam davon überzeugen kann, dass der gewählte Architekturansatz zur Erreichung der relevanten Qualitätsanforderungen geeignet ist (vgl. Kapitel 3.3.2.5). Die Generierung von Analysefragen bzw. die Diskussion eines Architekturansatzes kann aber sehr schnell ins Stocken geraten, wenn keine ausreichenden Kenntnisse bezüglich eines Ansatzes vorliegen und/oder ein Architekturansatz durch den Architekten bzw. das Architekturteam nicht verständlich erläutert werden kann. Die wesentliche Gefahr einer derartigen Situation entsteht dadurch, dass Architekturansätze vom Bewertungsteam nur unvollständig betrachtet und z. B. Schwächen, Sensitivitäts- und/oder Abwägungspunkte übersehen werden. Die unmittelbare Folge wäre, dass auch Risiken (und Sicherheiten) nicht erkannt werden und die Aussage bezüglich der Eignung einer Architektur verfälscht wird. Clements, Kazman und Klein schlagen zwar vor, die Generierung der Analysefragen durch dokumentierte Erfahrungen mit Architekturansätzen und Büchern zum Themenkomplex der Softwarearchitekturen zu unterstützen (vgl. Kapitel 3.3.2.5), jedoch kann aufgrund der Menge und Komplexität dieser Beschreibungen nicht davon ausgegangen werden, dass jedes Mit-

100

Bewertung von Softwarearchitekturen

glied des Bewertungsteams jeden dokumentierten Ansatz mit allen Details kennt und spontan entsprechende Analysefragen stellen kann. Auch ist eine detaillierte Analyse der Beschreibungen im Zusammenhang der Untersuchung der Architekturansätze nicht möglich, da der Aufwand im Kontext einer derartigen Diskussion nicht vertretbar wäre. Darüber hinaus erschweren die Struktur und der Aufbau der Pattern-Kataloge den schnellen Zugriff auf die innerhalb einer Bewertung notwendigen Informationen, wie z. B. die unterstützten Qualitätsmerkmale sowie die Sensitivitäts- und Abwägungspunkte eines Ansatzes (siehe Kapitel 1). Die Problematik der großen Abhängigkeit von den Kenntnissen und Fähigkeiten der Mitglieder des Bewertungsteams wird auch im dritten und vierten Arbeitsschritt der Methode deutlich. So hängt das „angemessene“ Abstraktionsniveau (vgl. Arbeitsschritt 3 in Kapitel 3.3.2.5) maßgeblich von den Kenntnissen des Bewertungsteams ab. Sind die verwendeten Architekturansätze bekannt, kann die Architektur sehr effizient von dem Architekten bzw. Architekturteam vorgestellt werden. Ist z. B. kein einziger Ansatz bekannt, ist eine Vorstellung der Architektur im vorgesehenen Rahmen nicht möglich. Analog können die innerhalb der Architektur verwendeten Ansätze bei einem entsprechenden Kenntnisstand des Bewertungsteams sehr schnell identifiziert werden, wohingegen die Identifikation bei einer mangelnden Kenntnis der Architekturansätze sehr zeitaufwändig sein kann (vgl. Arbeitsschritt 4 in Kapitel 3.3.2.5).

3.4

Zusammenfassung

Die Entwurfsentscheidungen innerhalb der Softwarearchitektur beeinflussen maßgeblich die Qualität eines Systems (vgl. Kapitel 3.1). Das Ziel der Bewertung von Softwarearchitekturen ist es, die Beziehungen zwischen den Entwurfsentscheidungen innerhalb der Architektur und deren Auswirkungen auf die Qualität eines Systems systematisch zu untersuchen, zu verstehen und zu bewerten, um so eine Vorhersage der Qualität des gesamten Systems zu ermöglichen. Die Kenntnis der Beziehungen ermöglicht einen gezielten Entwurf einer Softwarearchitektur im Hinblick auf die spezifizierten Qualitätsanforderungen. In diesem Kontext ist zu beachten, dass es keine „gute“ oder „schlechte“ Softwarearchitektur gibt, sondern eine Softwarearchitektur ist für einen definierten Einsatzbereich, der durch die jeweiligen Anforderungen spezifiziert wird, mehr oder weniger geeignet. Die Bewertung einer Softwarearchitektur beabsichtigt daher im Wesentlichen, eine Aussage über den Grad der Erfüllung der spezifizierten Anforderungen zu treffen. Die Grundlage für die Bewertung eines Softwareprodukts bzw. einer Softwarearchitektur ist ein zugrunde liegendes Qualitätsmodell, das das Konzept der Qualität operationalisiert, indem Qualitätsmerkmale und Metriken strukturiert und definiert werden (vgl. Kapitel 3.2.2.1). Problematisch ist die (noch) mangelnde detaillierte Kenntnis der Beziehungen zwischen den Qualitätsmerkmalen und den Metriken, d. h., die Frage, welche Menge von Metriken ver-

Zusammenfassung

101

wendet und wie die Ergebnisse interpretiert werden müssen, um eine bestimmte Aussage bezüglich eines Qualitätsmerkmal treffen zu können (vgl. Kapitel 3.2.2.3). Darüber hinaus wird nicht in allen Qualitätsmodellen der entsprechende Kontext berücksichtigt, der es erst ermöglicht, aussagekräftigen Anforderungen zu spezifizieren (vgl. Kapitel 3.2.2.3). Der ISO/IEC 9126-Standard definiert ein Qualitätsmodell, das durch eine einheitliche Struktur und Terminologie für die Qualität von Softwareprodukten die Kommunikation im Kontext der Softwareprodukt-Qualität wesentlich vereinfacht und eine Überprüfung der Vollständigkeit der Qualitätsanforderungen ermöglicht (vgl. 3.2.3.1). Das Modell beinhaltet allerdings auch die grundsätzlichen Probleme der Qualitätsmodelle, d. h., den fehlenden Bezug zwischen Metriken und Teilmerkmalen sowie den fehlenden Kontext, der die Formulierung von aussagekräftigen Anforderungen ermöglicht. Das Qualitätsmodell des Software Engineering-Instituts betrachtet ausschließlich die Ebene der Softwarearchitektur und greift insbesondere die Problematik der Definition von aussagekräftigen Anforderungen auf, indem neben der Definition von hierarchischen Qualitätsmerkmalen auf drei Abstraktionsebenen (vgl. Kapitel 3.2.4.2), dass Modell der QualitätsmerkmalSzenarios (vgl. Kapitel 3.2.4.3) eingeführt wurde. Die Qualitätsmerkmale sind nicht so detailliert wie im ISO/IEC 9126-Standard beschrieben, jedoch bieten die Qualitätsmerkmal-Szenarios einen konzeptuellen Rahmen für die Formulierung von Qualitätsanforderungen, der z. B. in zahlreichen Bewertungsmethoden wiederverwendet wird (vgl. Kapitel 3.3.1). Im Vergleich zum Qualitätsmodell des ISO/IEC 9126-Standards sind entsprechende Metriken, die zur Überprüfung der Szenarios verwendet werden können, nicht Bestandteil des Qualitätmodells. Zur Strukturierung der Bewertung einer Softwarearchitektur wurde eine Vielzahl von Bewertungsmethoden entwickelt, die die Untersuchung, das Verständnis und die Bewertung der Beziehungen zwischen den Entwurfsentscheidungen und den Qualitätsmerkmalen durch entsprechende Konzepte, Modelle und Vorgehensweisen unterstützen (vgl. Kapitel 3.3.1). Die Architecture Tradeoff Analysis-Methode, die aufgrund ihrer hohen Relevanz in Wissenschaft und Praxis im Detail und stellvertretend für die szenario-basierten Bewertungsmethoden erläutert wurde (vgl. Kapitel 3.3.2), beschreibt eine derartige strukturierte Vorgehensweise zur Bewertung von Softwarearchitekturen. In der Methode werden, ausgehend von dem Kontext und den zugrunde liegenden Geschäftszielen eines Systems, die Qualitätsanforderungen systematisch erfasst und den Ansätzen, die innerhalb der Architektur verwendet wurden, gegenübergestellt (vgl. Kapitel 3.3.2). Die Anwendbarkeit und der Erfolg der Methode hängen jedoch stark von den Kenntnissen und Erfahrungen der beteiligten Architekten bzw. des Bewertungsteams ab (vgl. Kapitel 3.3.2.7). Die wesentlichen Schritte der Methode, die die Untersuchung der Architekturansätze auf Basis von Analysefragen beinhalten, können nur erfolgreich ausgeführt werden, wenn innerhalb des Bewertungsteams ausreichende Kenntnisse bezüglich der Architekturansätze vor-

102

Bewertung von Softwarearchitekturen

handen sind. Anderenfalls besteht die Gefahr, dass z. B. Schwächen, Sensitivitäts- und Abwägungspunkte übersehen und deshalb Risiken nicht erkannt werden. Die Verwendung von dokumentierten Erfahrungen mit Architekturansätzen und/oder Pattern-Katalogen kann im Rahmen eines Bewertungsprozesses die mangelnden Kenntnisse des Bewertungsteams nicht vollständig kompensieren, da der Aufwand für den Zugriff auf die relevanten Informationen aufgrund der Struktur und des Aufbaus der Pattern-Kataloge zu groß wäre.

4 Pattern im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen 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 PatternDokumentation 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

104

Pattern im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen

ä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]). Gamma, Helm, Johnson und Vlissides weisen darauf hin, dass sich derartiges Entwurfswissen bereits in vielen objekt-orientiert entwickelten Systemen befindet (vgl. [GHJV1995, S. 1]). Das Ziel ihres Buchs Design Patterns – Elements of Reusable Object-Oriented Software (siehe [GHJV1995]) war deshalb, dieses Entwurfswissen in Form von sog. Entwurfs-Pattern (design pattern) systematisch zu dokumentieren, so dass Entwickler dieses Wissen effektiv und effizient wiederverwenden können (vgl. [GHJV1995. S. 2]).

4.1.1 Begriffsdefinitionen und Bezugsrahmen Das Pattern-Konzept wurde durch einen Vergleich des Entwicklungsstands der Softwareentwicklung mit anderen Ingenieurdisziplinen motiviert (vgl. [BMRS1996, S. 2). Es kann als eine Lösung für die von Shaw und Garlan aufgezeigte Kritik an der grundsätzlichen Vorgehensweise innerhalb der Softwareentwicklung (vgl. Kapitel 4.1) gesehen werden. Gamma, Helm, Johnson und Vlissides griffen bei der Erforschung der Problematik, in Anlehnung an andere Disziplinen, auf die Arbeiten zurück, die im Umfeld des Architekturprofessors Christopher Alexander entstanden sind (vgl. [GHJV1995. S. 2 f.]). Alexander, Ishikawa, Silverstein et al. hatten das Konzept der Pattern in Bezug auf die Gestaltung von Gebäuden und Städten entwickelt und wie folgt beschrieben:

Konzept der Pattern

105

„Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing the same way twice.“ [AISJ1977, S. x]. Gamma, Helm, Johnson und Vlissides transformierten den Kern dieses Konzepts auf die objekt-orientierte Softwareentwicklung, d. h., im Fokus stehen keine Wände und Türen, sondern Objekte und Schnittstellen (vgl. [GHJV1995. S. 2 f.]). Sie definieren ein Entwurfs-Pattern (design pattern) wie folgt: "Each design pattern systematically names, explains, and evaluates an important and recurring design in object-oriented systems." [GHJV1995, S. 2]. Ein Entwurfs-Pattern besteht nach Gamma, Helm, Johnson und Vlissides aus den folgenden Bestandteilen [GHJV1995, S. 3]: ƒ Ein Pattern-Name, der ein Entwurfsproblem, zusammen mit der Lösung und den ent-

sprechenden Konsequenzen, mit ein oder zwei Wörtern beschreibt. ƒ Eine Beschreibung des Problems, das mit Hilfe des Pattern gelöst werden kann. Die

Problembeschreibung erläutert den Kontext, in dem die Verwendung des Pattern sinnvoll ist, z. B., indem eine Liste von Bedingungen dokumentiert wird, die zur Anwendung des Pattern erfüllt sein müssen. ƒ Die Lösung des Problems, die die zugehörigen Elemente und deren Zusammenspiel um-

fasst. Die Lösung wird auf einem hohen Abstraktionsniveau, d. h., unabhängig von einem konkreten Entwurf oder einer Implementierung im Quellcode, beschrieben. Sie ist eine Art „Schablone“, die in vielen Situationen angewendet werden kann. ƒ Die Konsequenzen der Verwendung des Pattern, die die Ergebnisse und Abwägungen

des Einsatzes umfassen. Die Konsequenzen sind die Grundlage für einen bewertenden Vergleich von Pattern und für das Verständnis der Vor- und Nachteile, die beim Einsatz des Pattern entstehen. Gamma, Helm, Johnson und Vlissides weisen explizit darauf hin, dass sie innerhalb ihres Buches keine neuen oder unerprobten Entwürfe dokumentiert haben (vgl. [GHJV1995, S. 2]). Es wurden ausschließlich Entwürfe betrachtet, die in mehreren unterschiedlichen Systemen angewendet, aber zuvor noch nicht eigenständig dokumentiert worden sind. Darüber hinaus diskutieren sie die unterschiedlichen Abstraktionsebenen auf denen Pattern identifiziert werden können (vgl. [GHJV1995, S. 3 f.]). Demnach handelt es sich bei den Entwurfs-Pattern nicht um Entwürfe auf dem Abstraktionsniveau von z. B. verketteten Listen oder sog. Hash-Tables, die in einzelnen Klassen implementiert und einfach wiederverwendet werden können. Es handelt sich auch nicht um komplexe und/oder domänen-spezifische Entwürfe, die ganze Systeme oder Teile davon beschreiben. Bei einem Entwurfs-Pattern nach

106

Pattern im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen

Gamma, Helm, Johnson und Vlissides handelt es sich vielmehr um die Beschreibung von kommunizierenden Objekten und Klassen, die zur Lösung eines allgemeinen Entwurfsproblems in einem bestimmten Kontext angepasst werden [GHJV1995, S. 3]. Im Fokus eines Entwurfs-Pattern stehen die beteiligten Klassen und Instanzen, sowie deren Rollen und Verantwortlichkeiten. Die Pattern beschreiben objekt-orientierte Entwürfe, wobei sie unabhängig von einer spezifischen objekt-orientierten Programmiersprache sind. Gamma, Helm, Johnson und Vlissides gehen davon aus, dass viele der Pattern auch in einer strukturierten Programmiersprache umgesetzt werden können (vgl. [GHJV1995, S. 4]). Shaw und Garlan dagegen verwenden das Konzept der Pattern, um das Entwurfswissen auf der Ebene der Softwarearchitektur zu erfassen und zu strukturieren (vgl. Kapitel 2.1). Unter dem Begriff des Architektur-Stils dokumentierten sie Entwurfswissen über die Anordnung und das Zusammenspiel der einzelnen Elemente einer Softwarearchitektur, das innerhalb der Entwicklung von zahlreichen Systemen gewonnen wurde (vgl. [ShGa1996, S. 19 ff.]). Buschmann, Meunier, Rohnert et al. betrachten ebenfalls das Konzept der Pattern auf der Ebene der Softwarearchitektur (siehe [BMRS1996]) und definieren den Pattern-Begriff wie folgt: „An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.” [BMRS1996, S. 12]. Zu den Bestandteilen eines Pattern zählen sie – in Anlehnung an Gamma, Helm, Johnson und Vlissides – eine Beschreibung des zugrunde liegenden Problems, die erprobte Lösung des Problems und die entsprechenden Konsequenzen des Pattern, deren Beschreibung sie allerdings als Teil der Lösungsbeschreibung sehen (vgl. [BMRS1996, S. 8-11]). Dieser konzeptuelle Rahmen wird auch von Schmidt, Stal, Rohnert und Buschmann sowie Kirchner und Jain verwendet, die aufbauend auf der Arbeit von Buschmann, Meunier, Rohnert et al. weitere Entwurfs- und Architektur-Pattern dokumentiert haben (siehe [SSRB2000; KiJa2004]). Die Dokumentation von Entwurfswissen kann auch auf Basis von sog. Referenzmodellen und Referenzarchitekturen erfolgen. Das Pattern-Konzept muss deshalb von dem Konzept der Referenzmodelle und Referenzarchitektur abgegrenzt werden. Ein Referenzmodell ist eine standardisierte Aufteilung der Funktionalität im Kontext eines bekannten Problems (vgl. [BaCK2003, S. 25]). Es ist wesentlich abstrakter als die Softwarearchitektur eines spezifischen Systems und daher eine Beschreibung für ganze Klassen von Systemen, wie z. B. Compiler oder Datenbankmanagementsysteme. Ein Referenzmodell enthält alle möglichen Funktionen und Eigenschaften, die durch ein System dieser Klasse implementiert werden können (vgl. [Somm2004, S. 261]). Es definiert ein Vokabular, das insbesondere bei einem Vergleich von Softwareprodukten verwendet werden kann, um Gemeinsam-

Konzept der Pattern

107

keiten und Unterschiede aufzuzeigen, sowie die Vollständigkeit der Funktionalität zu überprüfen. Ein Beispiel ist das sog. ISO/OSI-Referenzmodell, das die grundlegenden Funktionen und Eigenschaften der Kommunikation in offenen Systemen beschreibt (siehe [ISIE1994]). Eine Referenzarchitektur verfeinert ein Referenzmodell, indem die Funktionen und Eigenschaften auf bestimmte Softwareelemente abgebildet werden (vgl. [BaCK2003, S. 25]). Eine Referenzarchitektur ist aber keine vollständige Softwarearchitektur, sondern primär ein Ausgangspunkt für die Diskussion und den Entwurf einer konkreten Softwarearchitektur (vgl. [BaCK2003, S. 25; Somm2004, S. 261]). Die Referenzmodelle und -architekturen berücksichtigen die entsprechenden Auswirkungen auf die Qualitätsmerkmale nur am Rande, da diese nicht im primären Fokus der beiden Konzepte stehen (vgl. z. B. [ISIE1994]). Aus diesem Grund werden sie in der vorliegenden Arbeit nicht weiter betrachtet.

4.1.2 Eigenschaften des Entwurfs auf Basis von Pattern Der Entwurf von Software auf der Basis von Pattern führt zu einer neuen Abstraktionsebene, d. h., die Pattern identifizieren und definieren Abstraktionen, die mehrere Klassen, Instanzen und/oder Softwareelemente umfassen und durch den Namen eines Pattern referenziert werden können (vgl. [GHJV1995, S. 3; BMRS1996, S. 6]). Pattern erweitern somit das Entwurfsvokabular eines Designers bzw. Entwicklers und können deshalb auch innerhalb der Dokumentation einer Softwarearchitektur (vgl. Kapitel 2.5) verwendet werden. Die neue Abstraktionsebene der Pattern führt zu einer Reduktion der Komplexität, da bei der Betrachtung eines Pattern von den einzelnen Klassen, Instanzen und Softwareelementen sowie deren Beziehungen und Interaktionen abstrahiert werden kann (vgl. [GHJV1995, S. 3; BMRS1996, S. 6]). Pattern unterstützen deshalb die Entwicklung von komplexen Softwaresystemen, wenn sie als „Entwurfsbausteine“ verwendet werden, die die Basis für einen umfassenden Entwurf bilden. Dabei ist aber zu beachten, dass Pattern – analog zu den Konzepten der Referenzmodelle und Referenzarchitekturen (vgl. Kapitel 4.1.1) – keine vollständigen Lösungen darstellen, d. h., Pattern können nicht, wie z. B. eine Klassen- oder Funktionsbibliothek, unmittelbar wiederverwendet werden, sondern müssen stets im Kontext eines spezifischen Problems implementiert werden (vgl. [BMRS1996, S. 6]). Da Pattern keine neuen, sondern existierende und erprobte Entwürfe darstellen, die in mehreren unterschiedlichen Systemen erfolgreich angewendet wurden (vgl. Kapitel 4.1.1), können auch die Auswirkungen eines Pattern auf die Qualitätsmerkmale eines Systems (vgl. Kapitel 3.2.2) beschrieben werden. Da Pattern aber abstrakte und keine vollständigen Lösungen darstellen, können die Auswirkungen auf die Qualitätsmerkmale lediglich qualitativ beschrieben werden.

108

Pattern im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen

Pattern sind Bausteine eines Entwurfs, die die Implementierung der Funktionalität eines Systems lediglich unterstützen (vgl. [BMRS1996, S. 7]). Eine Beschreibung der Auswirkungen eines Pattern kann nur für die nicht-funktionalen Qualitätsmerkmale eines Systems (vgl. Kapitel 3.2.2.2), wie z. B. die Wartbarkeit oder Effizienz, erfolgen. Dennoch können Pattern verwendet werden, um bereits innerhalb der Entwurfsphase – in der noch keine quantitativen Messungen möglich sind (vgl. Kapitel 3.2.2.3) – die Erreichung der Qualitätsanforderungen zu steuern und zu kontrollieren. Durch ihren Einsatz können z. B. die Auswirkungen auf die Qualitätsmerkmale besser nachvollziehbar und/oder mehrere Entwurfsalternativen verglichen werden. Sie unterstützen deshalb die Entwicklung von „qualitativhochwertiger“ Software, d. h., Software deren Qualitätseigenschaften in einem hohen Maß den Qualitätsanforderungen entspricht (vgl. Kapitel 3.2.2.1). Es ist aber zu beachten, dass der Einsatz von Pattern keine Garantie für die Qualität des gesamten Systems ist, da zum einen Pattern lediglich Entwurfsbausteine darstellen und zum anderen – analog zur Annahme der Bewertung von Softwarearchitekturen (vgl. Kapitel 3.1) – ein „guter“ Entwurf eines Pattern durch eine „schlechte“ Implementierung „untergraben“ werden kann.

4.1.3 Positionierung des Pattern-Konzepts Das Pattern-Konzept wurde von Gamma, Helm, Johnson und Vlissides zunächst auf der Abstraktionsebene von Objekten und Klassen angewendet (vgl. Kapitel 4.1.1). Die Pattern, die Gamma, Helm, Johnson und Vlissides dokumentierten, wurden als Entwurfs-Pattern bezeichnet, um das Abstraktionsniveau der Pattern oberhalb einer objekt-orientierten Programmiersprache zu verdeutlichen. Andere Autoren, wie z. B. Shaw und Garlan sowie Buschmann, Meunier, Rohnert et al., betrachteten das Konzept der Pattern auf der Abstraktionsebene der Softwarearchitektur und bezeichneten diese Pattern als architektur-bezogene Pattern, Architektur-Pattern bzw. Architektur-Stile (vgl. Kapitel 4.1.1). Diese beiden Typen von Pattern unterscheiden sich lediglich durch ihr unterschiedliches Abstraktionsniveau. Zur Positionierung des Pattern-Konzepts müssen sie aber von weiteren Konzepten abgegrenzt werden (siehe Abbildung 4-1). Das oberste Abstraktionsniveau stellen die fundamentalen Prinzipien der Softwareentwicklung dar. Diese Prinzipien wurden bereits in den 70er Jahren u. a. von Parnas im Kontext der strukturierten Programmierung identifiziert und dokumentiert (vgl. Kapitel 2.1). Sie haben noch heute Bestand und sind auch für die objekt-orientierte Softwareentwicklung relevant. Zu diesen Prinzipien gehören z. B. die Abstraktion, die Kapselung, das Information Hiding, die Modularisierung, die Kopplung und Kohäsion sowie die Trennung von Schnittstelle und Implementierung (vgl. z. B. [BMRS1996, S. 397 ff.]). Die Prinzipien definieren grundlegende Richtlinien für die Entwicklung von Software und haben keinen konkreten Bezug zu den Softwareelementen einer Softwarearchitektur und einzel-

Konzept der Pattern

109

nen Modulen, Klassen oder Instanzen. Sie stellen keine abstrakte Lösung eines Entwurfsproblems dar, sondern definieren Regeln, die grundsätzlich im Rahmen des Entwurfsprozesses beachtet werden sollten, um bestimmte allgemeine Qualitätsanforderungen, wie z. B. die Wartbarkeit eines Softwareprodukts, zu gewährleisten. Viele Pattern basieren auf diesen fundamentalen Prinzipien und einige fokussieren sich auf einzelne Prinzipien (vgl. [BMRS1996, S. 398]). Sie verfeinern die fundamentalen Prinzipien der Softwareentwicklung zu abstrakten Lösungen.

Abbildung 4-1: Positionierung des Pattern-Konzepts

Bass, Clements und Kazman dokumentieren im Kontext des Entwurfs von Softwarearchitekturen sog. Taktiken (tactics), die grundlegende Entwurfsentscheidungen auf der Ebene der Softwarearchitektur darstellen und die Qualitätsmerkmale eines Systems wesentlich beeinflussen (vgl. [BaCK2003, S. 99 ff.]). Eine grundlegende Taktik zur Erhöhung der Fehlertoleranz (vgl. Kapitel 3.2.3.5) eines Systems ist z. B. die Vorhaltung von redundanten Hard- und/oder Softwareelementen und die automatische Erkennung von Ausfällen (vgl. [BaCK2003, S. 101]). Eine grundlegende Taktik zur Erhöhung der Wartbarkeit (vgl. Kapitel 3.2.3.5) eines Systems ist z. B. die erwarteten Änderungen auf eine möglichst kleine Menge von Softwareelementen bzw. Modulen zu limitieren (vgl. [BaCK2003, S. 106 f.]).

110

Pattern im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen

Taktiken sind konkreter als die fundamentalen Prinzipien, da sie einen speziellen Fokus auf die Softwarearchitektur haben und in diesem Kontext grundlegende Entwurfsentscheidungen mit den entsprechenden Auswirkungen auf die Qualitätsmerkmale des Systems definieren. Analog zu den fundamentalen Prinzipien der Softwareentwicklung stellen die Taktiken allerdings keine vollständigen Lösungen dar und beziehen sich nicht auf konkrete Elemente einer Softwarearchitektur. Die Pattern auf der Ebene der Architektur und der Ebene des Entwurfs verfeinern die Taktiken, wobei ein Pattern i. d. R. mehrere Taktiken implementiert, was Bass, Clements und Kazman am Beispiel des sog. Active Object-Pattern (vgl. [SSRB2000, S. 369]) erläutern. Sie stellen in diesem Kontext dar, dass ein Pattern mehrere Taktiken „verpacken“ kann (vgl. [BaCK2003, S. 100, 123 f.]). Die sog. Idiome sind Pattern auf einer niedrigeren Abstraktionsebene und haben einen engen Bezug zu einer spezifischen Programmiersprache (vgl. [BMRS1996, S. 14 f.]). Sie beschreiben wie bestimmte Aspekte von Elementen oder deren Beziehungen mit den Fähigkeiten einer spezifischen Programmiersprache realisiert werden und beziehen sich sowohl auf den Entwurf als auch die Implementierung. Ein Beispiel für ein Idiom ist eine Vorgehensweise für die Verwaltung von Referenzen dynamisch vergebener Speicherbereiche auf Basis der Programmiersprache C++ (vgl. [BMRS1996, S. 14]). Die Idiome sind konkreter als Entwurfs-Pattern, da sie einen engen Bezug zu einer konkreten Programmiersprache haben. Sie sind aber abstrakter als Quellcode, da sie Konzepte und Vorgehensweisen spezifizieren, die oberhalb der Elemente einer Programmiersprache einzuordnen sind.

4.2

Dokumentation von Pattern

Die Qualität der Pattern-Dokumentation ist ein entscheidender Erfolgsfaktor des Pattern-Konzepts. Die Struktur und der Aufbau dieser Dokumentation definiert, wieviel Entwurfswissen innerhalb eines Pattern beschrieben wird und insbesondere, wie effizient der Zugriff auf dieses Wissen erfolgen kann. Pattern werden grundsätzlich in einer Textform beschrieben und i. d. R. in sog. Pattern-Katalogen zusammengefasst. Sie können durch zusätzliche Diagramme in unterschiedlichen Notationen ergänzt werden. Um den Zugriff auf die Pattern-Dokumentation zu erleichtern, wird der Text innerhalb eines Katalogs auf Basis einer einheitlichen sog. Pattern-Schablone strukturiert (siehe Kapitel 4.2.1). Pattern-Klassifikation (siehe Kapitel 4.2.2) und -Sprachen (siehe Kapitel 4.2.3) sollen die Menge der Pattern strukturieren und die Auswahl eines Pattern im Kontext des Entwurfs (siehe Kapitel 4.3) unterstützen.

Dokumentation von Pattern

111

Die folgende Untersuchung der Pattern-Schablonen, -Klassifikationen, -Sprachen und -Auswahlprozesse erfolgt aufgrund der mittlerweile großen Anzahl von Pattern und Pattern-Katalogen schwerpunktmäßig auf Basis von ausgewählten Beispielen. Diese Beispiele umfassen die Pattern-Kataloge von Gamma, Helm, Johnson und Vlissides (siehe [GHJV1995]) und Alur, Crupi und Malks (siehe [AlCM2003]) sowie die drei Bände der sog. Pattern-Oriented Software Architecture (POSA)-Serie (siehe [BMRS1996; SSRB2000; KiJa2004]). Die Auswahl erfolgte aufgrund des großen Bekanntheitsgrads der Kataloge und der relativ geringen Überschneidungen zwischen den Problembereichen der Pattern (siehe Kapitel 4.2.2). Daneben existieren weitere Pattern-Kataloge (siehe z. B. [Fowl2003; HoWo2004]) und eine Vielzahl weiterer Pattern, die (zunächst) unabhängig von einem Katalog dokumentiert worden sind. Weitere wesentliche Quellen in diesem Kontext sind die Tagungsbände der verschiedenen sog. Pattern Languages of Programs (PLoP)-Konferenzen26, die das primäre Ziel haben, die Pattern-Dokumentation und -Sprachen zu verbessern. Ausgewählte Pattern und Pattern-Sprachen, die bereits während der PLoP-Konferenzen diskutiert und validiert worden sind, werden in der sog. Software Pattern-Serie veröffentlicht (siehe z. B. [MaVN2006; HaFR2000]).

4.2.1 Konzept der Pattern-Schablonen Pattern werden i. d. R. nicht einzeln, sondern innerhalb von sog. Pattern-Katalogen dokumentiert (vgl. Kapitel 4.2). Ein Pattern-Katalog definiert für die Dokumentation, der in ihm beschriebenen Pattern, eine sog. Pattern-Schablone. Sie strukturiert die einzelnen Pattern-Dokumentationen, indem sie den Text der Dokumentation in Abschnitte gliedert. Eine einheitliche Pattern-Schablone soll den Zugriff auf die Pattern-Dokumentation erleichtern und den Vergleich von verschiedenen Pattern unterstützen (vgl. [GHJV1995, S. 6; BMRS1996, S. 19]). Im Folgenden werden zunächst die Pattern-Schablonen der ausgewählten Pattern-Kataloge untersucht (siehe Kapitel 4.2.1.1) und anschließend bewertet (siehe Kapitel 4.2.1.2).

4.2.1.1 Untersuchung ausgewählter Pattern-Schablonen Gamma, Helm, Johnson und Vlissides verwenden z. B. zur Dokumentation der EntwurfsPattern eine Pattern-Schablone, die aus 13 Abschnitten besteht. Die Abschnitte werden in Tabelle 4-1 erläutert (vgl. [GHJV1995, S. 6 f.]).

26

Siehe http://hillside.net/conferences/

112

Pattern im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen

Abschnitt

Beschreibung der Abschnitts

Pattern Name and Classification

Der Name des Pattern, der den Kern des Pattern wiedergeben soll. Die Klassifikation ist eine Referenz auf die spezielle Pattern-Klassifikation des Katalogs (siehe Kapitel 4.2.2).

Intent

Eine kurze Aussage zur Motivation und dem zugrunde liegenden Problem des Pattern.

Also Known As

Weitere bekannte Namen des Pattern, sofern diese vorhanden sind.

Motivation

Ein Szenario, das das Entwurfsproblem und die Lösung auf Basis von Klassen- und Objektstrukturen kurz skizziert.

Applicability

Die Situationen, in denen das Pattern angewendet werden kann und Beispiele von schlechten Entwürfen, die mit dem Pattern verbessert werden können.

Structure

Eine grafische Darstellung der Klassen und Beziehungen des Pattern sowie deren Interaktionen. Die statischen Beziehungen zwischen den Klassen werden auf Basis der Notation der sog. Object Modeling Language dargestellt (vgl. [RBPE1991]). Die dynamischen Interaktionen werden auf Basis von sog. Interaktionsdiagrammen veranschaulicht (vgl. [JCJO1992; Booc1994]).

Participants

Die Klassen und/oder Objekte, die Teil des Pattern sind, sowie ihre Verantwortlichkeiten.

Collaborations

Eine Beschreibung, wie die Klassen und/oder Objekte zusammenarbeiten, um ihre Verantwortlichkeiten wahrzunehmen.

Consequences

Die Art und Weise wie ein Pattern seine Ziele verfolgt. Darüber hinaus sind die Abwägungen und Ergebnisse des Einsatzes des Pattern in diesem Abschnitt dokumentiert.

Implementation

Die Fallstricke, Hinweise und Techniken, die bei der Implementierung des Pattern beachtet werden sollten.

Sample Code

Quellcode-Fragmente, die darstellen, wie das Pattern in C++ oder Smalltalk implementiert werden könnte.

Known Uses

Mindestens zwei Beispiele für den Einsatz des Pattern aus unterschiedlichen Anwendungsbereichen.

Related Patterns

Die Beziehungen zu anderen Pattern, d. h. verwandte oder alternative Pattern.

Tabelle 4-1: Pattern-Schablone nach Gamma, Helm, Johnson und Vlissides Quelle: in Anlehung an [GHJV1995, S. 6 f.]

Buschmann, Meunier, Rohnert et al. definieren eine Pattern-Schablone, die aus insgesamt 14 Abschnitten besteht (vgl. [BMRS1996, S. 19-21]). Die Struktur der Schablone wird in Tabelle 4-2 zusammengefasst. Sie wird in allen drei Pattern-Katalogen bzw. Bänden der PatternOriented Software Architecture-Serie verwendet (siehe [BMRS1996; SSRB2000; KiJa2004]).

Dokumentation von Pattern

Abschnitt

113

Beschreibung der Abschnitts

Name

Der Name und eine kurze Beschreibung des Pattern.

Also Known As

Weitere bekannte Namen des Pattern, sofern diese vorhanden sind.

Example

Ein reales Beispiel, das die Existenz des zugrunde liegenden Problems und den Bedarf des Pattern darlegt.

Context

Die Situationen, in denen das Pattern angewendet werden kann.

Problem

Eine Beschreibung des Problems, das das Pattern löst, und eine Diskussion der dem Pattern zugrunde liegenden „Kräfte“, d. h. die Auswirkungen auf Qualitätsmerkmale.

Solution

Das fundamentale Prinzip der Lösung, das den Kern des Pattern darstellt.

Structure

Eine detaillierte Spezifikation der strukturellen Aspekte des Pattern, die auf sog. Class-Responsibility-Collaborator-Karten (CRC-Karten) basiert (vgl. [CuBe1989]), die für jede Komponente des Pattern dokumentiert sind. Ein Klassendiagramm auf Basis der Notation der sog. Object Modeling Language (vgl. [RBPE1991]) stellt die Klassen des Pattern im Zusammenhang dar.

Dynamics

Die typischen Szenarios, die das Verhalten des Pattern zur Laufzeit beschreiben. Als Notation werden sog. Object Message Sequence Charts verwendet (vgl. [GrGR1993]).

Implementation

Die Richtlinien zur Implementierung des Pattern, wobei diese lediglich als Vorschläge zu verstehen sind.

Example Resolved

Eine Diskussion von weiteren Aspekten des Beispiels, die noch nicht in den Abschnitten „Solution“, „Structure“, „Dynamics“ und „Implementation“ behandelt wurden.

Variants

Eine kurze Beschreibung Spezialisierungen des Pattern.

Known Uses

Beispiele für die Verwendung des Pattern.

Consequences

Die Vorteile und mögliche Anfälligkeiten des Pattern.

See Also

Referenzen zu anderen Pattern, die ähnliche Probleme lösen oder verwendet werden können, um das Pattern zu verfeinern.

der

Varianten

oder

Tabelle 4-2: Pattern-Schablone der Pattern-Oriented Software Architecture-Serie Quelle: in Anlehung an [BMRS1996, S. 19-21]

Alur, Crupi und Malks definieren eine Pattern-Schablone (siehe Tabelle 4-3), die lediglich aus neun Abschnitten besteht (vgl. [AlCM2003, S. 129 f.]).

114

Pattern im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen

Abschnitt

Beschreibung der Abschnitts

Problem

Eine Beschreibung des Entwurfsproblems.

Forces

Eine Auflistung der Gründe und Motive, die das Problem und die Lösung beeinflussen. Diese Liste der Kräfte betont die Gründe für die Auswahl des Pattern und stellt eine Rechtfertigung für die Auswahl des Pattern dar.

Solution

Eine kurze Skizzierung des Lösungsansatzes und der Elemente der Lösung. Dieser Abschnitt enthält die beiden folgenden Unterabschnitte „Structure“ und „Strategies“.

Structure

Die grundlegende Struktur der Lösung auf Basis von Klassendiagrammen der UML (vgl. [OMG2004]).

Participants and Collaborations27

Die dynamischen Aspekte der Lösung auf Basis von Sequenzdiagrammen der UML (vgl. [OMG2004]).

Strategies

Eine Darstellung der möglichen Strategien, die innerhalb der Implementierung des Pattern verfolgt werden können.

Consequences

Eine Beschreibung der Abwägungen eines Pattern. In diesem Abschnitt werden gewöhnlich die Folgen des PatternEinsatzes zusammengefasst, sowie die Vor- und Nachteile des Pattern diskutiert.

Sample Code

Dieser Abschnitt enthält beispielhafte Implementierungen und Java-basierte Quellcode-Fragmente für das Pattern und seine Anwendungsstrategien.

Related Pattern

Eine Liste von Pattern, zu denen das Pattern eine Beziehung hat. Die Pattern können aus diesen oder auch anderen Katalogen stammen. Jede Beziehung wird kurz erläutert. Tabelle 4-3: Pattern-Schablone nach Alur, Crupi und Malks Quelle: in Anlehnung an [AlCM2003, S. 129 f.]

4.2.1.2 Bewertung der Pattern-Schablonen Die drei Beispiele für Pattern-Schablonen zeigen, dass zwar innerhalb der einzelnen PatternKataloge einheitliche Schablonen verwendet werden, aber keine katalog-übergreifende Pattern-Schablone existiert. Eine Ausnahme ist die Pattern-Oriented Software ArchitectureSerie, die aus drei Pattern-Katalogen besteht und innerhalb der drei Bände nur eine einheitliche Pattern-Schablone verwendet. Die Pattern-Schablonen enthalten – abgesehen von dieser Ausnahme – eine unterschiedliche Anzahl von Abschnitten, unterschiedliche Bezeichner für die Abschnitte, keine einheitlichen Inhalte innerhalb der Abschnitte und eine unterschiedliche Reihenfolge der Abschnitte. Das Entwurfsproblem und die Lösung auf Basis der zugrunde liegenden Klassen und Objektstrukturen wird z. B. innerhalb der Schablone von Gamma, Helm, Johnson und Vlissides im

27

Dieser Abschnitt wird innerhalb der Beschreibung der Pattern-Schablone nicht explizit als Abschnitt aufgeführt (vgl. [AlCM2003, S. 129]), obwohl er in der Pattern-Dokumentation konsequent genutzt wird.

Dokumentation von Pattern

115

Abschnitt „Motivation“ vorgestellt (vgl. Tabelle 4-1). Innerhalb der Schablone von Buschmann, Meunier, Rohnert et al. dagegen wird das Entwurfsproblem in dem Abschnitt „Problem“ und die zugehörige Lösung im Abschnitt „Solution“ beschrieben (vgl. Tabelle 4-2). Die Schablone von Alur, Crupi und Malks stellt das Entwurfsproblem und die Lösung in getrennten Abschnitten („Problem“ und „Solution“) dar, wobei der Abschnitt „Solution“ in weitere Abschnitte unterteilt ist, die die statischen und dynamischen Aspekte sowie Strategien der Lösung beschreiben (vgl. Tabelle 4-3). Diese Aspekte sind wiederum in den anderen beiden Schablonen in Hauptabschnitten mit anderen Bezeichnern erläutert. Die Auswirkungen auf die Qualitätsmerkmale werden von Gamma, Helm, Johnson und Vlissides innerhalb des „Consequences“-Abschnittes betrachet. Die Schablone der POSASerie enthält hierzu auch einen „Consequences“-Abschnitt, jedoch diskutieren z. B. Buschmann, Meunier, Rohnert et al. innerhalb des „Problem“-Abschnitts die „Kräfte“ des Pattern, so dass die Auswirkungen auf die Qualitätsmerkmale in mehreren Abschnitten beschrieben werden. Alur, Crupi und Malks verwenden zur Beschreibung der Auswirkungen ebenfalls den Abschnitt „Consequences“. Ihre Pattern-Schablone enthält aber auch einen Abschnitt „Forces“, der die Gründe und Motivation für den Einsatz darstellt und hier indirekt auch die Auswirkungen eines Pattern beschreibt. Die untersuchten Pattern-Kataloge verwenden bzw. referenzieren zur Beschreibung der Auswirkungen keine einheitlichen Qualitätsmerkmale und somit kein homogenes Qualitätsmodell. In den entsprechenden Abschnitten der Pattern-Dokumentation werden die Auswirkungen nicht konsequent den entsprechenden Qualitätsmerkmalen zugeordnet bzw. im Kontext eines Qualitätsmodells klassifiziert. Die Abschnitte beschreiben teilweise nur die Auswirkungen ohne den Bezug zu einem oder mehreren Qualitätsmerkmalen. Der Pattern-Katalog von Buschmann, Meunier, Rohnert et al. ist von den untersuchten Katalogen der einzige Katalog, der die Terminologie und Semantik einer Menge von Qualitätsmerkmalen explizit diskutiert (vgl. [BMRS1996, S. 404-410]). Alle anderen Pattern-Kataloge enthalten weder eine detaillierte Diskussion noch eine Definition der verwendeten Qualitätsmerkmale, sondern erwähnen die Semantik der Qualitätsmerkmale – wenn überhaupt – nur am Rande (vgl. z. B. [AlCM2003, S. 12, 117]). Da keine einheitliche Pattern-Schablone für alle Kataloge existiert, werden der katalog-übergreifende Vergleich von Pattern und die Navigation in unterschiedlichen Katalogen erschwert. Die Auswirkungen eines Pattern auf die Qualitätsmerkmale eines Systems sind teilweise über mehrere Abschnitte der Pattern-Dokumentation verteilt und referenzieren kein homogenes Qualitätsmodell mit entsprechenden Qualitätsmerkmalen. Die Analyse der Auswirkungen eines Pattern wird daher erschwert und der katalog-übergreifende Vergleich von mehreren Pattern hinsichtlich ihrer Auswirkungen ist nur mit großem Aufwand möglich. Abstrahiert man von den einzelnen Abschnitten sowie deren Bezeichnung und Reihenfolge, enthalten die Schablonen dennoch alle wesentlichen Bestandteile eines Pattern, d. h., einen

116

Pattern im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen

Pattern-Namen, eine Problem- und Lösungsbeschreibung und eine Darstellung der Konsequenzen des Pattern (vgl. Kapitel 4.1.1).

4.2.2 Konzept der Klassifikationen von Pattern Die große Anzahl der dokumentierten Pattern führt zu einer mangelnden Übersichtlichkeit und erschwert insbesondere die Suche nach einem geeigneten Pattern. Dies gilt sowohl für die Pattern, die innerhalb eines Katalogs dokumentiert sind, als auch für die gesamte Menge der dokumentierten Pattern (vgl. Kapitel 4.2). Der Pattern-Katalog von Gamma, Helm, Johnson und Vlissides enthält 23 Pattern (siehe [GHJV1995]). Alur, Crupi und Malks dokumentieren innerhalb ihres Katalogs 21 Pattern (siehe [AlCM2003]) und die gesamte Pattern-Oriented Software Architecture-Serie umfasst insgesamt 44 Pattern (siehe [BMRS1996; SSRB2000; KiJa2004])28. Rising hat im Kontext der Entwicklung einer katalog-übergreifenden Pattern-Klassifikation über 1000 dokumentierte Pattern identifiziert (siehe [Risi2000]). Eine Pattern-Klassifikation soll die Suche nach einem geeigneten Pattern und das Verständnis der Pattern eines Katalogs unterstützen (vgl. [GHJV1995, S. 9 f.]). Die Pattern-Klassifikationen der ausgewählten Pattern-Kataloge werden im Folgenden zunächst untersucht (siehe Kapitel 4.2.2.1) und anschließend bewertet (siehe Kapitel 4.2.2.2).

4.2.2.1 Untersuchung ausgewählter Pattern-Klassifikationen Gamma, Helm, Johnson und Vlissides verwenden zur Strukturierung, der von ihnen dokumentierten Entwurfs-Pattern, eine zwei-dimensionale Klassifikation, die die beiden Kriterien „Zweck“ (purpose) und „Wirkungsbereich“ (scope) umfasst (vgl. [GHJV1995, S. 10]). Der Zweck beschreibt, was ein Pattern bewirkt. Es wird zwischen einem erstellungs(creational), struktur- (creational) und verhaltens-bezogenen (behavioral) Zweck differenziert. Ein erstellungs-bezogenes Pattern bezieht sich auf den Prozess der Objekterstellung und ein struktur-bezogenes Pattern betrachtet die Zusammenstellung von Klassen oder Objekten. Ein verhaltens-bezogenes Pattern dagegen erläutert die Art und Weise, wie Klassen oder Objekte zusammenarbeiten bzw. wie die Verantwortlichkeiten zwischen den Klassen oder Objekten verteilt sind. Das Kriterium des Wirkungsbereichs unterscheidet, ob sich ein Pattern primär auf Klassen oder Objekte bezieht, d. h., es wird zwischen der Klasse (class) und dem Objekt (object) differenziert.

28

Band 1 umfasst 17, Band 2 ebenfalls 17 und Band 3 dokumentiert 10 Pattern.

Dokumentation von Pattern

117

In Tabelle 4-4 wird die Klassifikation und die Einordnung der Entwurfs-Pattern nach Gamma, Helm, Johnson und Vlissides dargestellt.

Purpose Creational Scope

Structural

Behavioral

Class

Factory Method

Adapter (class)

Interpreter, Template Method

Object

Abstract Factory, Builder, Prototype, Singleton

Adapter (object), Bridge, Composite, Decorator, Facade, Flyweight, Proxy

Chain of Responsibility, Command, Iterator, Mediator, Memento, Observer, State, Strategy, Visitor

Tabelle 4-4: Klassifikationsschema nach Gamma, Helm, Johnson und Vlissides Quelle: in Anlehnung an [GHJV1995, S. 10]

Buschmann, Meunier, Rohnert et al. verwenden ebenfalls eine zwei-dimensionale Klassifikation zur Strukturierung der von ihnen dokumentierten Pattern (vgl. [BMRS1996, S. 363 ff.]). Sie verwenden zur Klassifikation der Pattern das Abstraktionsniveau eines Pattern (vgl. Kapitel 4.1.3) und eine Menge von Problembereichen. Sie weisen explizit darauf hin, dass ihr Klassifikationsschema hinsichtlich beider Dimensionen erweiterbar ist, d. h., es können neue Abstraktionsniveaus und Problembereiche hinzugefügt werden (vgl. [BMRS1996, S. 366, 379]). Diese Erweiterbarkeit der Klassifikation wird genutzt, um die Entwurfs-Pattern von Gamma, Helm, Johnson und Vlissides zu integrieren, indem die Klassifikation um weitere Problembereiche ergänzt wird. Die Tabelle 4-5 zeigt das Ergebnis dieser Integration, d. h., eine Klassifikation, die die Pattern beider Kataloge umfasst. Die Entwurfs-Pattern von Gamma, Helm, Johnson und Vlissides wurden innerhalb der erweiterten Menge der Problembereiche eingeordnet und zur Abgrenzung innerhalb der Tabelle in kursiver Schrift erfasst.

118

Pattern im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen

Architectural Patterns From Mud to Structure

Layers, Pipes and Filters, Blackboard

Distributed Systems

Broker, Pipes and Filters, Microkernel

Interactive Systems

Model-View-Controller, PresentationAbstraction-Control

Adaptable Systems

Microkernel, Reflection

Creation

Structural Decomposition Organization of Work

Design Patterns Interpreter

Abstract Factory, Prototype, Builder

Master-Slave, Chain of Responsibility, Command, Mediator, Proxy, Facade, Iterator

Service Variation

Brigde, Strategy, State

Service Extension

Decorator, Visitor

Adaptation Communication

Resource Handling

Singleton, Factory Method

Whole-Part, Composite

Access Control

Management

Idioms

Template Method

Command Processor, View Handler, Memento Adapter Publisher-Subscriber, Forwarder-Receiver, Client-DispatcherServer Flyweight

Counted Pointer

Tabelle 4-5: Klassifikationsschema nach Buschmann, Meunier, Rohnert et al. Quelle: in Anlehnung an [BMRS1996, S. 380]

Schmidt, Stal, Rohnert und Buschmann verwenden im zweiten Band der Pattern-Oriented Software Architecture-Serie eine Klassifikation, die ebenfalls das Abstraktionsniveau eines

Dokumentation von Pattern

119

Pattern und verschiedene Problembereiche verwendet, um die Menge der Pattern zu strukturieren. Die Menge der Problembereiche unterscheidet sich von der Klassifikation von Buschmann, Meunier, Rohnert et al., da die Pattern insgesamt einen anderen Anwendungsbereich fokussieren. Schmidt, Stal, Rohnert und Buschmann dokumentieren eine Klassifikation für die Strukturierung von Pattern für nebenläufige und verteilte Objekte (vgl. [SSRB2000, S. 524-526]). Für diesen Anwendungsbereich haben sie entsprechende Problembereiche identifiziert und in die Klassifikation aufgenommen. Innerhalb der Klassifikation werden die von ihnen und anderen Autoren dokumentierten Pattern eingeordnet (siehe [SSRB2000, S. 525]). Kircher und Jain dokumentieren im dritten Band der Pattern-Oriented Software ArchitectureSerie keine explizite Klassifikation (siehe [KiJa2004]). Die Pattern-Dokumentationen sind nach den typischen Lebensphasen einer Ressource in die Kapitel „Resource Acquisition“, „Resource Lifecycle“ und „Resource Release“ strukturiert. In einem der einführenden Kapitel gruppieren sie die Pattern des Katalogs entsprechend der unterstützten Qualitätsmerkmale und skizzieren, wie diese Unterstützung erfolgt (vgl. [KiJa2004, S. 10-12]).

Presentation Tier

Business Tier

Integration Tier

Intercepting Filter, Front Controller, Context Object, Application Controller, View Helper, Composite View, Service to Worker, Dispatcher View, Business Delegate, Service Locator, Session Facade, Application Service, Business Object, Composite Entity, Transfer Object, Transfer Object Assembler, Value List Handler Data Access Object, Service Activator, Domain Store, Web Service Broker

Tabelle 4-6: Klassifikationsschema nach Alur, Crupi und Malks Quelle: in Anlehnung an [AlCM2003, S. 13]

Alur, Crupi und Malks verwenden eine eindimensionale Klassifikation zur Strukturierung der von ihnen dokumentierten Pattern (vgl. Tabelle 4-6).

120

Pattern im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen

Sie benutzen als Kriterium eine funktionale Einteilung einer Softwarearchitektur in die logischen Schichten der Präsentation, Geschäftslogik und Integration (vgl. [AlCM2003, S. 1113]). Jedes Pattern wird innerhalb einer dieser drei Schichten eingeordnet (vgl. Tabelle 4-6).

4.2.2.2 Bewertung der Pattern-Klassifikationen Die Beispiele verdeutlichen, dass innerhalb der Pattern-Kataloge keine einheitliche Klassifikation verwendet wird. In einzelnen Katalogen werden zwar erweiterbare Klassifikationsschemata spezifiziert und auch Pattern anderer Kataloge in die Klassifikationen integriert, aber es werden nur einzelne Pattern-Kataloge in der Klassifikation berücksichtigt. Daneben gibt es weitere Arbeiten, die ausschließlich die katalog-übergreifende Klassifikation von Pattern betrachten (siehe z. B. [Risi2000; Tich1997]). Diese Arbeiten beinhalten verschiedene Klassifikationen auf Basis von unterschiedlichen Prinzipien und Kategorien. Pattern sollen die Entwicklung von „qualitativ-hochwertiger“ Software, d. h., Software, deren Qualitätseigenschaften den Qualitätsanforderungen in einem hohen Maß entspricht, unterstützen, indem die bekannten Auswirkungen eines Pattern auf die Qualitätsmerkmale eines Systems als Teil der Pattern-Dokumentation erläutert werden (vgl. Kapitel 4.1.2). Da Pattern keine neuen, sondern existierende und erprobte Entwürfe darstellen, die in mehreren unterschiedlichen Systemen angewendet wurden, sind diese Auswirkungen auf die Qualitätsmerkmale eines Systems bekannt und können zumindest qualitativ beschrieben werden. Innerhalb der Entwurfsphase kann daher die Erreichung der Qualitätsanforderungen gesteuert und kontrolliert werden, indem z. B. die Auswirkungen auf die Qualitätsmerkmale besser nachvollziehbar werden und/oder mehrere Entwurfsalternativen verglichen werden können. Betrachtet man diese Eigenschaft des Entwurfs auf der Basis von Pattern, so fällt auf, dass keine der diskutierten Klassifikationen die Qualitätsmerkmale berücksichtigt, die durch ein Pattern beeinflusst werden. Die Klassifikationsschemata ermöglichen deshalb keine gezielte Suche auf Basis von beeinflussten Qualitätsmerkmalen.

4.2.3 Konzept der Definition von Pattern-Sprachen Die Pattern eines Pattern-Katalogs werden auf Basis einer Pattern-Schablone dokumentiert (vgl. Kapitel 4.2.1). Obwohl der Eindruck entstehen kann, dass Pattern isolierte Lösungen für bestimmte Problemstellungen darstellen, sind die Pattern stets im Kontext zu anderen Pattern zu betrachten (vgl. [BMRS1996, S. 16]): Ein Pattern kann z. B. ein Problem lösen, aber andere Probleme hervorrufen, die wiederum mit anderen Pattern gelöst werden können. Betrachtet man die Menge der Pattern, die innerhalb eines Pattern-Katalogs dokumentiert werden aus dieser Perspektive, erkennt man zahlreiche Beziehungen zwischen den Pattern. Die Pattern-

Dokumentation von Pattern

121

Schablonen enthalten hierzu einen dedizierten Abschnitt, in dem die Beziehungen eines Pattern zu anderen Pattern dokumentiert werden (vgl. Kapitel 4.2.1). Die Beziehungen zwischen den Pattern eines Katalogs sind aber allein auf Basis dieser Abschnitte innerhalb der Pattern-Dokumentationen nur sehr schwer nachvollziehbar. Es ist z. B. sehr aufwändig, alle benötigten Informationen aus den einzelnen Pattern-Dokumentationen zu extrahieren, um die möglichen Kombinationen der Pattern eines Katalogs zu identifizieren (vgl. [SSRB2000, S. 507]). Die Pattern eines Katalogs werden deshalb nicht isoliert, sondern neben der eigentlichen Pattern-Dokumentation auch im Kontext einer sog. Pattern-Sprache betrachtet. Eine derartige Sprache stellt die Pattern eines Katalogs aus einem größeren Blickwinkel dar und beschreibt, wie die Pattern kombiniert eingesetzt werden können und/oder sich gegenseitig ergänzen (vgl. [BMRS1996, S. 6; SSRB2000, S. 506]). Eine Pattern-Sprache kann bei der Lösung eines komplexen Entwurfsproblems unterstützen, indem die Elemente einer Sprache (d. h. die Pattern) derart kombiniert werden, dass ausschließlich sinnvolle Sätze (d. h. große geeignete Entwürfe) entstehen. Die Pattern-Sprachen ermöglichen dadurch die systematische Lösung von komplexen Entwurfsproblemen und können den Entwurfsprozess unterstützen (vgl. [SSRB2000, S. 508]). Das Konzept der Pattern-Sprachen entstand ebenfalls in Anlehnung an die Arbeiten aus dem Umfeld des Architekturprofessors Christopher Alexander, der das Konzept der Pattern-Sprachen in Bezug auf die Gestaltung von Gebäuden und Städten entwickelt und angewendet hat (siehe [Alex1979]). Eine Pattern-Sprache ist aber keine (künstliche) Sprache im engeren Sinn, da die Syntax und Semantik (noch) nicht ausreichend detailliert beschrieben wird. Im Folgenden werden zunächst die Pattern-Sprachen der ausgewählten Pattern-Kataloge untersucht (siehe Kapitel 4.2.3.1) und anschließend bewertet (siehe Kapitel 4.2.3.2).

4.2.3.1 Untersuchung ausgewählter Pattern-Sprachen Gamma, Helm, Johnson und Vlissides haben die Beziehungen zwischen den von ihnen dokumentierten Entwurfs-Pattern in einem Diagramm festgehalten (siehe Abbildung 4-2). Die Pattern werden durch Rechtecke dargestellt, die den Namen des Pattern enthalten. Die Beziehungen der Pattern werden durch beschriftete Pfeile zwischen den Rechtecken verdeutlicht.

122

Pattern im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen

Abbildung 4-2: Beziehungen zwischen den Entwurfs-Pattern Quelle: in Anlehnung an [GHJV1995, S. 12]

Die Beziehungen zwischen den einzelnen Entwurfs-Pattern sind informell beschrieben, so dass die Menge der Beziehungen sehr heterogen erscheint. Zimmer hat aus diesem Grund die Beziehungen näher analysiert und eine Klassifikation der Beziehungen entwickelt (siehe [Zimm1995]). Er identifizierte drei wesentliche Beziehungstypen, die er als Grundlage für eine neue Klassifikation der Entwurfs-Pattern verwendet hat (vgl. [Zimm1995]): ƒ Pattern X nutzt Pattern Y innerhalb der Lösung: Wenn das Pattern X zur Lösung eines

Problems eingesetzt wird, entsteht ein untergeordnetes Problem, das mit dem Pattern Y gelöst wird. Das Pattern X benutzt das Pattern Y innerhalb seiner Lösung und die Lösung des Pattern Y ist deshalb ein Teil der Lösung von X.

Dokumentation von Pattern

123

ƒ Pattern X ist ähnlich wie Pattern Y: Die Pattern X und Y addressieren ein ähnliches

Problem, aber mit unterschiedlichen Lösungsansätzen. Die Ähnlichkeit bezüglich des Problems spiegelt sich auch in der Klassifikation der Entwurfs-Pattern wider (vgl. Kapitel 4.2.2). ƒ Pattern X kann mit Pattern Y kombiniert werden: Die Pattern X und Y können mitein-

ander kombiniert werden, jedoch ohne dass z. B. Pattern X das Pattern Y innerhalb seiner Lösung verwendet. Die Pattern sind im Gegensatz zum ersten Beziehungstyp grundsätzlich unabhängig voneinander. Aufgrund der detaillierteren Beschreibung der Beziehungen und einer Analyse der „Pattern X nutzt Pattern Y“-Beziehung konnte Zimmer die Menge der Entwurfs-Pattern in drei semantische Schichten einteilen und neben der Klassifikation von Gamma, Helm, Johnson und Vlissides eine weitere Klassifikation der Entwurfs-Pattern entwickeln (siehe [Zimm1995]). Buschmann, Meunier, Rohnert et al. betrachten das Konzept der Pattern-Sprachen insbesondere aus der Perspektive der Softwarearchitekturen (vgl. [BMRS1996, S. 359]). Eine Pattern-Sprache für Softwarearchitekturen soll nach ihrem Verständnis vollständig sein, d. h., für jedes Problem und jeden Aspekt des Entwurfs und der Implementierung von Softwarearchitekturen muss mindestens ein Pattern vorhanden sein (vgl. [BMRS1996, S. 360]). Da sie innerhalb ihres Katalogs nur bestimmte Probleme und Aspekte behandeln und keine „vollständige“ Sprache formulieren können, verwenden sie den Begriff des Pattern-Systems (pattern system) anstelle von Pattern-Sprache: „A pattern system for software architectures is a collection of patterns for software architectures, together with guidelines for their implementation, combination and practical use in software development.” [BMRS1996, S. 361]. Sie definieren sechs Anforderungen an ein derartiges Pattern-System (vgl. [BMRS1996, S. 361 f.]). Zu diesen Anforderungen gehört auch, dass ein Pattern-System die verschiedenen Beziehungen zwischen den Pattern darstellen sollte, d. h., das System soll verdeutlichen, welches Pattern durch ein anderes Pattern verfeinert werden kann, wie die Pattern eines Katalogs kombiniert werden können und welche Alternativen zu einem Pattern existieren. Buschmann, Meunier, Rohnert et al. unterscheiden die drei Beziehungstypen Verfeinerung, Kombination und Alternative (vgl. [BMRS1996, S. 16-18, 361). Diese Beziehungstypen stimmen im Wesentlichen mit den von Zimmer identifizierten Beziehungstypen überein (vgl. [Zimm1995]), werden aber nicht innerhalb des von Buschmann, Meunier, Rohnert et al. dokumentierten Diagramms verwendet (vgl. [BMRS1996]). Die Beziehungen sind – analog zu dem Diagramm von Gamma, Helm, Johnson und Vlissides – nur informell beschrieben und daher nur eingeschränkt nachvollziehbar (siehe Abbildung 4-3).

124

Pattern im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen

Abbildung 4-3: Beziehungen zwischen den POSA 1-Pattern Quelle: in Anlehnung an [BMRS1996]29

Neben den Beziehungen wird innerhalb des Diagramms zwischen den Architektur- und Entwurfs-Pattern differenziert, indem die architektur-bezogenen Pattern grau hinterlegt worden sind. Die Suche und Auswahl eines Pattern auf Basis des Diagramms ist aufgrund der informellen Beschreibung der Beziehungen nur eingeschränkt möglich. Schmidt, Stal, Rohnert und Buschmann dokumentieren die Beziehungen zwischen den von ihnen dokumentierten Pattern ebenfalls innerhalb eines Diagramms (vgl. [SSRB2000, S. 511]). Sie greifen den Aspekt der unterschiedlichen Beziehungstypen auf, indem sie darauf hinweisen, dass im Kontext des Entwurfs auf Basis von Pattern insbesondere die Reihenfolge, in der die Pattern angewendet werden, von Relevanz ist (vgl. [SSRB2000, S. 506]). Sie fordern, die Beziehungen zwischen den Pattern derart zu definieren, dass diese Reihenfolge deutlich wird, um innerhalb des Entwurfsprozesses einen oder mehrere Pfade durch den Graph der 29

Das Diagramm befindet sich auf der letzten Seite des Buchs, die nicht mehr nummeriert ist.

Dokumentation von Pattern

125

Sprache ermitteln zu können. Jeder Pfad stellt durch die Kombination der Pattern eine mögliche Lösung eines komplexen Problems dar (siehe Abbildung 4-4).

Half-Sync/ Half-Async

Broker & Microkernel

async. layer implementation event demuxing and dispatching

queuing layer implementation

Leader / Followers

IPC encapsulation handler types

Wrapper Facade

Asynchronous Completion Token

thread safety

handler identification

IPC encapsulation

AcceptorConnector

service handler concurrency

Active Object

conponent types

Wrapper Facade

Component Configurator thread safety

role-specific interfaces

self-deadlock prevention

Extension Interface TS-object access

service handler concurrency

thread safety

Monitor Object by-pass interfaces

Thread-Specific Storage

locking mechanism encapsulation

singleton configuration

Interceptor

Scoped Locking

singleton interceptor

Extension Interface

lock acquisition and release

Thread-Safe Interface

Strategized Locking

locking mechanim encapsulation

thread safety

Wrapper Facade

error handling

thread-safe TS-object creation

Double-Checked Locking Optimization

Abbildung 4-4: Beziehungen zwischen den POSA 2-Pattern Quelle: in Anlehnung an [SSRB2000, S. 511]

Es werden sog. Einstiegspunkte (entry points) innerhalb der Pattern-Sprache definiert (vgl. [SSRB2000, S. 508]). Ein Einstiegspunkt einer Pattern-Sprache ist ein Pattern, das das übergeordnete Entwurfsproblem einer Anwendung bzw. eines Systems löst und ausgehend von diesem Pattern weitere Pattern zur Lösung der detaillierten Teilprobleme referenziert. Im Kontext des Pattern-Katalogs von Schmidt, Stal, Rohnert und Buschmann sind alle Architektur-Pattern Einstiegspunkte in die Pattern-Sprache (vgl. [SSRB2000, S. 508]). Die Architektur-Pattern beschreiben demnach Lösungen für die „größeren“ Probleme innerhalb des Entwurfs einer Anwendung bzw. eines Systems. Die Reihenfolge innerhalb der Pattern-Sprache spezifiziert die Pattern, die zur Lösung der untergeordneten Teilprobleme verwendet werden können. Im Kontext des Entwurfs von Softwarearchitekturen sind dies sehr häufig EntwurfsPattern, die wiederum in Kombination mit anderen Pattern ein Teilproblem lösen können.

126

Pattern im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen

Diese iterative Vorgehensweise der Dekomposition in „kleinere“ Pattern wird idealerweise solange fortgeführt, bis alle Probleme eines Anwendungsfalls durch ein bestimmtes Pattern adressiert werden (vgl. [SSRB2000, S. 508]). Bei der Entwicklung der Pattern-Sprache betrachteten Schmidt, Stal, Rohnert und Buschmann nur die „benutzt“-Beziehungen zwischen den Pattern ihres Katalogs (vgl. [SSRB2000, S. 508 ff.]). Es wurden auch optionale, aber keine transitiven Beziehungen berücksichtigt. Die „benutzt“-Beziehungen werden durch entsprechende Pfeile und die Richtung der Beziehung durch die Pfeilspitzen dargestellt (vgl. Abbildung 4-4). Die Einstiegspunkte, d. h. die Architektur-Pattern, werden grau markiert. Schmidt, Stal, Rohnert und Buschmann weisen explizit darauf hin, dass es sich hierbei nicht um eine vollständige Pattern-Sprache für den Anwendungsbereich der nebenläufigen und verteilten Objekte handelt (vgl. [SSRB2000, S. 520]). Das primäre Ziel des Diagramms ist, die von ihnen dokumentierten Pattern in Beziehung zueinander zu setzen und die Grundlage für eine derartige Sprache zu definieren. Das Diagramm wird ergänzend in einem dedizierten Kapitel erläutert (vgl. [SSRB2000, S. 510-519]). Darüber hinaus diskutieren sie die Erweiterung der Sprache mit anderen dokumentierten Pattern (vgl. [SSRB2000, S. 520 f.]). Diese Diskussion endet allerdings nicht in einem erweiterten Diagramm, d. h., einer erweiterten PatternSprache. Vergleicht man das Diagramm von Schmidt, Stal, Rohnert und Buschmann mit den Diagrammen von Gamma, Helm, Johnson und Vlissides sowie Buschmann, Meunier, Rohnert et al., wird deutlich, dass die Beziehungen zwischen den verschiedenen Pattern von Schmidt, Stal, Rohnert und Buschmann wesentlich detaillierter und klarer dokumentiert werden und deshalb den Anforderungen einer Pattern-Sprache gerechter werden. Die Semantik der Beziehungen bzw. Pfeile wird detaillierter beschrieben, obwohl auch in dieser Sprache keine Differenzierung zwischen einer verbindlichen und einer optionalen Beziehung erfolgt. Die Pattern-Sprache von Schmidt, Stal, Rohnert und Buschmann unterstützt daher einen strukturierten Entwurfsprozess besser als die beiden anderen zuvor vorgestellten Pattern-Sprachen. Kircher und Jain diskutieren die Beziehungen zwischen den von ihnen dokumentierten Pattern ausschließlich innerhalb der „See Also“-Abschnitte der Pattern-Dokumentation (siehe [KiJa2004]). Die Innenseite des Buchumschlags enthält zwar ein Diagramm, das die Beziehungen zwischen den Pattern darstellt, jedoch wird auf die Semantik der Beziehungen bzw. Pfeile nicht weiter eingegangen. Sie verwenden dennoch den Begriff der Pattern-Sprache innerhalb des Katalogs (vgl. z. B. [KiJa2004, S. 181-183]). Alur, Crupi und Malks diskutieren die Beziehungen zwischen den von ihnen dokumentierten Pattern im Detail und stellen diese auch innerhalb eines Diagramms dar (vgl. [AlCM2003, S. 130 ff.]). Sie erläutern die Beziehungen zwischen den Pattern und das Diagramm in einem dedizierten Kapitel. Die Menge der Beziehungen wird nicht einheitlich klassifiziert, d. h., ei-

Dokumentation von Pattern

127

nige Beziehungen sind sehr informell und individuell beschrieben, andere werden auf einen „benutzt“-Beziehungstyp zurückgeführt (siehe Abbildung 4-5).

LEGEND: Presentation-tier

Apply zero or more

Intercepting Filter

Business-tier Integration-tier

Centralize Control Delegate Control

Front Controller

Dispatch to target View

Composite View

Application Controller Create Delegate processing to Helpers

Dispatch to View

Create

Context Object View Helper

Compose View from Sub-Views

Dispatch to View

Front Controller

uses

Lightweight Control Processing

Dispatcher View

Dispatch to View

Access Business Service

Front Controller Control Processing

uses

Service to Worker

Access Business Service Access Business Service Invoke Business Processing

Application Service

uses

Business Delegate

Locate Services

Service Locator

Service Layers

Connect and Invoke Delegate Business Processing Encapsulate Session Facade and Encapsulate and coordinate Facade for coordinate List

Invoke Business Processing

Transfer Object Send Data

Business Object Coordinate Business Processing

Assembles Model

Value List Handler Invoke Business Processing

Implement Entity Beans

Service Activator Chain Async Processing Delegate Asynchronous Processing

uses

Send Data

Composite Entity

Transfer Object Assember uses

Transparently Persist Uses for Bean-managed Persistence

Transfer Object

Domain Store

uses

Web Service Broker

Send Data

Data Access Object

Business Object Retrieve Business List uses

Abbildung 4-5: Beziehungen zwischen den J2EE Core Pattern Quelle: in Anlehnung an [AlCM2003, S. 132]

Die Klassifikation der Pattern in drei logische Schichten (vgl. Kapitel 4.2.2) ist durch die unterschiedliche farbliche Hervorhebung in das Diagramm integriert. Innerhalb des Diagramms wird nicht zwischen verbindlichen und optionalen Beziehungen differenziert, obwohl

128

Pattern im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen

diese Unterscheidung innerhalb der textuellen Beschreibung der Beziehungen teilweise durch entsprechende sprachliche Formulierungen, wie z. B. „might“ oder „may be“, erfolgt. Obwohl die Pattern zahlreiche Beziehungen zu Pattern anderer Kataloge aufweisen und diese auch in den „Related Pattern“-Abschnitten dokumentiert werden, werden die katalog-übergreifenden Beziehungen nicht innerhalb des Diagramms dokumentiert. Aufgrund der nicht einheitlichen Klassifizierung, der unklaren Kardinalitäten der Beziehungen und der Unvollständigkeit des Diagramms wird die Auswahl und Kombination von Pattern nur bedingt unterstützt. Darüber hinaus enthält das Diagramm keine Einstiegspunkte, wie sie z. B. von Schmidt, Stal, Rohnert und Buschmann definiert wurden, so dass der Einstieg in das Diagramm durch die Auswahl eines ersten Pattern erschwert wird.

4.2.3.2 Bewertung der Pattern-Sprachen Das Konzept der Pattern-Sprachen ist ein vielversprechender Ansatz zur Unterstützung der systematischen Lösung von komplexen Entwurfsproblemen (vgl. [SSRB2000, S. 530]). Die ganzheitliche Betrachtung von Pattern und deren Beziehungen untereinander ermöglicht es, Pattern zu kombinieren und zu verfeinern, sowie alternative Pattern zu identifizieren. Es können im Rahmen des Entwurfs von Anwendungen bzw. Systemen die Lösungen, die innerhalb der Pattern dokumentiert werden, kombiniert, verfeinert und verglichen werden, indem auf Basis der Pattern-Sprache „gültige Sätze“ gebildet werden, die „übergeordnete“ Lösungen darstellen. Neben dem Entwurfswissen, das innerhalb der Pattern-Dokumentation beschrieben wird, kann durch eine Pattern-Sprache „übergeordnetes“ Wissen, d. h., Wissen über die Kombination und Verfeinerung von Pattern dokumentiert werden. Dieses Wissen kann z. B. Kenntnisse und Erfahrungen über den Entwurf einer Familie von Softwaresystemen und/oder großen Anwendungs-Frameworks umfassen (vgl. [SSRB2000, S. 508]). Die Betrachtung der verschiedenen Pattern-Sprachen führt zu der Erkenntnis, dass das Konzept der Pattern-Sprachen bisher nur rudimentär umgesetzt wurde. Die Beziehungen zwischen den Pattern sind häufig nur informell beschrieben und in Bezug auf ihre Syntax und Semantik nicht eindeutig dokumentiert. Eine eindeutige Definition von verschiedenen Beziehungstypen ist aber eine grundlegende Voraussetzung, um im Sinne einer Sprache grammatikalisch korrekte Sätze zu bilden, d. h., verschiedene Pattern „korrekt“ zu kombinieren oder ein Pattern „korrekt“ durch ein anderes Pattern zu verfeinern. Ist diese Voraussetzung nicht erfüllt, wird auch die Suche und Auswahl von Pattern eines Katalogs bzw. einer Sprache deutlich erschwert. Diese Problematik wurde bereits z. B. von Zimmer aufgegriffen, der die von Gamma, Helm, Johnson und Vlissides dokumentierten Entwurfs-Pattern analysiert und drei grundlegende Beziehungstypen zwischen Pattern identifiziert hat (siehe [Zimm1995]). Die Frage, ob diese drei Beziehungstypen ausreichend sind, um alle Pattern-Sprachen zu dokumentieren, ist noch

Konzepte zur Auswahl von Pattern

129

offen und könnte z. B. durch die Anwendung der Klassifikation auf andere Pattern-Sprachen überprüft werden. Diese Untersuchung ist aber nicht im Fokus der vorliegenden Arbeit. Die dokumentierten Pattern-Sprachen haben einen starken Bezug zu den Pattern eines Katalogs, d. h., die Beziehungen zu den Pattern anderer Kataloge werden häufig nicht betrachtet. Diese katalog-übergreifenden Beziehungen werden zwar teilweise innerhalb der PatternDokumentation und -Klassifikation beschrieben, aber innerhalb der Diagramme nicht dargestellt. Die Pattern-Dokumentationen von Alur, Crupi und Malks enthalten z. B. zahlreiche Referenzen auf Pattern des Katalogs von Buschmann, Meunier, Rohnert et al., die aber nicht in dem Diagramm des Katalogs dargestellt werden (vgl. [AlCM2003, S. 132]). Schmidt, Stal, Rohnert und Buschmann diskutieren den Aspekt der katalog-übergreifenden Beziehungen und beschreiben in einem dedizierten Kapitel Beispiele für die Erweiterung der von ihnen dokumentierten Pattern-Sprache (vgl. [SSRB2000, S. 520 f.]). Die Erweiterungen werden jedoch nicht innerhalb eines Diagramms berücksichtigt. Darüber hinaus betrachten die Pattern-Sprachen nicht den Aspekt, dass die Pattern bestimmte Auswirkungen auf Qualitätsmerkmale haben. Die identifizierten und teilweise in den Diagrammen verwendeten Beziehungstypen beschreiben, wie bestimmte Pattern mit anderen Pattern kombiniert bzw. verfeinert werden können und welche alternativen Pattern zu einem Pattern existieren. Die Pattern-Sprachen erläutern allerdings nicht, ob und wie sich die Auswirkungen eines Pattern auf die Qualitätsmerkmale verändern, wenn ein Pattern mit einem anderen Pattern kombiniert oder verfeinert wird. Unterstützt z. B. ein Pattern A die Wartbarkeit und wird mit einem Pattern B kombiniert, das die Effizienz unterstützt, aber negative Auswirkungen auf die Wartbarkeit hat, wird nicht deutlich, wie die Auswirkungen auf die Wartbarkeit bei einer Kombination der beiden Pattern sind. Dieses unklare Verhalten der Auswirkungen von kombinierten und verfeinerten Pattern, erschwert den Entwurf auf Basis von Pattern, da eine Anwendung bzw. Softwarearchitektur stets im Kontext bestimmter spezifizierter Anforderungen entwickelt wird und der Grad der Erfüllung dieser Anforderungen bestimmt, ob es sich um einen „guten“ oder „schlechten“ Entwurf handelt (vgl. Kapitel 3.1).

4.3

Konzepte zur Auswahl von Pattern

Neben den Pattern-Klassifikationen und -Sprachen betrachten die Pattern-Kataloge eigens den Aspekt der Auswahl eines Pattern. Die Diskussionen und Beschreibungen variieren in ihrem Umfang und reichen von einfachen Gruppierungen, die zusätzlich zu der Pattern-Klassifikation beschrieben werden, bis hin zu Vorgehensweisen zur Auswahl eines Pattern, die mehrere Arbeitsschritte und Iterationen umfassen.

130

Pattern im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen

Im Folgenden werden zunächt die unterschiedlichen Konzepte zur Auswahl von Pattern vorgestellt und untersucht (siehe Kapitel 4.3.1.1). Im Anschluss werden die verschiedenen Konzepte zusammenfassend bewertet (siehe Kapitel 4.3.1.2).

4.3.1.1 Untersuchung ausgewählter Konzepte Gamma, Helm, Johnson und Vlissides identifizieren sechs unterschiedliche Ansätze zur Auswahl eines geeigneten Entwurfs-Pattern. Sie werden kurz erläutert und referenzieren teilweise Beschreibungen, Tabellen, Abbildungen und Listen, die Bestandteil des Pattern-Katalogs sind, aber in anderen Kapiteln enthalten sind. Die Ansätze sind informell in der Textform beschrieben und nicht als Vorgehensweise im eigentlichen Sinn zu verstehen, sondern als mögliche gleichrangige Anfangspunkte bei der Auswahl eines Pattern (vgl. [GHJV1995, S. 28 f.]): ƒ Analyse der Art und Weise, wie die Entwurfs-Pattern Entwurfsprobleme lösen: Der

Kern dieses Ansatzes ist eine Diskussion, wie die Entwurfs-Pattern bestimmte Entwurfsprobleme im Kontext von objekt-orientierten Programmiersprachen lösen. In einem dedizierten Kapitel unterscheiden Gamma, Helm, Johnson und Vlissides sieben Problemfelder, mit denen ein Softwareentwickler typischerweise konfrontiert wird (siehe [GHJV1995, S. 11-28]). Diese Problemfelder umfassen z. B. die Ermittlung der angemessenen Objekte, die Bestimmung der Granularität der Objekte, den Einsatz der Wiederverwendungsmechanismen und der Entwurf unter der Berücksichtigung von zukünftigen Modifikationen. Die Entwurfs-Pattern, die im Katalog dokumentiert werden, werden innerhalb dieser sieben Problemfelder positioniert und es wird skizziert, wie die Pattern innerhalb der Problemfelder Lösungen darstellen. ƒ Untersuchung der "Intent"-Abschnitte: Die Inhalte der „Intent“-Abschnitte der Pattern-

Dokumentation (vgl. Kapitel 4.2.1) werden in einem separaten Kapitel redundant aufgelistet, um einen Überblick über die Entwurfs-Pattern zu erhalten (siehe [GHJV1995, S. 8 f.]). Der Ansatz referenziert dieses Kapitel und beinhaltet die Suche innerhalb dieser Liste, d. h., jeder „Intent“-Abschnitt kann nach einer ähnlichen Problembeschreibung untersucht werden, um ein geeignetes Entwurfs-Pattern zu finden. Der Vorteil der redundanten Auflistung der Abschnitte ergibt sich durch einen besseren Überblick und eine einfachere Navigation, d. h., es muss nicht der ganze Katalog durchsucht werden, um die Motivation und grundlegende Problemstellung der Pattern zu vergleichen und ein geeignetes Pattern zu finden. Darüber hinaus kann die Klassifikation der EntwurfsPattern (vgl. Kapitel 4.2.2) verwendet werden, um die Menge der Pattern einzuschränken. ƒ Analyse der Beziehungen zwischen den Pattern: Der Ansatz basiert auf der Pattern-

Sprache, die Gamma, Helm, Johnson und Vlissides innerhalb eines Diagramms doku-

Konzepte zur Auswahl von Pattern

131

mentieren (vgl. Kapitel 4.2.3.1). Die Beziehungen zwischen den Pattern können auf Basis der Sprache analysiert werden, um ein geeignetes Entwurfs-Pattern oder eine Gruppe von Pattern zu finden. ƒ Untersuchung der Pattern mit einem gemeinsamen Zweck: Der Pattern-Katalog ist nach

dem Zweck des Pattern in drei Kapitel strukturiert, die erstellungs-, struktur- und verhaltens-bezogene Entwurfs-Pattern unterscheiden. Die Struktur entspricht einer Dimension der Pattern-Klassifikation und kann nach diesem Ansatz zu Identifikation eines geeigneten Pattern verwendet werden, indem die Ähnlichkeiten und Unterschiede der Pattern mit gleichem Zweck untersucht werden. ƒ Analyse der Gründe für eine Überarbeitung des Entwurfs: Die Diskussion der sieben

Problemfelder mit denen ein Softwareentwickler konfrontiert wird, beinhaltet auch die Problematik des Entwurfs unter der Berücksichtigung von zukünftigen Änderungen. Die Diskussion umfasst u. a. eine Liste von acht typischen Gründen für eine Überarbeitung eines Entwurfs. Zu jedem Überarbeitungsgrund werden potenzielle EntwurfsPattern aufgelistet, die bei einem Einsatz eine Überarbeitung des Entwurfs hätten vermeiden können. ƒ Untersuchung der variablen Bestandteile des Entwurfs: Dieser Ansatz analysiert die

Bestandteile eines Entwurfs, die variabel sein müssen, damit bei bestimmten Änderungen keine Überarbeitung des Entwurfs erforderlich wird. Der Ansatz stellt das Gegenteil des vorherigen Ansatzes dar. Er referenziert eine Tabelle, in der zu jedem Entwurfs-Pattern des Katalogs, die Aspekte dokumentiert sind, die durch den Einsatz des Pattern variabel bleiben (siehe [GHJV1995, S. 30]). Die Tabelle kann die Auswahl eines Pattern unterstützen, indem ausgehend von einem variablen Aspekt auf ein Pattern verwiesen wird. Die sechs Ansätze zur Auswahl eines geeigneten Entwurfs-Pattern sehen im Wesentlichen die Auswahl eines Pattern aufgrund des zugrunde liegenden Problems vor. Eine Ausnahme ist der Ansatz, die Beziehungen zwischen den Pattern zu analysieren, um ein geeignetes Pattern zu identifizieren. Da innerhalb des Diagramms keine Einstiegspunkte in die Pattern-Sprache (vgl. Kapitel 4.2.3.1) vorgesehen sind, muss für diesen Ansatz mindestens ein Pattern bereits selektiert worden sein, um ausgehend von diesem Pattern weitere Pattern identifizieren zu können. Weitere Ausnahmen stellen die beiden letzten Ansätze dar, die aus verschiedenen Perspektiven die Unterstützung der Wartbarkeit (vgl. Kapitel 3.2.3.5) als Auswahlkriterium verwenden. Da keine weiteren Qualitätsmerkmale als Kriterium bei der Auswahl eines Entwurfs-Pattern vorgesehen sind, kann festgehalten werden, dass innerhalb des Katalogs kein vollständiger Ansatz zur Auswahl eines Pattern auf Basis von Qualitätsmerkmalen definiert wird. Buschmann, Meunier, Rohnert et al. definieren eine einfache Vorgehensweise zur initialen Auswahl eines Pattern, die auf der Pattern-Schablone, -Klassifikation und -Sprache ihres

132

Pattern im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen

Katalogs basiert (vgl. [BMRS1996, S. 368-370]). Die Vorgehensweise ist weniger geeignet, um ausgehend von einem bereits ausgewählten Pattern, das implementiert oder verfeinert werden soll, weitere Pattern zu finden. Hierzu ist die eigentliche Pattern-Dokumentation nach Auffassung von Buschmann, Meunier, Rohnert et al. besser geeignet, da insbesondere die „Implementation“-Abschnitte zahlreiche Hinweise auf weiterführende Pattern enthalten. Die Vorgehensweise umfasst im Kern sechs Arbeitsschritte, die um einen siebten optionalen Schritt ergänzt werden (vgl. [BMRS1996, S. 368-370]): 1. Spezifikation des Problems: Die Auswahl eines geeigneten Pattern setzt eine genaue Spezifikation des Problems voraus, d. h., es stellt sich die Frage nach dem generellen Problem und den wirkenden „Kräften“, die im Kontext der Lösung auszugleichen sind. Wenn das generelle Problem mehrere Aspekte beinhaltet, kann das Problem in mehrere Teilprobleme aufgegliedert werden. 2. Auswahl des Pattern-Typs: Dieser Arbeitsschritt umfasst eine Einschränkung der Pattern-Menge, indem der (voraussichtliche) Pattern-Typ ausgewählt wird. Die PatternTypen werden auf Basis der Klassifikation von Buschmann, Meunier, Rohnert et al. unterschieden (vgl. Kapitel 4.2.2.1). 3. Auswahl des Problembereichs: Die Auswahl des Problembereichs basiert ebenfalls auf der Klassifikation von Buschmann, Meunier, Rohnert et al. (vgl. Kapitel 4.2.2.1) und reduziert die Pattern-Menge weiter. Wenn das konkrete Entwurfsproblem nicht in die Klassifikation eingeordnet werden kann, wird zum siebten Arbeitsschritt verzweigt, um einen alternativen Problembereich zu selektieren. 4. Vergleich der Problembeschreibungen: Neben der Pattern-Menge, die durch die Arbeitsschritte zwei und drei reduziert worden ist, werden innerhalb dieses Schrittes die Problembeschreibungen der verbleibenden Pattern analysiert. Jedes Pattern des Problembereichs kann einen spezifischen Aspekt des konkreten Entwurfsproblems adressieren. Entweder kann ein einzelnes oder es können mehrere Pattern das Problem lösen. Aus diesem Grund werden alle Pattern ausgewählt, deren Problembeschreibungen am besten zu dem Entwurfsproblem passen. Wenn keines der verbleibenden Pattern dem konkreten Entwurfsproblem entspricht, wird wiederum zum siebten Arbeitsschritt verzweigt. 5. Vergleich des Nutzens und der Anfälligkeiten des Pattern: Innerhalb dieses Arbeitsschrittes werden der Nutzen und die Anfälligkeiten des bisher ausgewählten Pattern untersucht. Aus der verbleibenden Pattern-Menge werden die Pattern ausgewählt, die einen gewünschten Nutzen haben und deren Anfälligkeiten für das konkrete Entwurfsproblem am wenigsten relevant sind. 6. Auswahl der Variante: Wenn die restlichen Pattern Varianten haben, werden für jedes Pattern entsprechende Varianten selektiert. Sofern keine Probleme bei der Ausführung

Konzepte zur Auswahl von Pattern

133

der Arbeitsschritte drei und vier aufgetreten sind, ist die Pattern-Auswahl mit diesem Schritt abgeschlossen. 7. Selektion eines alternativen Problembereichs: Wenn kein angemessener Problembereich identifiziert werden konnte oder der ausgewählte Problembereich keine verwendbaren Pattern enthält, wird ein anderer Problembereich ausgewählt, indem das konkrete Entwurfsproblem weiter verallgemeinert wird. Dieser alternative Problembereich enthält potenzielle Pattern, die in einer spezialisierten Form das konkrete Problem lösen könnten. Im Anschluss an diesen Arbeitsschritt wird zum vierten Schritt zurückgekehrt. Wenn nach der Auswahl eines alternativen Problembereichs im siebten Arbeitsschritt kein Pattern identifiziert werden konnte, empfehlen Buschmann, Meunier, Rohnert et al. die Suche abzubrechen und andere Pattern-Sprachen, -Systeme oder -Kataloge zu analysieren (vgl. [BMRS1996, S. 370]). Die Vorgehensweise, die Buschmann, Meunier, Rohnert et al. zur initialen Auswahl eines Pattern vorschlagen, bildet einen deutlichen Schwerpunkt auf die zugrunde liegende Problemstellung. Es wird die zwei-dimensionale Klassifikation des Pattern-Katalogs verwendet, um die Pattern-Menge aufgrund des Pattern-Typs und des Problembereichs zunächst einzuschränken und anschließend die Problembeschreibungen der verbleibenden Pattern zu untersuchen. Die Auswirkungen eines Pattern auf die Qualitätsmerkmale werden ausschließlich innerhalb des fünften Arbeitsschrittes und dort nur oberflächlich betrachtet, indem der Nutzen möglichst mit dem konkreten Entwurfsproblem „übereinstimmen“ soll und die Anfälligkeiten innerhalb des konkreten Entwurfsproblems „nur von untergeordneter Rolle sind“. Eine detaillierte Abstimmung der Qualitätsanforderungen der Anwendung bzw. des Systems mit den Auswirkungen des Pattern, ist nicht Bestandteil der Vorgehensweise. Buschmann, Meunier, Rohnert et al. beschreiben zwar, dass ihre Vorgehensweise u. a. auch auf den Beziehungen zwischen den Pattern basiert, aber die Beziehungen oder die Pattern-Sprache wird innerhalb der Beschreibung der Vorgehensweise nicht referenziert. Schmidt, Stal, Rohnert und Buschmann diskutieren die Auswahl eines geeigneten Pattern nur indirekt im Kontext der Beschreibung der Pattern-Sprache und der Relevanz der PatternReihenfolge (vgl. Kapitel 4.2.3.1). Neben der Pattern-Klassifikation und -Sprache werden aber keine weiteren Beschreibungen oder Konzepte zur Auswahl eines Pattern dokumentiert. Im dritten Band der Pattern-Oriented Software Architecture-Serie erläutern Kircher und Jain die Auswahl eines Pattern im speziellen Kontext des Managements von Ressourcen (vgl. [KiJa2004, S. 181-184]). Sie spezifizieren vier Arbeitsschritte, die bei der Verwendung der Pattern-Sprache verfolgt werden sollten: 1. Identifikation der Schlüssel-Komponenten: Der erste Arbeitsschritt umfasst die Identifikation der Schlüssel-Komponenten eines Systems. Eine Schlüssel-Komponente ist eine Komponente, die entweder „teure“ Ressourcen oder eine große Anzahl von Ressourcen

134

Pattern im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen

konsumiert. Eine Ressource ist „teuer“, wenn sie innerhalb des Systems knapp ist oder es aufwändig ist, an die Ressource zu gelangen und sie anschließend wieder freizugeben. Darüber hinaus kann sie „teuer“ sein, wenn aufgrund des Benutzerverhaltens Konkurrenzsituationen bezüglich der Ressource entstehen können. 2. Identifikation des Kontexts: Der Kontext beschreibt die Problemstellung und die „Kräfte“, die sich innerhalb eines konkreten Entwurfs ergeben. Dieser Kontext wird im Folgenden betrachtet, um auf Basis der Pattern-Sprache für jede Schlüssel-Komponente ein Pattern zu selektieren. 3. Identifikation der „hot spots“: Ein sog. „hot spot“ ist ein Bestandteil einer Komponente, der Auswirkungen auf den Ressourcenverbrauch, die Geschwindigkeit, die Skalierbarkeit oder die Stabilität der Komponenten hat. Für jede Schlüssel-Komponente des Systems werden die entsprechenden „hot spots“ identifiziert und nach ihrer Auswirkung kategorisiert. 4. Anwendung der Pattern: In diesem Arbeitsschritt wird bzw. werden für jeden zuvor identifizierten „hot spot“ ein oder mehrere Pattern der Sprache ausgewählt. Die Grundlage für die Selektion bildet die Kategorie, in der der „hot spot“ eingeordnet wurde, und der Kontext, der die problem-bezogene Auswahl unterstützt. Die Anwendung eines Pattern führt zu einem neuen Kontext, der die „Kräfte“ der Problemstellung ausgleicht und zu einem neuen Kontext führt. Der neue Kontext kann neue „Kräfte“ enthalten, die wiederum ausgeglichen werden müssen, indem auf Basis der Pattern-Sprache weitere Pattern ausgewählt werden. Die Arbeitsschritte, die Kircher und Jain zur Auswahl von Pattern vorschlagen, sind insbesondere für Entwurfsprobleme im Umfeld des Ressourcenmanagements konzipiert, da ausgehend von Schlüssel-Komponenten, die „teure“ Ressourcen konsumieren, und dem Konzept der „hot spots“ eine Auswahl der Pattern erfolgt. Der Ansatz, ein Pattern aufgrund der Problemstellung auszuwählen, wird um die Konzepte der Schlüssel-Komponenten und „hot spots“ erweitert, um dem speziellen Kontext des Ressourcenmanagements gerecht zu werden. Das Konzept der „hot spots“ ist im Kern mit dem Konzept der Sensitivitäts- und Abwägungspunkte (vgl. Kapitel 3.3.2.2) vergleichbar. Es ist aber – im Vergleich zu der Arbeit von Clements, Kazman und Klein – nicht so detailliert ausgearbeitet. Die Beziehungen zwischen einem Pattern und den beeinflussten Qualitätsmerkmalen werden nur rudimentär betrachtet. Die Pattern werden z. B. nach den Qualitätsmerkmalen gruppiert, die durch ein Pattern „unterstützt“ werden. Eine weitere Klassifikation dieser Unterstützung erfolgt nicht, so dass die Auswahl eines Pattern primär auf der Basis der unterstützten Qualitätsmerkmale erfolgen kann. Es werden nur bestimmte Qualitätsmerkmale betrachtet, so dass es sich nicht um einen vollständigen Ansatz zur Auswahl eines Pattern auf Basis von Qualitätsmerkmalen handelt. Alur, Crupi und Malks beschreiben die Auswahl eines Pattern im Kontext der Anforderungen, die ein Architekt im Umfeld der Anwendungsentwicklung auf Basis der J2EE-Plattform be-

Konzepte zur Auswahl von Pattern

135

rücksichtigen muss (vgl. [AlCM2003, S. 135]). Sie definieren für jede logische Schicht eine Tabelle, die eine Liste von typischen Anforderungen enthält und ordnen jeder Anforderung mindestens ein Pattern, einen Entwurfs- oder einen Refactoring-Ansatz zu, wodurch die Anforderungen unterstützt werden. Tabelle 4-7 zeigt beispielhaft einen Auszug der Zuordnungen, die für die Präsentationsschicht relevant sind. Alur, Crupi und Malks spezifizieren hinter jedem Namen eine Referenz auf die erste Seite der Dokumentation des Pattern bzw. Ansatzes.

If you are looking for this

Find it here

Preprocessing or postprocessing of your request

Pattern Intercepting Filter (144)

Adding logging, debugging, or some other behavior to be completed for each request

Pattern Front Controller (166) Pattern Intercepting Filter (144)

Centralizing control for request handling

Pattern Front Controller (166) Pattern Intercepting Filter (144) Pattern Application Controller (205)

Creating a generic command interface or context object for reducing coupling between control components and helper components

Pattern Front Controller (166) Pattern Application Controller (205) Pattern Context Object (181)

Controlling client access to a certain View or Sub-view

Design “Controlling Client Access” (22) Refactoring “Hide Resources From a Client” (88)

Controlling the flow of requests into the application

Design “Duplicate Form Submissions” (27) Design “Introduce Synchronizer Token” (67)

Tabelle 4-7: Zuordnung von Anforderungen und Pattern (Präsentationsschicht) Quelle: in Anlehnung an [AlCM2003, S. 135 f.]

Die Tabellen verweisen neben den Pattern auch auf Entwurfs-Ansätze, die im Kontext der J2EE-Plattform grundlegende Entwurfsentscheidungen darstellen und mit dem Konzept der Taktiken von Bass, Clements und Kazman (vgl. Kapitel 4.1.3) verglichen werden können. Daneben wird auf sog. Refactoring-Ansätze referenziert, die Vorgehensweisen zur Umstrukturierung von Software darstellen (siehe z. B. [Opdy1992; Fowl1999]). Die innerhalb der Tabellen verwendeten Anforderungen wurden primär direkt aus den Problembeschreibungen der Pattern abgeleitet oder durch Verallgemeinerung der Problemstellungen auf mehrere Pattern abgebildet. Die Selektion eines Pattern gleicht deshalb einer Auswahl auf Basis der Problemstellung, die die anderen Pattern-Kataloge im Wesentlichen auch verfolgen. Die Tabellen von Alur, Crupi und Malks lassen sich insbesondere mit dem Ansatz von Gamma, Helm, Johnson und Vlissides vergleichen, die die Inhalte der „Intent“-Abschnitte der Pattern-Dokumentation in einem separaten Kapitel redundant aufgelistet haben, um einen Überblick über die Entwurfs-Pattern zu geben und eine effiziente Auswahl zu ermöglichen.

136

Pattern im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen

Eine Auswahl aufgrund von Qualitätsmerkmalen ist mit den Tabellen nicht möglich. Weiterhin ist aus den Tabellen nicht ersichtlich, welche Qualitätsmerkmale ein Pattern unterstützt.

4.3.1.2 Bewertung der Konzepte Die beispielhaft untersuchten Pattern-Kataloge betrachten nicht alle die Auswahl eines geeigneten Pattern. Wenn jedoch die Pattern-Auswahl explizit durch den Katalog unterstützt wird, erfolgt die Auswahl im Wesentlichen auf Basis der Problemstellung, die ein Pattern durch eine entsprechende Lösung unterstützt. Die Selektion eines Pattern aufgrund von beeinflussten Qualitätsmerkmalen wird von keinem der untersuchten Pattern-Kataloge vollständig unterstützt. Die Auswirkungen eines Pattern auf die Qualitätsmerkmale haben – wenn sie überhaupt bei der Auswahl berücksichtigt werden – einen untergeordneten Stellenwert. Buschmann, Meunier, Rohnert et al. z. B. betrachten die Auswirkungen nur oberflächlich und ausschließlich innerhalb eines einzigen Arbeitsschritts ihrer Vorgehensweise. Kircher und Jain gruppieren die Pattern ihres Katalogs nach den unterstützten Qualitätsmerkmalen. Die Auswahl mehrerer Pattern, die z. B. kombiniert oder verfeinert werden sollen, wird von den analysierten Pattern-Katalogen nicht unterstützt. Die geringe Unterstützung kann auf die (noch) existierenden Mängel bei der Umsetzung der Pattern-Sprachen zurückgeführt werden (vgl. Kapitel 4.2.3.2). Analog zu den Pattern-Sprachen werden bei der Selektion eines Pattern nicht die Auswirkungen von kombinierten bzw. verfeinerten Pattern berücksichtigt.

4.4

Pattern im Kontext des Entwurfs und der Bewertung

Der Kerngedanke des Pattern-Konzepts ist die systematische und strukturierte Dokumentation von Entwurfswissen, um den routinemäßigen Entwurf von Softwareelementen bzw. -architekturen effektiver und effizienter zu gestalten (vgl. Kapitel 4.1). Da Pattern keine neuen, sondern existierende und erprobte Entwürfe darstellen, die in mehreren unterschiedlichen Systemen bereits angewendet wurden, können auch die Auswirkungen eines Pattern auf die Qualitätsmerkmale eines Systems qualitativ beschrieben werden (vgl. Kapitel 4.1.2). Die Kenntnis der Pattern und deren Auswirkungen auf die Qualität eines Systems ermöglichen einen gezielten Entwurf eines Softwareelements bzw. einer Softwarearchitektur im Hinblick auf die spezifizierten Qualitätsanforderungen, indem das innerhalb der Pattern-Kataloge und -Dokumentationen beschriebene Entwurfswissen wiederverwendet wird. Das Pattern-Konzept kann auch die effektive und effiziente Bewertung von Softwarearchitekturen unterstützen, indem ebenfalls das Entwurfswissen wiederverwendet wird, um die Beziehungen zwischen den Entwurfsentscheidungen innerhalb der Architektur und deren Auswir-

Pattern im Kontext des Entwurfs und der Bewertung

137

kungen auf die Qualität eines Systems systematisch zu untersuchen, zu verstehen und zu bewerten (vgl. Kapitel 3.1). Die Nutzung des Pattern-Konzepts innerhalb des Entwurfs und der Bewertung von Softwarearchitekturen erfordert insbesondere die Kenntnis und Analyse der Auswirkungen eines Pattern auf die Qualitätsmerkmale eines Systems. Die Untersuchung der Dokumentation und Auswahl der Pattern hat gezeigt, dass die Auswirkungen der Pattern auf die Qualitätsmerkmale innerhalb der ausgewählten Pattern-Kataloge nur eine untergeordnete Rolle spielen. Sie sind zwar Bestandteil der Pattern-Schablonen und der Pattern-Dokumentation, jedoch erfolgt die Beschreibung der Auswirkungen ohne eine konsistente Terminologie und/oder einheitliche Begriffsdefinitionen. Darüber hinaus verwenden die Pattern-Kataloge bzw. -Dokumentationen kein homogenes Qualitätsmodell und keine einheitlichen Qualitätsmerkmale zur Klassifikation der Auswirkungen eines Pattern (vgl. Kapitel 4.2.1.2). Die analysierten Pattern-Klassifikationen, die die Übersichtlichkeit der Pattern eines Katalogs gewährleisten sollen, berücksichtigen die Auswirkungen der Pattern auf die Qualitätsmerkmale nicht. Es existiert innerhalb der ausgewählten Pattern-Kataloge keine Klassifikation, die ein Qualitätsmodell mit entsprechenden Qualitätsmerkmalen berücksichtigt (vgl. Kapitel 4.2.2.2). Die Klassifikationsschemata ermöglichen – sowohl im Kontext des Entwurfs als auch der Bewertung – keine gezielte Suche auf Basis von unterstützen Qualitätsmerkmalen. Die untersuchten Pattern-Sprachen berücksichtigen die Auswirkungen auf die Qualitätsmerkmale ebenfalls nicht (vgl. Kapitel 4.2.3.2). Die in den Diagrammen verwendeten Beziehungstypen beschreiben im Wesentlichen, wie bestimmte Pattern mit anderen Pattern kombiniert bzw. verfeinert werden können und welche alternativen Pattern zu einem Pattern existieren. Sie spezifizieren nicht, ob und wie sich die Auswirkungen eines Pattern auf die Qualitätsmerkmale verhalten, wenn ein Pattern mit einem anderen Pattern kombiniert oder verfeinert wird, so dass insbesondere der Entwurf und die Bewertung auf der Ebene der Softwarearchitektur durch die Pattern-Sprachen nur bedingt unterstützt werden. Die Auswahlprozesse betrachten – sofern sie innerhalb eines Pattern-Katalogs diskutiert werden – die Auswirkungen der Pattern auf die Qualitätsmerkmale nicht (vgl. Kapitel 4.3). Die Auswahl eines Pattern erfolgt im Wesentlichen auf Basis der zugrunde liegenden Problemstellung, die ein Pattern durch eine entsprechende Lösung adressiert. Die Auswirkungen eines Pattern auf die Qualitätsmerkmale haben einen untergeordneten Stellenwert, so dass die Prozesse die Auswahl aufgrund von beeinflussten Qualitätsmerkmalen nicht unterstützen. Die Nutzung des Pattern-Konzepts innerhalb des Entwurfs und der Bewertung von Softwarearchitekturen ist im Hinblick auf einen systematischen Entwurfs- und Bewertungsprozess (vgl. Kapitel 4.1) grundsätzlich möglich und sinnvoll. Die Verwendung der Pattern-Kataloge bzw. -Dokumentationen wird aber durch die mangelnde Betrachtung der Auswirkungen auf

138

Pattern im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen

die Qualitätsmerkmale innerhalb der Pattern-Schablonen, -Klassifikation, -Sprachen und -Auswahlprozesse erschwert, so dass die Identifikation und Bewertung der Auswirkungen mit einem relativ großen Aufwand verbunden ist.

4.5

Zusammenfassung

Das Konzept der Pattern beinhaltet die systematische Erfassung und Strukturierung von Entwurfswissen, das auf Basis von existierenden und erprobten Entwürfen gewonnen wird (vgl. Kapitel 4.1). Pattern beschreiben Lösungsansätze für spezifische Problemstellungen und etablieren durch die verwendeten Pattern-Namen ein Entwurfsvokabular, das gleichzeitig eine neue Abstraktionsebene darstellt, wodurch die Komplexität bei der Entwicklung von umfangreichen Softwaresystemen reduziert werden kann. Sie beschreiben darüber hinaus innerhalb der Pattern-Dokumentation die Auswirkungen eines Pattern auf die Qualitätsmerkmale eines Systems. Diese Eigenschaften der Pattern ermöglichen die Nutzung des Konzepts im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen. Die Untersuchung der Pattern-Dokumentation (vgl. Kapitel 4.2) und Auswahlprozesse (vgl. Kapitel 4.3) hat jedoch gezeigt, dass insbesondere die Auswirkungen der Pattern auf die Qualitätsmerkmale innerhalb der ausgewählten Pattern-Kataloge nur eine untergeordnete Rolle spielen. Die Pattern-Dokumentationen beschreiben zwar die Auswirkungen auf die Qualitätsmerkmale, aber es werden keine konsistente Terminologie, keine einheitlichen Begriffsdefinitionen und kein homogenes Qualitätsmodell verwendet. Die mangelnde Betrachtung der Auswirkungen auf die Qualitätsmerkmale innerhalb der Pattern-Schablonen, -Klassifikation, -Sprachen und -Auswahlprozesse erschwert die Nutzung des Konzepts, d. h., die Wiederverwendung von Entwurfswissen (vgl. Kapitel 4.4). Obwohl die Verwendung des Pattern-Konzepts grundsätzlich möglich und sinnvoll ist, ist die Identifikation und Bewertung der Auswirkungen mit einem großen Aufwand verbunden.

5 Entwicklung eines pattern-basierten Wissensmodells Der Erfolg des Entwurfs und der Bewertung einer Softwarearchitektur hängen stark von den Kenntnissen und Erfahrungen der beteiligten Architekten bzw. des Bewertungsteams ab (vgl. Kapitel 3.4). Pattern können den Entwurf und die Bewertung unterstützen, indem sie existierendes und erprobtes Entwurfswissen in Form von Pattern-Katalogen und -Dokumentationen wiederverwendbar machen. Die Untersuchung von ausgewählten Pattern-Katalogen hat aber gezeigt, dass diese kein homogenes Qualitätsmodell und keine einheitlichen Qualitätsmerkmale verwenden (vgl. Kapitel 4.5). Die existierenden Pattern-Klassifikationen, -Sprachen und -Auswahlprozesse ermöglichen keine Selektion auf Basis von Qualitätsmerkmalen. Die fehlende Klassifikation und Selektion der Pattern im Hinblick auf die Unterstützung von spezifizierten Qualitätsmerkmalen erschwert den Entwurf und die Bewertung von Softwarearchitekturen auf Basis von Pattern. Das Ziel des vorliegenden Kapitels ist deshalb die Entwicklung einer Vorgehensweise, mit der existierende Pattern-Dokumentationen analysiert und die für einen pattern-basierten Entwurf bzw. eine szenario-basierte Bewertung relevanten Informationen extrahiert werden können. Diese Informationen werden auf Basis eines Wissensmodells dokumentiert, das den Entwurf und die Bewertung von Softwarearchitekturen auf Basis von Pattern unterstützt. In Kapitel 5.1 wird zunächst die Entwicklung des Wissensmodells beschrieben, indem detailliert die Struktur und der Aufbau des Modells erläutert und begründet werden. Der Aufbau einer entsprechenden Wissensbasis erfolgt mit einer Vorgehensweise, die in Kapitel 5.2 entwickelt und erläutert wird. Die Validierung des Wissensmodells und der Vorgehensweise erfolgte auf Basis ausgewählter Pattern-Kataloge und wird in Kapitel 5.3 dokumentiert. In Kapitel 5.4 wird schließlich die Verwendung der Wissensbasis innerhalb des pattern-basierten Entwurfs und der szenario-basierten Bewertung einer Softwarearchitektur erläutert.

5.1

Entwicklung des Wissensmodells

Die Entwicklung des Wissensmodells beginnt mit einer Beschreibung der Zieldefinition und der zugrunde liegenden Annahmen (Kapitel 5.1.1). Die Grundstruktur des Wissensmodells ist eine Tabelle, deren Struktur und Aufbau in den Kapiteln 5.1.3 bis 5.1.8 detailliert erläutert werden.

140

Entwicklung eines pattern-basierten Wissensmodells

5.1.1 Zieldefinition und Annahmen Das Wissensmodell soll die jeweils durch ein Pattern beeinflussten Qualitätsmerkmale abbilden. Die Wissensrepräsentation soll übersichtlich, nachvollziehbar und vergleichbar sein (siehe Abbildung 5-1).

Abbildung 5-1: Ziele des Wissensmodells

Die Beziehungen zwischen Pattern und Qualitätsmerkmalen sind grundsätzlich bereits in den Pattern-Katalogen bzw. -Dokumentationen beschrieben. Allerdings beinhalten die PatternSchablonen keine konsequente Klassifikation auf Basis eines homogenen Qualitätsmodells (vgl. Kapitel 4.2.1.2), was die Nachvollziehbarkeit und Vergleichbarkeit, insbesondere im Kontext einer Bewertung, wesentlich reduziert. Die existierenden Pattern-Klassifikationen, -Sprachen und Auswahlprozesse, die als Teil der Pattern-Kataloge dokumentiert sind, ermöglichen keine Selektion von Pattern auf Basis von Qualitätsmerkmalen (vgl. Kapitel 4.4), wodurch innerhalb des Entwurfs die Übersichtlichkeit und Nachvollziehbarkeit im Hinblick auf die zu unterstützenden Qualitätsmerkmale stark reduziert werden. Da die Auswirkungen auf die Qualitätsmerkmale bereits innerhalb der Pattern-Dokumentationen betrachtet werden, wird die zu entwickelnde Wissenbasis in Bezug auf die PatternKataloge redundante Informationen enthalten. Das Ziel ist es aber, diese Redundanz so gering wie möglich zu halten (vgl. Abbildung 5-1). Da aufgrund der redundanten Informationen innerhalb des Entwurfs bzw. der Bewertung mehrere Quellen verwendet werden müssen, ist das Ziel der geringen Redundanz konträr zu den Zielen der Übersichtlichkeit, Nachvollziehbarkeit und Vergleichbarkeit. Das Wissensmodell soll in Bezug auf das Qualitätsmodell vollständig sein, d. h., es ist nicht vorgesehen, Qualitätsmerkmale hinzuzufügen und/oder zu entfernen (vgl. Abbildung 5-1). Hinsichtlich der Pattern-Menge soll das Wissensmodell erweiterbar sein, damit die Wissensbasis durch die Erfassung von weiteren bzw. neuen Pattern vergrößert werden kann.

Entwicklung des Wissensmodells

141

Die Problembereiche des Entwurfs und der Bewertung von Softwarearchitekturen überlagern sich mit dem Einsatzbereich von Expertensystemen (vgl. z. B. [Pupp1990, S. 8 ff.]). Die Entwicklung eines solchen Systems ist aber nicht das Ziel der vorliegenden Arbeit, obwohl das Wissensmodell und die Vorgehensweise eine Grundlage für eine derartige Entwicklung bilden kann. Das Wissensmodell soll nicht als Problemlöser, sondern als Wissensmedium verstanden werden, das innerhalb eines Bewertungs- bzw. Entwurfsprozesses lediglich eine unterstützende Funktion einnimmt (vgl. [Pupp1990, S. 11]).

5.1.2 Grundlegende Struktur und Aufbau des Wissensmodells Die Entwicklung des Wissensmodells und der Vorgehensweise basiert auf der Problemlösungsmethode der Klassifikation (vgl. [Pupp1990, S. 42]). Diese wird zur Identifikation von geeigneten Lösungen zu einem spezifizierten Problem verwendet (siehe Abbildung 5-2).

Abbildung 5-2: Positionierung der Problemlösungsmethode der Klassifikation und des Wissensmodells

Das Wissensmodell definiert die Repräsentation des Wissens, die von der Problemlösungsmethode verwendet wird. Die grundlegende Struktur des Wissensmodells ist eine Tabelle (siehe Abbildung 5-3). Die Kopfzeilen enthalten die Qualitätsmerkmale eines homogenen Qualitätsmodells, das im folgenden Kapitel 5.1.3 definiert wird. Die Vorspalten identifizieren bzw. referenzieren eine Menge von Pattern. Die Tabellenfelder bilden die Zuordnung von Pattern zu Qualitätsmerkmalen ab. Ein Pattern kann auf mehrere Qualitätsmerkmale einwirken und ein Qualitätsmerkmal kann durch mehrere Pattern beeinflusst werden. Aufgrund des hohen Abstraktionsniveaus eines Pattern (vgl. Kapitel 4.1) kann keine direkte und eindeutige Zuordnung zwischen einem Pattern und den Qualitätsmerkmalen erfolgen. Die Zuordnungen werden deshalb auf Basis von verschiedenen Kategorien abgebildet (siehe

142

Entwicklung eines pattern-basierten Wissensmodells

Kapitel 5.1.7), die innerhalb des Entwurfs- bzw. Bewertungsprozesses untersucht und aufge-

Pattern

löst werden.

Abbildung 5-3: Grundlegende Struktur und Aufbau der Tabelle

Die einfache Struktur in Form einer Tabelle unterstützt die Ziele der Übersichtlichkeit und Vergleichbarkeit (vgl. Kapitel 5.1.1), da auf Basis der Tabellenfelder Zuordnungen einfach und schnell identifiziert werden können. Im Kontext der Bewertung einer Softwarearchitektur wird analysiert, wie die Pattern, die in-

p1

p2

p3

pm

nerhalb der Architektur eingesetzt werden, die Qualitätsanforderungen des Systems unterstützen (vgl. Kapitel 3.3.2.1). Es stellt sich ausgehend von einem Pattern die Frage, welche Qualitätsmerkmale durch das Pattern beeinflusst werden (siehe Abbildung 5-4).

Abbildung 5-4: Herleitung der Lösung im Kontext der Bewertung

In diesem Kontext stellen die Vorspalten die Problemmerkmale (Symptome) und die Kopfzeilen die Problemlösungen (Diagnosen) dar (vgl. [Pupp1990, S. 42]). Die Herleitung der Lö-

Entwicklung des Wissensmodells

143

sungen erfolgt ausgehend von den Pattern über die Zuordnungen zu den unterstützten Qualitätsmerkmalen, was Abbildung 5-4 am Beispiel des Pattern p3 verdeutlicht. Im Kontext des Entwurfs einer Softwarearchitektur ist die Fragestellung genau umgekehrt. Die zu unterstützenden Qualitätsmerkmale sind als Anforderung bekannt und es wird die Menge von Pattern gesucht, die ein Qualitätsmerkmal unterstützen und somit potenzielle Kan-

p1

p2

p3

pm

didaten für die Nutzung innerhalb der Softwarearchitektur sind (siehe Abbildung 5-5).

Abbildung 5-5: Herleitung der Lösung im Kontext des Entwurfs

Die Kopfzeilen stellen die Problemmerkmale (Symptome) dar; die Vorspalten bilden die Problemlösungen (Diagnosen) in der Form von Pattern ab. Abbildung 5-5 verdeutlicht diese Herleitung beispielhaft an dem Qualitätsmerkmal q2. In Kapitel 5.4 wird die Verwendung des Wissensmodells im Kontext der Bewertung und des Entwurfs von Softwarearchitekturen, insbesondere unter Berücksichtigung der verschiedenen Kategorien der Zuordnung, im Detail diskutiert. Die Herleitung auf Basis der einfachen Navigation in Zeilen und Spalten – unter Berücksichtigung der unterschiedlichen Anforderungen innerhalb des Bewertungs- und Entwurfsprozesses – unterstützt das Ziel der Nachvollziehbarkeit (vgl. Kapitel 5.1.1). Mit Ausnahme der Kopfzeilen wird für jedes Feld der Tabelle eine entsprechende Syntax auf Basis einer erweiterten Backus-Naur-Form definiert, um die Übersichtlichkeit und Nachvollziehbarkeit zu gewährleisten. Hierbei wird aufgrund der weiten Verbreitung die Metasyntax genutzt, die bei der Definition der sog. Extensible Markup Language (XML) verwendet wird (siehe [BPSM2004]). In den folgenden Kapiteln werden nur die jeweils für das Verständnis der Vorspalten und Tabellenfelder relevanten Ableitungsregeln (Produktionen) dargestellt. Die vollständige Grammatik befindet sich im Anhang A.

144

Entwicklung eines pattern-basierten Wissensmodells

Da die Pattern-Kataloge bzw. -Dokumentationen i. d. R. in der englischen Sprache verfasst sind, ist die Tabelle ebenfalls in der englischen Sprache verfasst, um so die einfache Nachvollziehbarkeit zu gewährleisten und potenzielle Interpretationsfehler durch inkorrekte Übersetzung zu vermeiden. Die Grammatik im Anhang A ist analog in der englischen Sprache verfasst. Um die Nachvollziehbarkeit zu erleichtern, enthalten – mit Ausnahme der Vorspalte für den Namen des Pattern – alle Produktionsregeln für die Befüllung der Felder eine Referenz auf die Seite der Pattern-Dokumentation. Die Referenz belegt die Seite, von der die extrahierte Information stammt. Insbesondere die Zuordnung zwischen den Pattern und den Qualitätsmerkmalen wird so begründet.

5.1.3 Definition eines homogenen Qualitätsmodells Der erste Teil des internationalen Standards ISO/IEC 9126 dokumentiert durch die Definition eines homogenen Qualitätsmodells mit einheitlichen Qualitätsmerkmalen eine konsistente Terminologie für die Qualität von Softwareprodukten (vgl. Kapitel 3.2.3.1). Darüber hinaus bildet der erste Teil des Standards einen Rahmen, der im Kontext der Softwareentwicklung bei der Spezifikation der qualitäts-bezogenen Anforderungen verwendet werden kann, um die Vollständigkeit der spezifizierten Anforderungen zu überprüfen (vgl. [ISIE2001, S. 1]). Um die Vergleichbarkeit, Nachvollziehbarkeit und Vollständigkeit zu unterstützen, wird bei der Definition eines homogenen Qualitätsmodells im Kontext der Entwicklung des Wissensmodells auf diesen Standard zurückgegriffen. Dabei wird nur der erste Teil des Qualitätsmodells verwendet, der sechs Qualitätsmerkmale und deren Teilmerkmale für die interne und externe Qualität eines Softwareprodukts definiert. Der zweite Teil definiert vier Qualitätsmerkmale, die aus der Sicht eines Benutzers des Softwareprodukts analysiert werden. Diese Merkmale messen nicht unmittelbar die Eigenschaften der Software, sondern die Leistungsfähigkeit des Softwareprodukts, einen Benutzer, der ein spezifiziertes Ziel erreichen möchte, zu unterstützen (vgl. [ISIE2001, S. 12]). Sie sind nicht zu verwechseln mit dem Qualitätsmerkmal der Benutzerbarkeit (usability), das die Leistungsfähigkeit des Softwareprodukts im Hinblick auf die Verständlichkeit, Erlernbarkeit und Bedienbarkeit definiert (vgl. [ISIE2001, S. 12]). Da das Wissensmodell die Zuordnungen von Pattern und den beeinflussten Qualitätsmerkmalen auf der Abstraktionsebene der Softwarearchitektur abbildet, sind der genaue Kontext und die Ziele eines Benutzers, die mit Hilfe des Softwareprodukts erreicht werden sollen, nicht bekannt. Die vier Qualitätskriterien aus der Sicht des Benutzers werden daher im Kontext des Wissensmodells nicht weiter betrachtet. Die hier eingenommene spezielle Sicht auf die Ebene der Softwarearchitektur ist auch der Grund für die geringfügige Änderung bzw. Erweiterung des ersten Teils des Qualitätsmodells.

Entwicklung des Wissensmodells

145

Das Qualitätsmerkmal der Funktionalität (functionality) wird nicht vollständig betrachtet, da die Softwarearchitektur und die Funktionalität einer Anwendung nicht direkt voneinander abhängen (vgl. Kapitel 3.2.2.2) und im Kontext der Vorgehensweise sowie des Wissensmodells lediglich die Softwarearchitektur betrachtet wird. Das Teilmerkmal der Sicherheit (security) ist dagegen ein architektur-relevantes Merkmal und wird deshalb im Wissensmodell gesondert als neues Hauptmerkmal betrachtet (vgl. Kapitel 3.2.3.6). Es kann in weitere Teilmerkmale verfeinert werden. In einer Anmerkung beschreibt der ISO/IEC 9126-Standard, dass sich das Merkmal der Sicherheit auch auf die Daten bezieht, die übertragen werden (siehe [ISIE2001, S. 8]). In Anlehnung an diese Erweiterung des Sicherheitsaspekts wird bei der Verfeinerung auf den zweiten Teil des Standards ISO/IEC 7498 (siehe [ISIE1989]) zurückgegriffen. Dieser Standard enthält eine allgemeine Beschreibung von Sicherheitsdiensten und -mechanismen, die im Kontext des sog. ISO/OSI-Referenzmodells (siehe [ISIE1994]) spezifiziert werden. Auf der Basis der dort definierten Sicherheitsdienste werden die Teilmerkmale Authentifikation (authentication), Zugriffskontrolle (access control), Vertraulichkeit der Daten (data confidentiality), Integrität der Daten (data integrity) und Unleugbarkeit (non-repudiation) differenziert (vgl. [ISIE1989]). Zusätzlich werden die Teilmerkmale Verfügbarkeit (availability) und Auditierung (auditing) unterschieden (vgl. [BaCK2003, S. 86]). Das Qualitätsmerkmal der Wartbarkeit (maintainability) wird in Modifizierbarkeit (modifiability) umbenannt, um Verwechselungen mit der Ebene der Implementierung bzw. des Quellcodes zu vermeiden. Die Modifizierbarkeit und die untergeordneten Teilmerkmale beziehen sich auf die Ebene der Softwarearchitektur. Die Portabilität (portability) wird als Teilmerkmal der Modifizierbarkeit definiert, denn sofern die Portierung eine Modifikation der Softwarearchitektur erfordert, ist die Portabilität eine spezialisierte Form der Modifizierbarkeit [ClKK2002, S. 31]. Die Modifizierbarkeit kann durch das Teilmerkmal der Variabilität (variability) weiter verfeinert werden. Die Variabilität definiert das Maß, in dem eine Softwarearchitektur erweitert oder modifiziert werden kann, um neue Architekturen zu erstellen, die sich in einer bestimmten, vorausgeplanten Art und Weise voneinander unterscheiden [ClKK2002, S. 31]. Dieses Teilmerkmal lässt sich weiterhin durch das Merkmal der Fähigkeit der Teilmengenbildung (subsetability) verfeinern. Dieses Teilmerkmal beschreibt die Fähigkeit einer Softwarearchitektur, lediglich eine Teilmenge des Systems zu implementieren und so eine inkrementelle Lieferung eines Softwareprodukts zu ermöglichen [ClKK2002, S. 31]. Die Teilmerkmale, die jeweils die Fähigkeit zur Einhaltung von entsprechenden Standards, Konventionen und Regulationen im Kontext eines Hauptmerkmals messen (vgl. [ISIE2001, S. 9-11]), werden aufgrund ihrer ungenauen Definition im Wissensmodell nicht weiter betrachtet. Die jeweiligen Standards, Konventionen und Regulationen sind u. U. namentlich be-

146

Entwicklung eines pattern-basierten Wissensmodells

kannt, jedoch müssten deren konkrete Inhalte bekannt sein, um hier eine Zuordnung zu Pattern abzubilden. Die Tabellen 5-1, 5-2 und 5-3 listen die im Wissensmodell verwendeten Qualitätsmerkmale mit ihrer hierarchischen Struktur auf und dokumentieren für jedes Merkmal eine kurze Beschreibung gemäß der verwendeten Quelle. Für eine detaillierte Beschreibung der Qualitätsmerkmale werden die entsprechenden Standards bzw. Quellen referenziert (siehe [ISIE2001; ITU199130; ClKK2002; BaCK2003]). Um die Nachvollziehbarkeit zu gewährleisten, sind die Merkmale und die Kurzbeschreibung in der englischen Sprache verfasst. Für jedes Merkmal wird eine deutsche Übersetzung dokumentiert, um die Nachvollziehbarkeit innerhalb der vorliegenden Arbeit zu gewährleisten.

Hauptmerkmal

Teilmerkmal 1. Ebene

Teilmerkmal 2. Ebene

Kurzbeschreibung The capability of the software product to maintain a specified level of performance when used under specified conditions [ISIE2001, S. 8].

Reliability (Zuverlässigkeit) Maturity (Reife)

The capability of the software product to avoid failure as a result of faults in the software [ISIE2001, S. 8].

Fault tolerance (Fehlertoleranz)

The capability of the software product to maintain a specified level of performance in cases of software faults or of infringement of its specified interface [ISIE2001, S. 9].

Recoverability (Wiederherstellbarkeit)

The capability of the software product to re-establish a specified level of performance and recover the data directly affected in the case of failure [ISIE2001, S. 9]. The capability of the software product to be understood, learned, used and attractive to the use, when used under specified conditions [ISIE2001, S. 8].

Usability (Benutzbarkeit)

Understandability (Verständlichkeit)

The capability of the software product to enable the user to understand whether the software is suitable, and how it can be used for particular tasks and conditions of use [ISIE2001, S. 9].

Learnability (Erlernbarkeit)

The capability of the software product to enable the user to learn its application [ISIE2001, S. 9].

Tabelle 5-1: Qualitätsmerkmale des Wissensmodells (Teil 1)

30

Da der zweite Teil des Standards ISO/IEC 7498 nicht frei verfügbar ist, wird an dieser Stelle die ITU-Empfehlung X.800 referenziert. Der zweite Teil des ISO/IEC-Standards und die ITU-Empfehlung sind allerdings technisch identisch (vgl. [ITU1991, S. 1]).

Entwicklung des Wissensmodells

Hauptmerkmal

Teilmerkmal 1. Ebene

147

Teilmerkmal 2. Ebene

Kurzbeschreibung

Operability (Bedienbarkeit)

The capability of the software product to enable the user to operate and control it [ISIE2001, S. 9].

Attractiveness (Attraktivität)

The capability of the software product to be attractive to the user [ISIE2001, S. 10]. The capability of the software product to provide appropriate performance, relative to the amount of resources used, under stated conditions [ISIE2001, S. 10].

Efficiency (Effizienz)

Time behaviour (Zeitverhalten)

The capability of the software product to provide appropriate response and processing times and throughput rates when performing its function, under stated conditions [ISIE2001, S. 10].

Resource utilization (Verbrauchsverhalten)

The capability of the software product to use appropriate amounts and types of resources when the software performs its function under stated conditions [ISIE2001, S. 10]. The capability of the software product to be modified. [ISIE2001, S. 10].

Modifiability (Modifizierbarkeit) Analyzability (Analysierbarkeit)

The capability of the software product to be diagnosed for defenciencies or causes of failures in the software, or for parts to be modified to be identified [ISIE2001, S. 10].

Changeability (Veränderlichkeit)

The capability of the software product to enable a specified modification to be implemented [ISIE2001, S. 10].

Stability (Stabilität)

The capability of the software product to avoid unexpected effects from modifications of the software [ISIE2001, S. 10].

Testability (Prüfbarkeit)

The capability of the software product to enable modified software to be validated [ISIE2001, S. 11].

Portability (Übertragbarkeit)

The capability of the software product to be transferred from one environment to another [ISIE2001, S. 11]. Adaptability (Anpassbarkeit)

The capability of the software product to be adapted for different specified environments without applying actions or means other that those provided for this purpose for the software considered [ISIE2001, S. 11].

Tabelle 5-2: Qualitätsmerkmale des Wissensmodells (Teil 2)

148

Hauptmerkmal

Entwicklung eines pattern-basierten Wissensmodells

Teilmerkmal 1. Ebene

Teilmerkmal 2. Ebene

Kurzbeschreibung

Installability (Installierbarkeit)

The capability of the software product to be installed in a specified environment [ISIE2001, S. 11].

Co-existance (Koexistenz)

The capability of the software product to co-exist with other independent software in a common environment sharing common resources [ISIE2001, S. 11].

Replaceability (Austauschbarkeit)

The capability of the software product to be used in place of another specified software product for the same purpose in the same enviroment [ISIE2001, S. 11]. Variability is how well the architecture can be expanded or modified to produce new architectures that differ in specific, preplanned ways [ClKK2002, S. 31].

Variability (Variabilität)

Subsetability (Teilmengenbildung)

Subsetability is the ability to support the production of a subset of the system [ClKK2002, S. 31]. The capability of the software product to protect information and data so that unautorised persons or systems cannot read or modify them and autorised persons or systems are not denied access to them [ClKK2002, S. 8].

Security (Sicherheit)

Authentication (Authentifikatio)

The corroboration that the source of data received or a peer entity in an association is as claimed [ITU1991, S. 4, 6].

Access control (Zugriffskontrolle)

The prevention of unauthorized use of a resource, including the prevention of use of a resource in an unauthorized manner [ITU1991, S. 3].

Data confidentiality (Vertraulichkeit der Daten)

The property that information is not made available or disclosed to unauthorized individuals, entities, or processes [ITU1991, S. 4].

Data integrity (Integrität der Daten)

The property that data has not been altered or destroyed in an unauthorized manner [ITU1991, S. 4].

Non-repudiation (Unleugbarkeit)

Denial by one of the entities involved in a communication of having participated in all or part of the communication [ITU1991, S. 6].

Availability (Verfügbarkeit)

Availability is the property that despite of denail-of-service attacks the system will be available for legitimate use (vgl. [BaCK2003], S. 86]).

Auditing (Auditierung)

Auditing is the property that the system tracks activities within it at levels sufficient to reconstruct them [BaCK2003], S. 86].

Tabelle 5-3: Qualitätsmerkmale des Wissensmodells (Teil 3)

Entwicklung des Wissensmodells

149

Im Folgenden werden, um Missverständnisse zu vermeiden, einige Qualitätsmerkmale weiter erläutert, sofern die Definitionen der verwendeten Standards bzw. Quellen vom allgemeinen Sprachgebrauch abweichen. Das Merkmal der Interoperabilität (interoperability) wird im ISO/IEC 1926-Standard unterhalb des Hauptmerkmals der Funktionalität (functionality) eingeordnet und beschreibt die Fähigkeit des Softwareprodukts, mit einem oder mehreren anderen Systemen zusammenzuarbeiten (vgl. [ISIE2001, S. 8]). Der Begriff der Interoperabilität wurde in diesem Kontext anstelle des Begriffs „compatibility“ verwendet, um eine Verwechselung mit dem Merkmal Austauschbarkeit (replaceability) zu vermeiden. Austauschbarkeit wird als die Fähigkeit eines Softwareprodukts definiert, anstelle eines anderen Softwareprodukts für einen bestimmten Zweck verwendet werden zu können (vgl. [ISIE2001, S. 11]). Das Merkmal der Interoperabilität wird im Wissensmodell nicht betrachtet, da das Qualitätsmerkmal der Funktionalität (functionality) nicht (vollständig) betrachtet wird. Das Merkmal der Austauschbarkeit wird – wie alle anderen verwendeten Merkmale – auf der Ebene der Softwarearchitektur betrachtet und als die Fähigkeit einer Softwarearchitektur verstanden, einzelne Softwareelemente (vgl. Kapitel 2.1) durch andere Softwareelemente austauschen zu können. In diesem Sinn entspricht diese Definition dem allgemeinen Sprachgebrauch der Interoperabilität. Die Verfügbarkeit (availability) ist die Fähigkeit einer Software, zu einem bestimmten Zeitpunkt und unter definierten Bedingungen in der Lage zu sein, eine erforderliche Funktion auszuführen [ISIE2001, S. 9]. Sie kann extern durch das Verhältnis zwischen der Zeit in der die Software nutzbar ist, und der Zeit in der die Software nutzbar sein soll, gemessen werden. Die Verfügbarkeit ist eine Kombination aus den Merkmalen Reife (die die Häufigkeit von Ausfällen wiedergibt), Fehlertoleranz und Wiederherstellbarkeit (die die Länge der Zeit nach einem Ausfall wiedergibt) (vgl. [ISIE2001, S. 9; BaCK2003, S. 86]). Das Merkmal der Verfügbarkeit, das nicht (direkt) im Qualitätsmodell verwendet wird, kann auf Basis der Merkmale Reife, Fehlertoleranz und Wiederherstellbarkeit abgeleitet werden. Das Teilmerkmal der Verfügbarkeit (availability) unterhalb des Hauptmerkmals der Sicherheit betrachtet den speziellen Kontext der sog. Denial-of-Service-Angriffe (vgl. [BaCK2003], S. 86]). Hier erfolgt aufgrund des speziellen Kontexts keine weitere Verfeinerung in die Teilmerkmale Reife, Fehlertoleranz und Wiederherstellbarkeit. Bei der Verwendung des Qualitätsmodells muss stets beachtet werden, dass die Zuordnungen auf der konzeptuellen Ebene der Softwarearchitektur erfolgen. Die Zuordnungen dokumentieren die Beeinflussung von einem oder mehreren Qualitätsmerkmal(en) durch die Softwarearchitektur. Hierbei soll die hierarchische Struktur des Qualitätsmodells berücksichtigt werden. Die Zuordnungen sollen innerhalb der Hierarchie so tief wie möglich erfolgen, um eine möglichst genaue Zuordnung zu dokumentieren (siehe Kapitel 5.2.2.2).

150

Entwicklung eines pattern-basierten Wissensmodells

5.1.4 Katalog-übergreifende Identifikation von Pattern Die Vorspalte „Pattern Name“ enthält den Namen des Pattern, der unverändert aus dem Pattern-Katalog bzw. der Pattern-Dokumentation übernommen wird. Der Name soll durch einen intuitiven Bezeichner die Essenz des Pattern kommunizieren (vgl. [BMRS1996, S. 19]) und dazu beitragen, das Entwurfsvokabular auf einem höheren Abstraktionsniveau zu erweitern (vgl. [GHJV1995, S. 3; ShGa1996, S. 2]). Durch die unveränderte Übernahme in das Wissensmodell wird das in den Pattern-Katalogen definierte Entwurfsvokabular wiederverwendet und kann innerhalb des Entwurfs bzw. der Bewertung genutzt werden. Die Vorspalte „Source“ definiert den Pattern-Katalog, in dem das Pattern dokumentiert ist, auf Basis einer Kurzbezeichnung und dem Erscheinungsjahr. Eine Referenz auf die erste Seite der Pattern-Dokumentation ermöglicht die Navigation innerhalb des Katalogs. Die Kurzbezeichnung und Referenz gewährleisten die Nachvollziehbarkeit in Bezug auf die erfassten Pattern. Abbildung 5-6 stellt zur Verdeutlichung einen Auszug aus der Grammatik im Anhang A dar.

/*---------------------------------------------------------------------*/ /* Column: Pattern Name */ PatternName ::= Name /* The name used in the pattern catalog */ /*---------------------------------------------------------------------*/ /* Column: Source */ Source

::= ShortTermOfSource YearOfPublication " (" PageNumber ")"

ShortTermOfSource ::= OneAuthor | TwoAuthors | ThreeAutors | FourAuthors | MoreThanFourAuthors

Abbildung 5-6: Ableitungsregeln für die Vorspalten „Pattern Name“ und „Source“

Die Kurzbezeichnung des Pattern-Katalogs setzt sich entsprechend der Anzahl der Autoren aus einer fest definierten Menge von Buchstaben des Nachnamens zusammen31. Der Aufbau 31

Auf die Verwendung von Kurzbezeichnungen, die auf Basis des Titels eines Pattern-Katalogs gebildet werden (vgl. z. B. „POSA 1“ für [BMRS1996], „POSA 2“ für [SSRB2000] und „PEAA“ für [Fowl2003]), wurde bewusst verzichtet, da erstens zur Bildung des Titels kein eindeutiger Algorithmus definiert bzw. verbreitet ist und zweitens nicht für alle Kataloge eine derartige Kurzbezeichnung verwendet wird.

Entwicklung des Wissensmodells

151

entspricht im Wesentlichen dem in dieser Arbeit verwendeten Algorithmus zur Bildung der Kurzbezeichung von Quellen (vgl. Anhang A). Der Fall von mehreren gleichen Kurzbezeichnungen, die durch die Veröffentlichung von mehreren Pattern-Katalogen durch die gleichen Autoren innerhalb nur eines Jahres entstehen können, wird nicht berücksichtigt. Dieser Fall wird als unwahrscheinlich eingeschätzt und hätte eine Erhöhung der Komplexität der Ableitungsregeln zur Folge. Da die Eindeutigkeit des Pattern-Namens nur innerhalb eines Pattern-Katalogs gewährleistet ist, ist eine eindeutige Identifikation allein aufgrund des Namens nicht möglich. Im J2EE Core Patterns-Katalog (siehe [AlCM2003]) und in den von Fowler dokumentierten Pattern (siehe [Fowl2003]) sind z. B. die Pattern „Application Controller“ und „Front Controller“ enthalten. Zur eindeutigen und katalog-übergreifenden Identifikation eines Pattern werden beide Vorspalten der Tabelle benötigt. Hierdurch wird die Erweiterbarkeit des Wissensmodells in Bezug auf die Menge der Pattern gewährleistet.

5.1.5 Identifikation des Pattern-Typs und des Bezugs der Zuordnung Die Vorspalte „Pattern Type“ dokumentiert explizit den Typ des Pattern, um die hier eingenommene spezielle Sicht auf die Abstraktionsebene der Softwarearchitektur hervorzuheben. Grundsätzlich kann zwischen einem Pattern auf der Architekturebene und einem Pattern auf der Entwurfsebene differenziert werden (vgl. Kapitel 4.1.3). Da nicht alle Pattern-Kataloge eine Klassifikation anhand der beiden Pattern-Typen vornehmen, wird durch diese Vorspalte zunächst dokumentiert, ob eine Klassifikation auf Basis des Katalogs vorliegt. Wenn innerhalb des Katalogs explizit zwischen einem Pattern der Architektur- und der Entwurfsebene unterschieden wird, wird durch eine Referenz auf die Seite(n) im Pattern-Katalog die Klassifikation nachvollziehbar. Die folgenden Vorspalten „Context“, „Stimulated Artifact“ und „Supported General Scenarios“ dokumentieren den Bezug der Zuordnung, der auf Basis des Modells der Qualitätsmerkmal-Szenarios (vgl. Kapitel 3.2.4.3) abgebildet wird. Dieser Bezug ist notwendig, um die zugeordneten Qualitätsmerkmale operationalisierbar zu machen, indem insbesondere durch das stimulierte Artefakt ein Kontext hergestellt wird, in dem das Qualitätsmerkmal interpretiert wird (vgl. Kapitel 3.2.4.3). Ohne diesen Bezug hat ein Qualitätsmerkmal keine Aussagekraft (vgl. Kapitel 3.2.2.3). Die Vorspalte „Context“, die i. d. R. in jedem Pattern-Katalog vorhanden ist, skizziert den Kontext, in dem das Pattern angewendet werden kann (vgl. Kapitel 4.2.1.1). Die Vorspalte „Stimulated Artifact“ beschreibt im Sinne des Modells der QualitätsmerkmalSzenarios das Softwareelement der Architektur, das durch einen Stimulus beeinflusst wird. Die Reaktion dieses Artefakts und das Ausmaß der Reaktion werden als Indikator (vgl. Kapitel 3.2.2.1) für die Zuordnung zu einem Teilmerkmal des Qualitätsmodells verwendet. Das

152

Entwicklung eines pattern-basierten Wissensmodells

stimulierte Artefakt verfeinert den groben Kontext und bildet den Bezugsrahmen, auf dessen Basis die Zuordnung zu einem Teilmerkmal erfolgt (siehe Kapitel 5.1.7). Ohne diesen Bezug ist eine Zuordnung nicht aussagekräftig (vgl. Kapitel 3.2.2.3), wie das folgende Beispiel verdeutlichen soll (vgl. [BaCK2003, S. 74]): Die Aussage, dass eine Softwarearchitektur änderbar sein soll, ist nichtssagend, denn jede Architektur ist im Hinblick auf eine Menge von Änderungen mit weniger Aufwand und für eine andere Menge von Änderungen mit mehr Aufwand modifizierbar. Erst durch den Bezug zu einem Artefakt entsteht eine Aussagekraft, die z. B. durch eine Aufwandsschätzung detailliert werden kann. Eine bestimmte Softwarearchitektur könnte z. B. im Hinblick auf ihre Benutzeroberfläche mit wenig Aufwand änderbar sein, wohingegen die Modifikation des Datenmodells mit viel Aufwand verbunden ist. Es ist zu beachten, dass ohne den Bezug zu einer konkreten Softwarearchitektur keine quantitative Messung der Reaktion stattfinden kann (vgl. Kapitel 3.2). Die Aussage beschreibt somit auf einem abstrakten Niveau das grundsätzliche Verhalten des Reaktionsmaßes. Um den Bezugsrahmen der Zuordnung weiter zu verdeutlichen, enthält die Vorspalte „Supported General Scenarios“ eine Liste der allgemeinen Szenarios (vgl. Kapitel 3.2.4.3), die durch das Pattern unterstützt werden. Diese Szenarios sind implizit innerhalb der PatternDokumentation vorhanden und werden durch die Vorgehensweise extrahiert. Dabei wird auf eine getrennte Erfassung der einzelnen Elemente eines Qualitätsmerkmal-Szenarios und die Berücksichtigung des optionalen Charakters der Elemente (vgl. [BaCK2003, S. 75 f.]) zugunsten des Ziels der Übersichtlichkeit bewusst verzichtet und die Szenarios in einem satzbasierten Format erfasst. Die Identifikation des Pattern-Typs und des Bezugs der Zuordnung unterstützt die Nachvollziehbarkeit des Wissensmodells. Durch die Dokumentation des Pattern-Typs wird explizit die Sicht auf die Ebene der Softwarearchitektur hervorgehoben. Wird ein Pattern durch den Katalog als ein Pattern auf der Ebene der Softwarearchitektur klassifiziert, wird dies im Wissensmodell dokumentiert und über eine Referenz innerhalb des Katalogs nachvollziehbar (siehe Abbildung 5-7). Die Vorspalten zur Dokumentation des Bezugs der Zuordnung stellen auf Basis des Modells der Qualitätsmerkmal-Szenarios einen Kontext her, der durch die Vorspalten „Context“, „Stimulated Artefact“ und „Supported General Scenarios“ sukzessive verfeinert wird. Durch die Angabe von Seitenreferenzen wird dieser Kontext nachvollziehbar gemacht. Darüber hinaus wird durch Referenzen auf den jeweiligen Abschnitt der Pattern-Schablone die Navigation innerhalb der Pattern-Dokumentation vereinfacht (siehe Abbildung 5-7). Die Dokumentation des Abschnitts innerhalb der Pattern-Schablone ermöglicht darüber hinaus eine Auswertung im Hinblick auf die Fragestellung, wo in der Pattern-Dokumentation, welche Informationen extrahiert werden können. Abbildung 5-7 zeigt zur Verdeutlichung einen Auszug aus der Grammatik im Anhang A.

Entwicklung des Wissensmodells

153

/*---------------------------------------------------------------------*/ /* Column: Pattern Type */ PatternType ::= "Architectural" PageReferences | "-" /* A simple dash means that there is no explicit classification in the pattern catalog */

/*---------------------------------------------------------------------*/ /* Column: Context Context

::= ContextDescription PageReferences SectionReferences

ContextDescription ::= Description

/*---------------------------------------------------------------------*/ /* Column: Stimulated Artifact */ SimulatedArtifact

::= SimulatedArtifactDescription PageReferences SectionReferences

SimulatedArtifactDescription ::= Description

/*---------------------------------------------------------------------*/ /* Column: Supported General Scenarios */ SupportedGeneralScenarios ::= SupportedGeneralScenario* SupportedGeneralScenario

::= " - " SupportedGeneralScenarioDescription PageReferences SectionReferences

SupportedGeneralScenarioDescription ::= Description

Abbildung 5-7: Ableitungsregeln für die Vorspalten „Pattern Type“, „Context“, „Stimulated Artifact“ und „Supported General Scenarios“

5.1.6 Identifikation und Klassifikation der Beziehungen zwischen Pattern In der Vorspalte „Relationships“ werden die Beziehungen zwischen den Pattern dokumentiert, wobei drei grundsätzliche Beziehungstypen unterschieden werden: die Nutzungs-, Vererbungs- und Alternativ-Beziehung. Bei der Nutzungs- und Vererbungs-Beziehung werden je-

154

Entwicklung eines pattern-basierten Wissensmodells

weils zwei verschiedene (Sub-)Beziehungstypen unterschieden, um explizit die Richtung der Beziehung zu dokumentieren. Es wird für jeden der insgesamt fünf Beziehungstypen die Kardinalität der Beziehung beschrieben und eine Referenz in Bezug auf den Pattern-Katalog dokumentiert. Abbildung 5-8 zeigt zur Verdeutlichung einen Auszug aus der Grammatik im Anhang A.

/*---------------------------------------------------------------------*/ /* Column: Relationships */ Relationships

::=

Relationship*

Relationship

::= " - " RelationshipType " (" Cardinality "): " PatternName PageReferences SectionReferences

RelationshipType ::= "uses" | "is used by" | "generalises" | "specialises" | "is alternative to" Cardinality

::= "optional" | "required"

Abbildung 5-8: Ableitungsregeln für die Vorspalte „Relationships“

Die Nutzungs-Beziehung entspricht im Fall einer verbindlichen Kardinalität semantisch dem von Zimmer identifizierten Beziehungstyp „Pattern X nutzt Pattern Y innerhalb der Lösung“, d. h., der Einsatz eines Pattern X führt zu einem untergeordneten Problem, das mit dem Pattern Y gelöst wird (vgl. Kapitel 4.2.3.1). Das Pattern X benutzt das Pattern Y innerhalb seiner Lösung und ist deshalb ein (verbindlicher) Teil der Lösung des Pattern X. Im Fall einer optionalen Kardinalität entspricht die Beziehung dem von Zimmer identifizierten Beziehungstyp „Pattern X kann mit dem Pattern Y kombiniert werden“, d. h., zwei Pattern X und Y können miteinander kombiniert werden, ohne dass das Pattern X das Pattern Y innerhalb seiner Lösung verwenden muss (vgl. Kapitel 4.2.3.1). Die Pattern sind grundsätzlich unabhängig voneinander. Die Semantik der Vererbungs-Beziehung wird in Anlehnung an die Vererbungsmechanismen einer objekt-orientierten Programmiersprache definiert. Ein allgemeines Pattern X kann z. B. durch ein Pattern Y spezialisiert werden, wenn das Pattern Y die Problemstellung und Lösung des Pattern X im Kontext einer spezifischen Entwicklungsplattform und/oder Umgebung beschreibt. Analog verallgemeinert das Pattern X die Problemstellung und Lösung, ohne die Details einer spezifischen Entwicklungsplattform und/oder Umgebung zu berücksichtigen. Die Alternativ-Beziehung entspricht semantisch der Beziehung "Pattern X ist ähnlich wie Pattern Y" von Zimmer, d. h., die Pattern X und Y adressieren ein ähnliches Problem, aber mit unterschiedlichen Lösungsansätzen (vgl. Kapitel 4.2.3.1). Die Kardinalität spiegelt bei diesem Beziehungstyp wider, wie ähnlich die Problemstellungen von Pattern X und Y sind,

Entwicklung des Wissensmodells

155

d. h., ein Pattern X kann eine „echte“ Alternative zu einem Pattern Y sein („required“) oder ein Pattern X ist nur unter der Berücksichtigung von bestimmten Annahmen eine Alternative zum Pattern Y („optional“). Die Beziehungen zwischen den Pattern werden in der vorliegenden Arbeit auf einem relativ hohen Abstraktionsniveau betrachtet, da eine detailliertere Betrachtung der Semantik der Beziehungen nicht im Fokus der vorliegenden Arbeit steht. Das Abstraktionsniveau ist aber ausreichend, um den Entwurf und die Bewertung einer Softwarearchitektur zu unterstützen (vgl. Kapitel 5.4). Die weiterführende Betrachtung und Verfeinerung der Semantik der Beziehungen ist eine potenzielle Erweiterung des Wissensmodells (siehe Kapitel 6.2.2). Die Dokumentation einer Beziehung beginnt mit einer fest definierten Zeichenkette, die den Beziehungstyp identifiziert. Im Anschluss an diese Zeichenkette folgt die Spezifikation der Kardinalität der Beziehung und des Namens des Pattern, das an der Beziehung beteiligt ist. Der Pattern-Name wird analog zur Vorspalte „Pattern Name“ gebildet, d. h., der Name wird unverändert aus dem Pattern-Katalog bzw. der Pattern-Dokumentation übernommen (vgl. Kapitel 5.1.4). Die Beziehungen werden durch die Angabe von Seitenreferenzen und Referenzen auf den jeweiligen Abschnitt der Pattern-Schablone nachvollziehbar (vgl. Abbildung 5-8). Das Ziel der Vergleichbarkeit wird unterstützt, da die Beziehungen der Pattern, die innerhalb der PatternKataloge in unterschiedlichem Umfang beschrieben werden (vgl. Kapitel 4.2.3), auf Basis von fünf einheitlichen Beziehungstypen dokumentiert werden.

5.1.7 Klassifikation der Auswirkungen Das Wissensmodell soll unabhängig von einem speziellen Anwendungsfall des Entwurfs bzw. der Bewertung einer Softwarearchitektur verwendet werden können (vgl. Kapitel 5.1.1). Der Kern des Wissensmodells beinhaltet die Abbildung der jeweils durch ein Pattern beeinflussten Qualitätsmerkmale. Pattern sind erprobte Lösungen für wiederkehrende Entwurfsprobleme, die das Wissen bezüglich der Lösungen innerhalb von Pattern-Katalogen bzw. -Dokumentationen verfügbar machen (vgl. Kapitel 4.1). Ein Pattern beschreibt keinen konkreten Entwurf und keine konkrete Implementierung, sondern vielmehr eine Vorlage, die in vielen Situationen verwendet werden kann [GHJV1995, S. 3]. Pattern spezifizieren generische Lösungsansätze, die die wesentliche Struktur und das grundsätzliche Zusammenwirken von bestimmten Softwareelementen beschreiben [GHJV1995, S. 3]. Diese Vorgehensweise der Abstraktion ist vergleichbar mit den allgemeinen Szenarios im Kontext des Modells der Qualitätsmerkmal-Szenarios (vgl. Kapitel 3.2.4.3). Allgemeine Szenarios sind unabhängig von einer spezifischen Anwendung bzw. einem spezifischen System

156

Entwicklung eines pattern-basierten Wissensmodells

und können sich potenziell auf mehrere Anwendungen bzw. Systeme beziehen. Sie beschreiben lediglich die grundlegende Richtung und das wesentliche Ausmaß einer Reaktion in Bezug auf ein Qualitätsmerkmal. Da die Zuordnungen auf Basis des Pattern-Konzepts bzw. der Pattern-Dokumentationen abgebildet werden, erfolgt eine Zuordnung unabhängig von einem konkreten Entwurf bzw. von einer konkreten Implementierung. Analog zu dem generischen Lösungsansatz eines Pattern und dem Konzept der allgemeinen Szenarios, kann durch eine Zuordnung lediglich die grundlegende Richtung und das wesentliche Ausmaß einer Reaktion in Bezug auf ein Qualitätsmerkmal dargestellt werden. Die Auswirkung kann ausschließlich qualitativ abgebildet werden. Der Einsatz eines Pattern kann zu mehreren Reaktionen führen, da es sich insbesondere bei den Pattern auf der Architekturebene um Lösungen handelt, die die grundlegenden Strukturen einer Softwarearchitektur definieren und eine Vielzahl der Eigenschaften einer Anwendung beeinflussen (vgl. [BMRS1996, S. 12]). Die Reaktionen, die durch den Einsatz eines Pattern hervorgerufen werden, können sich auf ein oder mehrere Qualitätsmerkmale beziehen. Die Auswirkungen eines Pattern umfassen die Menge der Reaktionen, die jeweils ein oder mehrere Qualitätsmerkmale beeinflussen. Für jede Reaktion werden die grundlegende Richtung und das Ausmaß der Reaktion spezifiziert. Die grundlegende Richtung einer Reaktion wird auf Basis der Rangfolge definiert, die die Analyse der Metriken des ISO/IEC 9126-Standards ergeben hat (vgl. Kapitel 3.2.3.5). Diese Rangfolgen sind im Wesentlichen mit den Rangfolgen identisch, die u. a. durch die architektur-bezogenen Taktiken zur Erreichung von Qualitätsmerkmalen definiert werden (vgl. Kapitel 4.1.3). Das Ausmaß einer Reaktion wird auf Basis von vier Kategorien klassifiziert, die den unterschiedlichen Grad der Auswirkung darstellen. Der Grad beschreibt qualitativ das Ausmaß einer Reaktion. Die Klassifikation verwendet u. a. das Konzept der Sensitivitäts- und der Abwägungspunkte der ATAM (vgl. Kapitel 3.3.2.2) und wird um eine rein positive sowie negative Auswirkung ergänzt. Die Dokumentation der Beeinflussung erfolgt innerhalb der Felder der Tabelle. Das relevante Feld wird in vertikaler Richtung durch das Pattern und in horizontaler Richtung durch das Qualitätsmerkmal definiert (vgl. Kapitel 5.1.2). Tabelle 5-4 erläutert die vier Kategorien zunächst kurz im Überblick.

Entwicklung des Wissensmodells

157

Kategorie des Ausmaß einer Reaktion

Beschreibung der Kategorie

Positive Reaktion (positive response)

Eine positive Reaktion charakterisiert die Beeinflussung eines Qualitätsmerkmals, die bei einer Messung auf Basis einer Metrik grundsätzlich zu besseren Werten auf der Skala führt.

Sensitivitätspunkt (sensitivity point)

Die Kategorie des Sensitivitätspunkts stellt eine Reaktion dar, die direkt von einer Eigenschaft eines oder mehrerer Softwareelemente und/oder deren Beziehungen untereinander abhängt. Die Ausprägungen dieser Eigenschaft determinieren, ob eine positive oder negative Reaktion eintritt.

Abwägungspunkt (tradeoff point)

Die Kategorie des Abwägungspunkts charakterisiert eine Beeinflussung mehrerer Qualitätsmerkmale. Ob ein bestimmtes Qualitätsmerkmal positiv oder negativ beeinflusst wird, hängt allerdings direkt von einer Eigenschaft eines oder mehrerer Softwareelemente und/oder deren Beziehungen untereinander ab. Die Ausprägungen dieser Eigenschaft determinieren, ob eine positive oder negative Reaktion eintritt. Verschiedene Qualitätsmerkmale können auch unterschiedlich beeinflusst werden.

Negative Reaktion (negative response)

Eine negative Reaktion beschreibt eine Beeinflussung eines Qualitätsmerkmals, die bei einer Messung auf Basis einer Metrik grundsätzlich zu schlechteren Werten auf der Skala führt. Tabelle 5-4: Kategorien des Ausmaßes einer Reaktion

Da der Einsatz eines Pattern zu mehreren Reaktionen führen kann, können auch mehrere Reaktionen in einem Tabellenfeld dokumentiert werden. Abbildung 5-9 zeigt zur Verdeutlichung einen Ausschnitt aus der Grammatik im Anhang A. Der Ausgangspunkt für die Gestaltung eines Tabellenfelds ist die Ableitungsregel „EffectOnQualityCharacteristic“. Sie ist für alle Felder der Tabelle relevant.

/*---------------------------------------------------------------------*/ /* Effect on quality characteristic */ EffectOnQualityCharacteristic ::= ( ( ( (

PositiveResponse )* Sensitivitypoint )* Tradeoffpoint )* NegativeResponse )*

Abbildung 5-9: Ableitungsregel für die Beeinflussung eines Qualitätsmerkmals

Da der Einsatz eines Pattern zu mehreren Reaktionen führen kann, können zu jeder Kategorie eine oder mehrere Reaktionen innerhalb eines Tabellenfelds erfasst werden. Dies wird durch den Listen-Operator „*“ spezifiziert (vgl. [BPSM2004]). Jedes Feld der Tabelle kann eine Liste von positiven Reaktionen, Sensitivitätspunkten, Abwägungspunkten oder negativen Re-

158

Entwicklung eines pattern-basierten Wissensmodells

aktionen enthalten, wobei die Liste auch leer sein kann. Die Ableitungsregel spezifiziert darüber hinaus eine Reihenfolge der Listen, um die Übersichtlichkeit und Vergleichbarkeit zu gewährleisten. Ein Tabellenfeld enthält zunächst eine (optionale) Liste der positiven Reaktionen gefolgt von einer (optionalen) Liste der Sensitivitätspunkte, einer (optionalen) Liste der Abwägungspunkte und einer (optionalen) Liste der negativen Reaktion. Die Risiken und Sicherheiten (vgl. Kapitel 3.3.2.3), die bestimmte Werte bzw. Ausprägungen der Eigenschaften von Sensitivitätspunkten betrachten, können aufgrund des fehlenden Bezugs zu einer konkreten Bewertung nicht identifiziert werden. Da keine konkrete Softwarearchitektur vorliegt, sind keine konkreten Werte bzw. Ausprägungen bezüglich der Eigenschaften von Sensitivitäts- bzw. Abwägungspunkten vorhanden. Im Folgenden werden die unterschiedlichen Kategorien im Detail diskutiert und insbesondere die Syntax vorgestellt, mit der jeweils eine Reaktion eines Pattern innerhalb des Wissensmodells klassifiziert und dokumentiert wird.

5.1.7.1 Positive Reaktionen Eine positive Reaktion beschreibt eine direkte Beeinflussung eines Qualitätsmerkmals. Positiv in Bezug auf die Reaktion bedeutet, dass bei einer Messung auf Basis von einer oder mehrerer Metriken der Einsatz des Pattern grundsätzlich zu besseren Werten auf der jeweiligen Skala führt. Im Unterschied zu einem Sensitivitätspunkt (siehe Kapitel 5.1.7.2) führt der Einsatz des Pattern direkt zu besseren Werten auf der Skala. Es existiert keine einzelne Eigenschaft, die determiniert, ob die positive Reaktion eintritt oder nicht. Abbildung 5-10 verdeutlicht eine positive Reaktion.

Abbildung 5-10: Positive Reaktion in Bezug auf ein Qualitätsmerkmal Quelle: in Anlehnung an [BaCK2003, S. 75]

Die Dokumentation einer positiven Reaktion erfolgt auf Basis einer kurzen Beschreibung der positiven Reaktion innerhalb eines Felds der Tabelle. Das relevante Feld wird in vertikaler Richtung durch das Pattern und in horizontaler Richtung durch das Qualitätsmerkmal definiert (vgl. Kapitel 5.1.2). Da der Einsatz eines Pattern zu mehreren Reaktionen führen kann, können mehrere positive Reaktionen in einem Tabellenfeld dokumentiert werden, d. h., ein

Entwicklung des Wissensmodells

159

Feld kann eine Menge von positiven Reaktionen enthalten (vgl. Kapitel 5.1.7). Abbildung 5-11 zeigt einen Ausschnitt aus der Grammatik im Anhang A.

/*---------------------------------------------------------------------*/ /* Positive response on characteristic */ PositiveResponse

::= " - Positive response: " PositiveResponseDescription PageReferences SectionReferences

PositiveResponseDescription ::= Description /* A brief description of the positive response with regard to the quality characteristic */

Abbildung 5-11: Ableitungsregeln für die Dokumentation einer positiven Reaktion

Die Dokumentation einer positiven Reaktion beginnt mit einer fest definierten Zeichenkette, die die positive Reaktion als solche identifiziert (vgl. Abbildung 5-11). Im Anschluss an diese Zeichenkette folgt eine Beschreibung, die die positive Reaktion hinsichtlich eines Qualitätsmerkmals beschreibt. Diese Beschreibung soll kurz und prägnant den positiven Effekt hinsichtlich eines Qualitätsmerkmals und in Anlehnung an die Quelle dokumentieren. Die positive Reaktion wird durch die Angabe von Seitenreferenzen und Referenzen auf den jeweiligen Abschnitt der Pattern-Schablone nachvollziehbar (vgl. Abbildung 5-11). Die Referenzen auf den jeweiligen Abschnitt der Pattern-Schablone vereinfachen die Navigation innerhalb der Pattern-Dokumentation und ermöglichen Auswertungen bezüglich der Abschnitte, die Beschreibungen von positiven Reaktionen enthalten. Abbildung 5-12 zeigt ein Beispiel, das die Dokumentation von positiven Reaktionen verdeutlichen soll. Die Zuordnung bezieht sich auf das sog. „Layers“-Pattern (siehe [BMRS1996, S. 31 ff.]) und das Qualitätsmerkmal der Veränderlichkeit (vgl. Kapitel 5.1.3).

- Positive response: Dependencies are kept local (48) [Consequences/Benefits] - Positive response: Individual layer implementations can be replaced (49) [Consequences/Benefits] Abbildung 5-12: Beispiel für die Dokumentation von positiven Reaktionen

Zur Vereinfachung ist in Abbildung 5-12 nur das relevante Feld der Tabelle dargestellt, das zwei positive Reaktionen enthält.

160

Entwicklung eines pattern-basierten Wissensmodells

Die erste positive Reaktion wird mit einer Beschreibung dokumentiert, die aussagt, dass Abhängigkeiten lokal gehalten werden. Da durch den Einsatz des Pattern Abhängigkeiten lokal konzentriert werden, unterstützt das „Layers“-Pattern die Veränderlichkeit. Diese Beschreibung wurde von der Seite 48 des Pattern-Katalogs übernommen und befindet sich im Abschnitt „Consequences/Benefits“ der Pattern-Schablone. In diesem Beispiel werden nur eine Seitenanzahl und ein Abschnitt innerhalb der Pattern-Dokumentation erfasst. Da eine positive Reaktion auf einer oder mehreren Seiten beschrieben werden kann, definiert die Grammatik zwei Ableitungsregeln, die jeweils eine Liste von Seitenzahlen („PageReferences“) und eine Liste von Abschnitten („SectionReferences“) enthalten (vgl. Abbildung 5-11 in Verbindung mit Anhang A). Auf Basis dieser Listen können auch mehrere Seiten und Abschnitte erfasst werden. Die zweite positive Reaktion spezifiziert ebenfalls eine Beeinflussung des Qualitätsmerkmals der Veränderlichkeit, da einzelne Implementierungen einer Schicht ausgetauscht werden können. Analog zu der ersten Reaktion wird zur Unterstützung der Nachvollziehbarkeit eine Referenz auf die Seite der Pattern-Dokumentation und des relevanten Abschnitts der Pattern-Dokumentation erfasst.

5.1.7.2 Sensitivitätspunkte Ein Sensitivitätspunkt beschreibt eine Reaktion, die direkt von einer Eigenschaft eines oder mehrerer Softwareelemente und/oder deren Beziehungen untereinander abhängt. Die Ausprägungen dieser Eigenschaft determinieren, ob eine positive oder negative Reaktion eintritt. Abbildung 5-13 zeigt schematisch einen Sensitivitätspunkt.

Abbildung 5-13: Sensitivitätspunkt in Bezug auf ein Qualitätsmerkmal Quelle: in Anlehnung an [BaCK2003, S. 75]

Die Dokumentation eines Sensitivitätspunkts erfolgt in Anlehnung an die Dokumentation einer positiven Reaktion innerhalb der Felder der Tabelle. Da der Einsatz eines Pattern zu mehreren Reaktionen führen kann, können mehrere Sensitivitätspunkte vorliegen, die in Form einer Liste in einem Tabellenfeld erfasst werden. Ein Feld kann somit eine Menge von Sensi-

Entwicklung des Wissensmodells

161

tivitätspunkten enthalten (vgl. Kapitel 5.1.7). Abbildung 5-14 zeigt einen Ausschnitt aus der Grammatik im Anhang A.

/*---------------------------------------------------------------------*/ /* Sensitivity Point */ SensitivityPoint

::= " - Sensitivity point: " SensitivityPointDescription ImpactOfProperty PageReferences SectionReferences

SensitivityPointDescription ::= Description ImpactOfProperty

::= " [" ConsistentImpact | ValueBasedImpact "]"

ConsistentImpact

::= Impact

ValueBasedImpact

::= PropertyAndImpact (", " PropertyAndImpact)+

PropertyAndImpact

::= DescriptionOfProperty " (" Impact ")"

Impact

::= "+" | "-"

DescriptionOfProperty

::= Description

Abbildung 5-14: Ableitungsregeln für die Dokumentation eines Sensitivitätspunkts

Die Dokumentation eines Sensitivitätspunkts beginnt mit einer fest definierten Zeichenkette, die den Sensitivitätspunkt als solches identifiziert (vgl. Abbildung 5-14). Im Anschluss an diese Zeichenkette folgt eine Beschreibung, die den Sensitivitätspunkt hinsichtlich eines Qualitätsmerkmals erläutert. Diese Beschreibung soll kurz und prägnant insbesondere die Eigenschaft charakterisieren, die das Qualitätsmerkmal direkt beeinflusst. Der Beschreibung folgt eine Spezifikation der grundsätzlichen Auswirkung der Eigenschaft, die auf Basis der Ableitungsregel „ImpactOfProperty“ spezifiziert wird (vgl. Abbildung 5-14). Dabei werden zwei Definitionsbereiche bezüglich der Eigenschaften unterschieden: eine Eigenschaft kann auf Basis einer reellen bzw. ganzen Zahl abgebildet werden oder einen eng begrenzten Definitionsbereich besitzen. Sofern der Definitionsbereich der Eigenschaft auf einer reellen bzw. ganzen Zahl basiert, kann die Auswirkung für den gesamten Definitionsbereich einheitlich spezifiziert werden

162

Entwicklung eines pattern-basierten Wissensmodells

(vgl. Ableitungsregel „ConsistentImpact“ in Abbildung 5-14). Die grundsätzliche Auswirkung der Eigenschaft wird ausgehend von einer Erhöhung der Werte der Eigenschaft in Bezug auf das relevante Qualitätsmerkmal ausgedrückt. Eine Verbesserung des Qualitätsmerkmals bei der Erhöhung der Werte wird durch das Zeichen „+“ ausgedrückt. Verschlechtert sich ein Qualitätsmerkmal bei der Erhöhung der Werte der Eigenschaft, wird dies durch das Zeichen „-“ ausgedrückt. Die Interpretation der Zeichen erfordert die Berücksichtigung der Rangfolge eines Qualitätsmerkmals (vgl. Kapitel 3.2.3.5), die die grundlegende Richtung einer Reaktion und somit die Adjektive „besser“ bzw. „schlechter“ semantisch definiert. Besteht der Definitionbereich nicht aus einer Menge von reellen bzw. ganzen Zahlen, wird für eine Eigenschaft eine eng begrenzte Menge von gültigen Werten definiert. Es handelt sich hierbei um eine kleine Menge von Alternativen, deren Auswahl eine bestimmte Auswirkung auf ein Qualitätsmerkmal hat. Aufgrund des spezifischen Definitionsbereichs kann die Auswirkung nicht einheitlich charakterisiert werden. Auf Basis der Ableitungsregel „ValueBasedImpact“ wird deshalb jeder gültige Wert der Eigenschaft mit der entsprechenden Auswirkung auf das relevante Qualitätsmerkmal aufgelistet (vgl. Abbildung 5-14). Jedem Wert folgen ein Leerzeichen und die jeweilige Auswirkung in runden Klammern (Ableitungsregel „ValueBasedImpact“). Die Zeichen „+“ und „-“ werden analog zu den Eigenschaften mit einem Definitionsbereich auf Basis von reellen bzw. ganzen Zahlen verwendet. Auch in diesem Fall muss bei der Interpretation stets die Rangfolge des Qualitätsmerkmals beachtet werden. Um die Übersichtlichkeit nicht zu gefährden, werden die Auswirkungen einer Eigenschaft lediglich in „besser“ und „schlechter“ klassifiziert. Eine weitere Betrachtung im Sinne der mathematischen Eigenschaft der Monotonie findet nicht statt, d. h, es wird nicht zwischen monoton steigend, streng monoton steigend, monoton fallend und streng monoton fallend unterschieden. Darüber hinaus wird auf die Abbildung von oberen und unteren Grenzwerten verzichtet, da diese die Komplexität der Ableitungsregeln erhöhen und ohne den Bezug zu einer konkreten Softwarearchitektur nicht quantitativ spezifiziert werden können. Im Anschluss an die grundsätzliche Auswirkung der Eigenschaft wird der Sensitivitätspunkt – analog zur Dokumentation einer positiven Reaktion – durch die Angabe von Seitenreferenzen und Referenzen auf den jeweiligen Abschnitt der Pattern-Schablone nachvollziehbar (vgl. Abbildung 5-14). Abbildung 5-15 zeigt ein Beispiel, das die Dokumentation von Sensitivitätspunkten verdeutlichen soll. Die Zuordnung bezieht sich auf das sog. „Layers“-Pattern (siehe [BMRS1996, S. 31 ff.]) und das Qualitätsmerkmal des Zeitverhaltens (vgl. Kapitel 6.1.3). Zur Vereinfachung der Abbildung ist nur das relevante Tabellenfeld dargestellt, das einen Sensitivitätspunkt enthält.

Entwicklung des Wissensmodells

163

- Sensitivity point: Amount of data that must be transferred over several boundaries [-] (33) [Problem/Forces, Consequences/Liabilities] Abbildung 5-15: Beispiel für die Dokumentation von Sensitivitätspunkten mit einheitlicher Auswirkung

Der Sensitivitätspunkt beschreibt die Größe der Datenmenge, die über mehrere Schichten transportiert werden muss, als eine Eigenschaft, die direkten Einfluss auf das Zeitverhalten hat. Der Beschreibung des Sensitivitätspunkts folgt eine Spezifikation der grundsätzlichen Auswirkung der Eigenschaft, die in diesem Fall negativ ist. Denn steigt die Datenmenge, die über mehrere Schichten transportiert werden muss, erhöht sich die Zeit, die zum Aufruf einer Funktion benötigt wird (vgl. [BMRS1996, S. 33]). Aus der Erhöhung der Datenmenge folgt eine Erhöhung des Zeitverhaltens. Da die grundsätzliche Rangfolge des Qualitätsmerkmals des Zeitverhaltens definiert, dass eine kürzere Reaktionszeit als „besser“ einzustufen ist, ist die grundsätzliche Auswirkung der Eigenschaft als negativ klassifiziert. Eine Erhöhung der Datenmenge führt grundsätzlich zu einer Verschlechterung des Zeitverhaltens. Da der Definitionsbereich der Eigenschaft auf einer ganzen Zahl basiert, kann die Auswirkung für den gesamten Definitionsbereich einheitlich spezifiziert werden; das erfolgt im Beispiel mit der Zeichenfolge „[-]“. Die Abbildung 5-16 verdeutlicht einen Sensitivitätspunkt, dessen Eigenschaft einen eng begrenzten Definitionsbereich besitzt. Das Beispiel bezieht sich auf das sog. „Pipes and Filters“Pattern (siehe [BMRS1996, S. 31 ff.]) und das Qualitätsmerkmal der Veränderlichkeit (vgl. Kapitel 5.1.3).

- Sensitivity point: Filters as active or passive components [active filter (-), passive filter (+)] (61, 62) [Implementation] Abbildung 5-16: Beispiel für die Dokumentation von Sensitivitätspunkten mit engem Definitionsbereich

Der Sensitivitätspunkt beschreibt eine Eigenschaft, die sich auf die Entscheidung bezieht, einen sog. Filter als „aktive“ oder „passive“ Komponente zu implementieren. Ein aktiver Filter ruft einen benachbarten Filter direkt auf, wohingegen ein passiver Filter einen benachbarten Filter ausschließlich über einen sog. Pipe-Mechanismus und somit indirekt aufruft (vgl. [BMRS1996, S. 61 f.]). Die Verwendung von aktiven Filtern erhöht den Aufwand bezüglich der Veränderlichkeit, denn sollen bestehende Filter neu kombiniert und/oder wiederverwendet werden, muss aufgrund der direkten Aufrufe zwischen den benachbarten Filtern, der Quellcode der Filter angepasst werden. Passive Filter verwenden dagegen einen einheitlichen sog. Pipe-Mechanismus, der die Rekombination und/oder Wiederverwendung ohne Änderung des Quellcodes ermöglicht. Da die Eigenschaft einen eng begrenzten Definitionsbereich besitzt, kann die Auswirkung nicht einheitlich spezifiziert werden. Der Definitionsbereich basiert auf

164

Entwicklung eines pattern-basierten Wissensmodells

der Entscheidung bezüglich der Implementierung der einzelnen Filter und besteht lediglich aus den Werten „aktiver Filter“ und „passiver Filter“. Aus diesem Grund wird für beide Werte die entsprechende Auswirkung auf das Qualitätsmerkmal der Veränderlichkeit spezifiziert („[active filter (-), passive filter (+)]“).

5.1.7.3 Abwägungspunkte Ein Abwägungspunkt beschreibt eine Reaktion, die mehrere Qualitätsmerkmale beeinflusst und direkt von einer Eigenschaft eines oder mehrerer Softwareelemente und/oder deren Beziehungen untereinander abhängt. Die Ausprägungen der Eigenschaft determinieren, ob eine positive oder negative Reaktion eintritt. Die unterschiedlichen Qualitätsmerkmale können unterschiedlich beeinflusst werden. Abbildung 5-17 verdeutlicht schematisch die Auswirkungen eines Abwägungspunkts.

+/ Ausmaß der Reaktion Eigenschaft (=Abwägungspunkt)

Stimulus Quelle des Stimulus

Artefakt Ausmaß der Reaktion

Umgebung

+/ Abbildung 5-17: Abwägungspunkt in Bezug auf mehrere Qualitätsmerkmale Quelle: in Anlehnung an [BaCK2003, S. 75]

Die Dokumentation eines Abwägungsspunkts innerhalb der Felder der Tabelle erfolgt im Wesentlichen entsprechend der Dokumentation eines Sensitivitätspunkts. Da der Einsatz eines Pattern zu mehreren Reaktionen führen kann, können mehrere Abwägungspunkte vorliegen, die in Form einer Liste in einem Tabellenfeld erfasst werden. Ein Feld kann somit – analog zu den anderen Kategorien von Auswirkungen – eine Menge von Abwägungspunkten enthalten (vgl. Kapitel 5.1.7). Ein Abwägungspunkt beeinflusst mehr als ein Qualitätsmerkmal und wird deshalb bei jedem beeinflussten Qualitätsmerkmal aufgeführt. Abbildung 5-18 zeigt einen Ausschnitt aus der Grammatik im Anhang A.

Entwicklung des Wissensmodells

165

/*---------------------------------------------------------------------*/ /* Tradeoff Point */ TradeoffPoint

::= " - Tradeoff point: " TradeoffPointDescription ImpactOfProperty PageReferences SectionReferences OtherAffectedCharacteristicsReference

TradeoffPointDescription

::= Description

ImpactOfProperty

::= " [" ConsistentImpact | ValueBasedImpact "]"

ConsistentImpact

::= Impact

ValueBasedImpact

::= PropertyAndImpact (", " PropertyAndImpact)+

PropertyAndImpact

::= DescriptionOfProperty " (" Impact ")"

DescriptionOfProperty

::= Description

Impact

::= "+" | "-"

OtherAffectedCharacteristicsReference ::= " (" Characteristic (", " Characteristic)* ")" Characteristic

::= FirstLevelCharacteristic | SecondLevelCharacteristic | ThirdLevelCharacteristic

Abbildung 5-18: Ableitungsregeln für die Dokumentation eines Abwägungspunkts

Die Dokumentation eines Abwägungspunkts beginnt – analog zu jeder Kategorie von Auswirkungen – mit einer fest definierten Zeichenkette, die den Abwägungspunkt als solchen identifiziert (vgl. Abbildung 5-18). Der Zeichenkette folgt eine Beschreibung, die den Abwägungspunkt hinsichtlich der beeinflussten Qualitätsmerkmale beschreibt. Diese Beschreibung soll kurz und prägnant die Eigenschaft erläutern, die die Qualitätsmerkmale beeinflusst. Der Beschreibung folgt eine Spezifikation der grundsätzlichen Auswirkung der Eigenschaft, die auf Basis der Ableitungsregel „ImpactOfProperty“ spezifiziert wird (vgl. Abbildung 5-18). Diese Ableitungsregel wird analog zu einem Sensitivitätspunkt verwendet, d. h., die grundsätzliche Auswirkung der Eigenschaft wird ausgehend von einer Erhöhung der Werte der Eigenschaft in Bezug auf das relevante Qualitätsmerkmal ausgedrückt und die Syntax der Spezifikation der Auswirkung wird durch den Definitionsbereich der Eigenschaft determiniert (vgl. Kapitel 5.1.7.2).

166

Entwicklung eines pattern-basierten Wissensmodells

Im Gegensatz zu den Sensitivitätspunkten werden auf Basis der Ableitungsregel „OtherAffectedCharacteristicsReference“ alle weiteren Qualitätsmerkmale aufgelistet, die die Eigenschaft beeinflusst, und der Abwägungspunkt bei jedem beeinflussten Qualitätsmerkmal dokumentiert (vgl. Abbildung 5-18). Die Auswirkung der Eigenschaft kann bei unterschiedlichen Qualitätsmerkmalen auch unterschiedlich sein. Die Verknüpfung der Qualitätsmerkmale kann auf allen drei Ebenen des Qualitätsmodells erfolgen (vgl. Kapitel 5.1.3). Sie sollte allerdings zur Gewährleistung der Nachvollziehbarkeit möglichst auf der niedrigsten Ebene erfolgen. Die mehrfache Aufführung eines Abwägungspunkts und die Dokumentation der anderen beeinflussten Qualitätsmerkmale innerhalb eines Abwägungspunkts fördern die Übersichtlichkeit und Nachvollziehbarkeit des Wissensmodells. Abbildung 5-19 verdeutlicht beispielhaft die Dokumentation eines Abwägungspunkts. Das Beispiel bezieht sich auf das sog. „Pipes and Filters“-Pattern (vgl. [BMRS1996, S. 53 ff.]); es werden der Einfachheit halber nur die Qualitätsmerkmale des Zeitverhaltens und der Analysierbarkeit betrachtet.

- Tradeoff point: Sharing a large amount of global data [-] (68) [Consequences/Liabilities] (Resource utilization, Analyzability, Changeability, Stability, Testability) Abbildung 5-19: Beispiel für die Dokumentation von Abwägungspunkten (Qualitätsmerkmal des Zeitverhaltens)

Der Abwägungspunkt beschreibt den Umfang der globalen Daten, die zwischen den Filtern einer sog. Filterkette ausgetauscht werden. Das sind Daten, die neben den eigentlichen Eingabe- und Ausgabedaten zwischen den Filtern übertragen werden und z. B. Zustandsinformationen übermitteln (vgl. [BMRS1996, S. 68]). Der Umfang dieser Daten wirkt sich negativ auf das Zeitverhalten aus, denn durch die Verarbeitung zusätzlicher Eingabedaten erhöht sich die Verarbeitungsdauer, und die Rangfolge des Merkmals definiert, dass eine kürzere Dauer „besser“ ist. Darüber hinaus beeinflusst der Umfang der globalen Daten die Qualitätsmerkmale Verbrauchsverhalten, Analysierbarkeit, Veränderlichkeit, Stabilität und Testbarkeit (vgl. Kapitel 5.1.3). Im Folgenden wird der Einfachheit halber nur die Analysierbarkeit diskutiert und beispielhaft die Dokumentation des Abwägungspunkts innerhalb der Spalte der Analysierbarkeit verdeutlicht (siehe Abbildung 5-20).

Entwicklung des Wissensmodells

167

- Tradeoff point: Sharing a large amount of global data [-] (68) [Consequences/Liabilities] (Time behaviour, Resource utilization, Changeability, Stability, Testability) Abbildung 5-20: Beispiel für die Dokumentation von Abwägungspunkten (Qualitätsmerkmal der Analysierbarkeit)

Wie die Abbildung 5-20 zeigt, hat der Umfang der globalen Daten eine negative Auswirkung auf die Analysierbarkeit: Je mehr globale Daten zwischen den Filtern einer Filterkette ausgetauscht werden, desto komplexer wird der Quellcode der Filter, da die globalen Daten innerhalb eines Filters definiert, eingelesen und abgefragt werden müssen. Durch die steigende Komplexität der Filter erhöht sich deren Analysierbarkeit, da die globalen Daten z. B. bei der Suche nach einem Fehler berücksichtigt werden müssen. Die Auswirkung der Eigenschaft ist in beiden Beispielen negativ, wobei die Auswirkung für jedes beeinflusste Qualitätsmerkmal auch unterschiedlich sein kann. Die Liste der beeinflussten Qualitätsmerkmale reflektiert die anderen Qualitätsmerkmale, auf die die Eigenschaft eine entsprechende Auswirkung hat. In den vorgestellten Beispielen sind die Listen unterschiedlich, da sie sich auf verschiedene Qualitätsmerkmale beziehen.

5.1.7.4 Negative Reaktionen Eine negative Reaktion beschreibt eine direkte Auswirkung eines Qualitätsmerkmals. Negativ in Bezug auf die Reaktion bedeutet, dass bei einer Messung auf Basis von einer oder mehrerer Metriken der Einsatz des Pattern grundsätzlich zu schlechteren Werten auf der jeweiligen Skala führt. Abbildung 5-21 verdeutlicht eine negative Reaktion.

Stimulus Quelle des Stimulus

Artefakt

Reaktion

Ausmaß der Reaktion

Umgebung

Abbildung 5-21: Negative Reaktion in Bezug auf ein Qualitätsmerkmal Quelle: in Anlehnung an [BaCK2003, S. 75]

Die Dokumentation einer negativen Reaktion erfolgt im Wesentlichen analog zu einer positiven Reaktion (vgl. Kapitel 5.1.7.1). Da der Einsatz eines Pattern zu mehreren Reaktionen führen kann, können mehrere negative Reaktionen in einem Tabellenfeld dokumentiert werden (vgl. Kapitel 5.1.7). Abbildung 5-22 zeigt zur Verdeutlichung einen Ausschnitt aus der Grammatik im Anhang A.

168

Entwicklung eines pattern-basierten Wissensmodells

/*---------------------------------------------------------------------*/ /* Negative response on characteristic */ NegativeResponse

::= " - Negative response: " NegativeResponseDescription PageReferences SectionReferences

NegativeResponseDescription ::= Description

Abbildung 5-22: Ableitungsregeln für die Dokumentation einer negativen Reaktion

Die Dokumentation einer negativen Reaktion beginnt mit einer fest definierten Zeichenkette, die die negative Reaktion als solche identifiziert (vgl. Abbildung 5-22). Im Anschluss an diese Zeichenkette folgt eine Beschreibung, die die negative Reaktion hinsichtlich eines Qualitätsmerkmals charakterisiert. Diese Beschreibung soll kurz und prägnant den negativen Effekt, hinsichtlich eines Qualitätsmerkmals und in Anlehnung an die Quelle, dokumentieren. Analog zu einer positiven Reaktion wird die negative Reaktion durch die Angabe von Seitenreferenzen und Referenzen auf den jeweiligen Abschnitt der Pattern-Schablone nachvollziehbar (vgl. Abbildung 5-22). Abbildung 5-23 zeigt ein Beispiel, das die Dokumentation von negativen Reaktionen verdeutlichen soll. Die Zuordnung bezieht sich auf das sog. „Layers“-Pattern (siehe [BMRS1996, S. 31 ff.]) und das Qualitätsmerkmal des Zeitverhaltens (vgl. Kapitel 5.1.3).

- Negative response: Lower efficiency (50) [Consequences/Liabilities] Abbildung 5-23: Beispiel für die Dokumentation von negativen Reaktionen

Die negative Reaktion beschreibt kurz und prägnant, dass der Einsatz des „Layers“-Pattern einen negativen Einfluss auf das Zeitverhalten hat. Diese Beschreibung wurde von der Seite 50 des Pattern-Katalogs extrahiert und befindet sich im Abschnitt „Consequences/Liabilities“ der Pattern-Schablone.

5.1.7.5 Interpretation der Reaktionen Ein Feld der Tabelle kann zu jeder Kategorie eine oder mehrere Reaktionen enthalten, da der Einsatz eines Pattern auf der Ebene der Softwarearchitektur i. d. R. zu mehreren Reaktionen führt (vgl. Kapitel 5.1.7). Jedes Tabellenfeld kann jeweils eine Liste von positiven Reaktionen, Sensitivitätspunkten, Abwägungspunkten und negativen Reaktionen enthalten, wobei das grundlegende Ausmaß der jeweiligen Reaktion aufgrund des generischen Lösungsansatzes eines Pattern und des fehlenden Bezugs zu einer konkreten Softwarearchitektur ausschließlich qualitativ dokumentiert wird. Die Interpretation eines Tabellenfelds innerhalb des

Entwicklung des Wissensmodells

169

Entwurfs bzw. der Bewertung einer Softwarearchitektur erfordert die Betrachtung einer ggf. großen Menge von Reaktionen, die zudem die grundlegenden Reaktionen lediglich qualitativ beschreiben. Daher kann die Zuordnung zwischen den Pattern und Qualitätsmerkmalen nicht unmittelbar und nicht eindeutig erfolgen. Die Analyse der Zuordungen zwischen Pattern und Qualitätsmerkmalen muss auf Basis der gesamten Menge der Reaktionen erfolgen, die innerhalb eines Tabellenfelds dokumentiert sind. Neben der Beschreibung der Reaktion muss stets der Kontext beachtet werden, der durch das stimulierte Artefakt einen Bezug zur Interpretation des Qualitätsmerkmals herstellt (vgl. Kapitel 5.1.5). Ohne diesen Bezug kann keine Reaktion interpretiert werden. Die verschiedenen Kategorien, die das grundlegende Ausmaß einer Reaktion beschreiben, benötigen unterschiedlichen Aufwand bezüglich der Analyse der Zuordnungen. Die positiven und negativen Reaktionen charakterisieren einen direkten Einfluss auf ein Qualitätsmerkmal. Sie benötigen lediglich eine Betrachtung des Kontexts, um die Zuordnung eines Pattern zu einem Qualitätsmerkmal zu beurteilen. Ein Sensitivitätspunkt dagegen erfordert eine weiterführende Betrachtung der Eigenschaft, die determiniert, ob eine positive oder negative Reaktion eintritt. Der Definitionsbereich der Eigenschaft bestimmt die Syntax (vgl. Kapitel 5.1.7.2), die das grundlegende Ausmaß der Reaktion spezifiziert. Auf dieser Basis wird die Zuordnung beurteilt. Die Abwägungspunkte erfordern den größten Analyseaufwand, denn neben dem Kontext und der einwirkenden Eigenschaft, müssen alle weiteren beeinflussten Qualitätsmerkmale und deren Beeinflussung durch die Eigenschaft berücksichtigt werden. Wenn innerhalb des Entwurfs bzw. der Bewertung die Eigenschaften aller Sensitivitäts- und Abwägungspunkte und deren Einfluss auf das grundlegende Ausmaß der Reaktion analysiert worden sind, besteht die Menge nur aus (direkten) positiven und negativen Reaktionen (siehe Kapitel 5.4). Aufgrund der ausschließlich qualitativen Betrachtung ist aber keine „Aufrechnung“ von positiven und negativen Reaktionen möglich. Die Reaktionen müssen einzeln betrachtet werden, um das Verständnis eines Pattern in Bezug auf die Beeinflussung der Qualitätsmerkmale zu fördern. Im Kontext eines Entwurfs bzw. einer Bewertung können bei Bedarf die qualitativ spezifizierten Reaktionen gezielt durch quantitative Messungen verfeinert bzw. validiert werden (siehe Kapitel 5.4). Die Interpretation der in einem Tabellenfeld dokumentierten Reaktionen wird im Folgenden an einem Beispiel verdeutlicht. Die Zuordnung bezieht sich auf das sog. „Layers“-Pattern (siehe [BMRS1996, S. 31 ff.]) und das Qualitätsmerkmal der Veränderlichkeit (vgl. Kapitel 5.1.3). Der folgende Ausschnitt der Tabelle des Wissensmodells zeigt zunächst den Kontext und stimulierten Artefakt, die den Bezug der Zuordnung herstellen (siehe Tabelle 5-5).

170

Entwicklung eines pattern-basierten Wissensmodells

Context

Stimulated Artifact

A large system that requires decompostion (32) [Context]

Tasks or functions (32) [Problem]

Tabelle 5-5: Beispiel für die Interpretation der Reaktionen (Kontext, stimulierter Artefakt)

Der Bezug des „Layers“-Pattern wird zunächst durch den Kontext des Pattern spezifiziert. Das Pattern kann im Kontext von großen Systemen eingesetzt werden, die eine Dekomposition benötigen. Der Bezug wird durch das stimulierte Artefakt verfeinert, das in diesem Beispiel Aufgaben oder Funktionen umfasst. Die Zuordnungen des Pattern zu Qualitätsmerkmalen beziehen sich somit auf die Aufgaben oder Funktionen eines großen Systems, das eine Komposition benötigt. Der folgende Tabellenausschnitt zeigt die Menge von Reaktionen, die bezüglich des Qualitätsmerkmals der Veränderlichkeit dokumentiert sind (siehe Abbildung 5-24).

Changeability - Positive response: Similar responsibilities should be grouped to help understandability and maintainability (33) [Problem/Forces] - Positive response: Reuse of layers (48) [Consequences/Benefits] - Positive response: Dependencies are kept local (48) [Consequences/Benefits] - Positive response: Individual layer implementations can be replaced (49) [Consequences/Benefits] - Tradeoff point: Number of layers [+] (39, 50) [Implementation, Consequences/Liabilities] (Time behaviour, Resource utilization, Analyzability, Stability, Testability) - Tradeoff point: Complexity of error-handling strategy [-] (43) [Implementation] (Time behaviour, Resource utilization, Analyzability, Stability, Testability) - Tradeoff point: Rigor of relationship between the layers [+] (45) [Variants] (Time behaviour, Resource utilization, Analyzability, Stability, Testability) Abbildung 5-24: Beispiel für die Interpretation der Reaktionen (Qualitätsmerkmal der Veränderlichkeit)

Die erste positive Reaktion charakterisiert, dass durch Gruppierung von ähnlichen Verantwortlichkeiten die Verständlichkeit und Wartbarkeit unterstützt wird. Diese Gruppierung bezieht sich auf das stimulierte Artefakt, d. h. die Aufgaben bzw. Funktionen eines großen Systems. Eine Besonderheit ist die Verwendung von pattern-katalog-spezifischen Qualitätsmerkmalen innerhalb der Beschreibung der positiven Reaktion. Diese werden innerhalb der Vorgehensweise in das einheitliche Qualitätsmodell transformiert (siehe Kapitel 5.2). Die Gruppierung der Aufgaben bzw. Funktionen eines großen Systems führen grundsätzlich zu einer positiven Reaktion hinsichtlich der Veränderlichkeit. Das Pattern unterstützt somit die Veränderlichkeit in Bezug auf die Aufgaben oder Funktionen eines großen Systems.

Entwicklung des Wissensmodells

171

Die zweite positive Reaktion spezifiziert die Möglichkeit Schichten wiederzuverwenden, wodurch die Veränderlichkeit in Bezug auf die Aufgaben oder Funktionen eines großen Systems grundsätzlich positiv beeinflusst wird. Die dritte positive Reaktion wird mit einer Beschreibung dokumentiert, die aussagt, dass Abhängigkeiten lokal gehalten werden. Diese Abhängigkeiten beziehen sich auf die Aufgaben bzw. Funktionen eines großen Systems, d. h., das Pattern unterstützt grundsätzlich die Veränderlichkeit in Bezug auf die Aufgaben oder Funktionen eines großen Systems. Die vierte positive Reaktion beschreibt die Möglichkeit, einzelne Implementierungen einer Schicht auszutauschen. Aufgrund dieser Möglichkeit des Austauschs wird – analog zu der zweiten positiven Reaktion – die Veränderlichkeit in Bezug auf die Aufgaben oder Funktionen eines großen Systems grundsätzlich positiv beeinflusst. Die fünfte Reaktion stellt einen Abwägungspunkt dar, der sich auf die Eigenschaft der Anzahl der Schichten bezieht. Unter der Berücksichtigung des Kontexts gibt die Eigenschaft die Anzahl der logischen Abstraktionsebenen wieder, die für eine Dekomposition der Aufgaben bzw. Funktionen eines großen Systems verwendet werden können. Das Zeichen „+“ besagt, dass mit einer steigenden Anzahl von Schichten die Reaktionen „besser“ werden, d. h., die Veränderlichkeit steigt. Allerdings kann die Veränderlichkeit durch Hinzufügen weiterer Schichten nicht unendlich gesteigert werden. Auf die Abbildung von oberen und unteren Grenzwerten wird allerdings zur Erhaltung der Übersichtlichkeit bewusst verzichtet (vgl. Kapitel 5.1.7.2). Neben der Veränderlichkeit beeinflusst die Anzahl der Schichten weitere Qualitätsmerkmale (Zeitverhalten, Verbrauchsverhalten, Analysierbarkeit, Stabilität und Prüfbarkeit). Der zweite Abwägungspunkt bezieht sich auf die Komplexität der Fehlerbehandlung zwischen den einzelnen Schichten. Durch die Dekomposition der Aufgaben bzw. Funktionen eines großen Systems und deren Implementierung innerhalb unterschiedlicher Schichten, wird die Übermittlung von Fehlern innerhalb und insbesondere zwischen den Schichten notwendig. Je mehr Schichten zur Dekomposition verwendet werden, desto komplexer ist die Fehlerbehandlung und desto „schlechter“ ist die Veränderlichkeit. Die grundsätzliche Auswirkung ist deshalb negativ. Die Komplexität der Fehlerbehandlung beeinflusst darüber hinaus weitere Qualitätsmerkmale. Der dritte und letzte Abwägungspunkt beschreibt die Strenge, mit der die Zugriffsregeln zwischen den Schichten definiert werden. Je strenger diese Zugriffsregeln sind, desto „besser“ ist die Veränderlichkeit. Die grundsätzliche Auswirkung ist daher positiv und beeinflusst – analog zu den anderen Abwägungspunkten – weitere Qualitätsmerkmale. Das Beispiel zeigt, dass die Zuordnung zwischen dem „Layers“-Pattern und dem Qualitätsmerkmal der Veränderlichkeit nicht direkt und nicht eindeutig erfolgen kann. Die verschiedenen Reaktionen lassen aber eine zusammenfassende Interpretation der Zuordnung zu: Das

172

Entwicklung eines pattern-basierten Wissensmodells

Pattern bezieht sich auf die Dekomposition von Aufgaben bzw. Funktionen im Kontext eines großen Systems. Die Gruppierung der Aufgaben bzw. Funktionen und die Konzentration der Abhängigkeiten zwischen Aufgaben bzw. Funktionen wirken sich grundsätzlich positiv auf die Veränderlichkeit aus. Das Pattern ermöglicht die Wiederverwendung und Austauschbarkeit einzelner Schichten, was sich positiv auf die Veränderlichkeit auswirkt. Diese vier Reaktionen sind stets grundsätzlich positiv, d. h., es existiert keine einzelne Eigenschaft, die determiniert, ob die Reaktionen positiv oder negativ sind. Die Abwägungspunkte erfordern im Kontext des Entwurfs- bzw. Bewertungsprozesses erhöhte Aufmerksamkeit. Sie beschreiben jeweils eine Eigenschaft, die determiniert, ob eine positive oder negative Reaktion eintritt. Die Anzahl der Schichten, die Komplexität der Fehlerbehandlung und die Strenge der Zugriffsregeln müssen daher detailliert analysiert werden, um eine zusammenfassende Aussage bezüglich der Zuordnung machen zu können. Die Basis für diese Untersuchung bilden die grundsätzlichen Auswirkungen der Eigenschaften, die durch die Zeichen „+“ und „-“ innerhalb des Tabellenfelds spezifiziert werden. Darüber hinaus erfordert die Interpretation der Zuordnung im Kontext des Entwurfs bzw. der Bewertung eine weiterführende Analyse anderer Zuordnungen, denn die Eigenschaften beeinflussen weitere Qualitätsmerkmale (Zeitverhalten, Verbrauchsverhalten, Analysierbarkeit, Stabilität und Prüfbarkeit).

5.1.8 Klassifikation der Tabellenfelder Die Felder der Tabelle können zu jeder Kategorie eine oder mehrere Reaktionen enthalten (vgl. Kapitel 5.1.7). Um die Herleitung einer Lösung, die auf Basis der Navigation in den Zeilen und Spalten der Tabelle erfolgt (vgl. Kapitel 5.1.2), und die Interpretation der Reaktionen (vgl. Kapitel 5.1.7.5) zu unterstützen, werden die Tabellenfelder klassifiziert, indem der Hintergrund eines Felds mit unterschiedlichen Farben dargestellt wird. Die Grundlage für diese Klassifikation bilden die unterschiedlichen Kategorien, die das Ausmaß einer Reaktion spezifizieren (vgl. Kapitel 5.1.7). Die farbliche Klassifikation beschreibt unterschiedliche Kombinationen der Mengen von Reaktionen und unterstützt dadurch die Übersichtlichkeit des Wissensmodells. Sie entfällt, wenn ein Tabellenfeld keine Reaktionen enthält (siehe Tabelle 5-6). Wenn ein Feld ausschließlich positive Reaktionen enthält, wird der Hintergrund des Felds grün dargestellt (siehe Tabelle 5-6). Diese Farbe verdeutlicht, dass lediglich direkte positive Auswirkungen auf ein Qualitätsmerkmal in dem Feld dokumentiert sind. Sie vermittelt eine positive Tendenz bezüglich der gesamten Menge der Reaktionen. Die Interpretation der Reak-

Entwicklung des Wissensmodells

173

tionen erfordert lediglich eine Betrachtung des Kontexts, um die Zuordnung des Pattern zu dem Qualitätsmerkmal zu beurteilen (vgl. Kapitel 5.1.7.5).

Farbe des Hintergrunds

Beschreibung

keine

Das Feld enthält keine Reaktionen.

grün

Das Feld enthält ausschließlich positive Reaktionen.

gelb

Das Feld enthält mindestens einen Sensitivitätspunkt, aber keinen Abwägungspunkt und keine negative Reaktion.

rot-braun

Das Feld enthält mindestens einen Abwägungspunkt, aber keine negative Reaktion.

rot

Das Feld enthält mindestens eine negative Reaktion. Tabelle 5-6: Farbliche Klassifikation der Tabellenfelder

Enthält ein Feld mindestens einen Sensitivitätspunkt, aber keinen Abwägungspunkt und keine negative Reaktion, wird der Hintergrund gelb dargestellt (vgl. Tabelle 5-6). Die gelbe Hintergrundfarbe verdeutlicht eine grundsätzlich positive Tendenz der Menge der Reaktionen, d. h., neben einer optionalen Menge von positiven Reaktionen, existiert mindestens ein Sensitivitätspunkt dessen Eigenschaft detailliert betrachtet werden muss. Grundsätzlich ist die Tendenz allerdings positiv, denn es existieren kein Abwägungspunkt und keine negative Reaktion. Die Existenz von mindestens einem Abwägungspunkt, aber keiner negativen Reaktion, wird durch einen rot-braunen Hintergrund verdeutlicht (vgl. Tabelle 5-6). Diese Farbe vermittelt insbesondere die Beeinflussung und Abhängigkeit von weiteren Qualitätsmerkmalen. Es können zwar positive Reaktionen und Sensitivitätspunkte existieren, aber die Existenz von mindestens einem Abwägungspunkt erfordert – neben der Betrachtung des Kontexts und der Eigenschaft – eine weiterführende Analyse der anderen beeinflussten Qualitätsmerkmale. Eine Tendenz bezüglich der Menge von Reaktionen kann ohne diese Betrachtungen nicht definiert werden. Ein roter Hintergrund schließlich klassifiziert ein Feld, das mindestens eine negative Reaktion enthält (vgl. Tabelle 5-6). Das Feld kann positive Reaktionen, Sensitivitätspunkte und auch Abwägungspunkte enthalten. Aus einer negativen Reaktion kann nicht unmittelbar auf eine negative Tendenz der Menge der Reaktionen geschlossen werden. Vielmehr verdeutlicht die rote Hintergrundfarbe, dass aufgrund der direkten negativen Auswirkung, die Menge der Reaktionen detailliert untersucht werden muss. Insbesondere die Menge der negativen Auswirkungen muss hinsichtlich ihrer Bedeutung im Gesamtkontext der Softwarearchitektur berücksichtigt werden.

174

5.2

Entwicklung eines pattern-basierten Wissensmodells

Entwicklung der Vorgehensweise

Nachdem im vorherigen Kapitel 5.1 die Entwicklung eines Wissensmodells dargestellt wurde, wird in diesem Kapitel eine Vorgehensweise entwickelt, mit der eine Wissensbasis aufgebaut werden kann. Die Vorgehensweise basiert auf einer Menge von Grundlagen und Annahmen, die zunächst in Kapitel 5.2.1 diskutiert werden. Das Kapitel 5.2.2 beschreibt im Anschluss den Prozess, mit dem existierende Pattern-Dokumentationen untersucht und die Informationen extrahiert werden, die für einen pattern-basierten Entwurf bzw. eine szenario-basierte Bewertung relevant sind.

5.2.1 Zieldefinition und Annahmen Die Vorgehensweise basiert auf der Annahme, dass das zugrunde liegende Wissensmodell im Hinblick auf die Menge der Pattern erweiterbar ist, um beliebige Architektur-Pattern erfassen zu können. Diese Annahme entspricht einem der Entwicklungsziele des Wissensmodells und wird als eine zutreffende Annahme betrachtet (vgl. Kapitel 5.1.1). Die Vorgehensweise soll bezüglich der Menge der Pattern erweiterbar sein und verschiedene Pattern-Kataloge berücksichtigen. Es wird davon ausgegangen, dass die relevanten Pattern-Kataloge „stabil“ sind, d. h., der Katalog und die Pattern-Dokumentationen befinden sich in einem finalen Zustand und Änderungen bzw. Erweiterungen sind kurz- bis mittelfristig nicht zu erwarten. Die Änderung bzw. Erweiterung existierender Pattern-Kataloge und -Dokumentationen würde anderenfalls häufige Aktualisierungen der Wissensbasis erfordern, da diese in Bezug auf die Pattern-Kataloge redundante Informationen enthält (vgl. Kapitel 5.1.1). Bei einer Erweiterung eines PatternKatalogs um neue Pattern sind lediglich diese Pattern zu erfassen (siehe Kapitel 5.2.2.2.3). Änderungen an existierenden Pattern-Dokumentationen erfordern die Identifikation der für das Wissensmodell relevanten Modifikationen. Da Pattern aber existierende erprobte Erfahrungen dokumentieren, die über mehrere Jahre hinweg erworben wurden (vgl. Kapitel 4.1), ist nicht davon auszugehen, dass sich die Pattern-Kataloge häufig ändern. Die Änderungshäufigkeit der folgenden Beispiele bestätigen diese Annahme: Die sog. Design Pattern von Gamma, Helm, Johnson und Vlissides (siehe [GHJV1995]) wurden 1995 publiziert. Seitdem existiert keine Überarbeitung in Form einer neuen Auflage. Die von Buschmann, Meunier, Rohnert et al. dokumentierten Architektur-Pattern wurden 1996 veröffentlicht (siehe [BMRS1996]). Eine Aktualisierung dieses Pattern-Katalogs hat bisher nicht stattgefunden. Allerdings ist dieser Katalog Teil einer Serie, in der unterschiedliche Autoren, Pattern zu unterschiedlichen Bereichen dokumentiert haben (siehe [SSRB2000; KiJa2004]). Die Menge der Pattern ist erweitert, die bestehenden Pattern sind aber nicht verändert worden.

Entwicklung der Vorgehensweise

175

Die Vorgehensweise wird lediglich heuristisch beschrieben, da die Extraktion der relevanten Informationen auf Basis von determinierten Algorithmen aufgrund der textuellen Beschreibung der Pattern zu aufwändig ist. Zudem kann nicht davon ausgegangen werden, dass alle Pattern-Kataloge in elektronischer Form verfügbar sind. Die Verwendung von nicht-determinierten Extraktionsalgorithmen führt aber dazu, dass unterschiedliche Instanzen des Prozesses auf Basis der gleichen Pattern-Menge unterschiedliche Ergebnisse produzieren können. Diese unterschiedlichen Wissensbasen lassen sich durch einen Abgleich und eine Verifikation der Ergebnisse mit geringem Aufwand angleichen. In Kapitel 5.3 wird die Validierung des Wissensmodells und der Vorgehensweise auf Basis ausgewählter Pattern-Kataloge erläutert. Die Wissensbasis, die durch diese Validierung entsteht, ist ein Ausgangspunkt für einen derartigen Abgleich mit anderen Prozess-Instanzen. Der im Folgenden beschriebene Prozess kann nur die Informationen extrahieren, die Bestandteil der Pattern-Dokumentation sind, d. h., inbesondere eigene Erfahrungen oder tiefergehende Interpretationen der Beschreibung sind nicht im Fokus des Prozesses und werden auch nicht in die Wissensbasis aufgenommen. Hieraus ergibt sich die Problematik der Nichtvollständigkeit der existierenden Pattern-Dokumentationen, die in Kapitel 6.2 aufgegriffen wird.

5.2.2 Prozess zum Aufbau einer Wissensbasis Die grundlegende Logik und wesentlichen Aktivitäten des Prozesses werden in Kapitel 5.2.2.1 beschrieben. In Kapitel 5.2.2.2 wird zunächst kurz eine Struktur für die Beschreibung der Aktivitäten des Prozesses vorgestellt. Sie soll gewährleisten, dass die Beschreibung der Aktivitäten einheitlich erfolgt. Im Anschluss werden die Aktivitäten der Vorgehensweise erläutert, wobei die Erfassung eines Architektur-Pattern (siehe Kapitel 5.2.2.2.3) den Kern der Vorgehensweise bildet.

5.2.2.1 Prozesslogik und Aktivitäten im Überblick Der Prozess zum Aufbau einer Wissensbasis besteht aus drei Aktivitäten und zwei Schleifen. Abbildung 5-25 stellt den Prozess auf Basis eines Aktivitätendiagramms der UML dar (siehe [OMG2005a, S. 447 ff.]). Die erste Aktivität beinhaltet eine Selektion der relevanten Pattern-Kataloge, da nicht alle Kataloge für alle Anwendungsfälle des Entwurfs bzw. der Bewertung relevant sind. Das Ergebnis der Aktivität ist eine Liste der zu analysierenden Kataloge.

176

Entwicklung eines pattern-basierten Wissensmodells

Die zweite Aktivität bezieht sich auf einen Katalog dieser Liste und beinhaltet die Selektion aller Architektur-Pattern dieses Katalogs. Das Ergebnis der Aktivität ist eine Liste der zu untersuchenden Architektur-Pattern.

Selektion der Pattern-Kataloge

Selektion der ArchitekturPattern eines Katalogs

Erfassung eines Architektur-Pattern [weiteres Pattern vorhanden] [alle ArchitekturPattern des Katalogs erfasst]

[weiterer Katalog vorhanden]

[alle ausgewählten Kataloge untersucht]

Abbildung 5-25: Prozesslogik und Aktivitäten zum Aufbau einer Wissensbasis

Die Untersuchung bzw. Erfassung eines Pattern erfolgt innerhalb der dritten Aktivität, die solange ausgeführt wird bis alle Architektur-Pattern eines Katalogs verarbeitet worden sind. Im Anschluss folgt eine weitere Schleife, die solange ausgeführt wird, bis alle Kataloge, die innerhalb der ersten Aktivitäten selektiert worden sind, verarbeitet sind.

5.2.2.2 Beschreibung der Aktivitäten Die Beschreibung der Aktivitäten erfolgt grundsätzlich in textueller Form. Für jede Aktivität werden die wesentlichen Eingaben, Hilfsmittel und Ergebnisse sowie eine Kurzbeschreibung der Aktitivität in einer einheitlichen Tabelle zusammengefasst. Insbesondere die Eingaben, Hilfsmittel und Ergebnisse werden in der Tabelle ebenfalls in textueller Form dokumentiert. Die Hilfsmittel werden – sofern möglich – direkt innerhalb der Beschreibung einer Aktivität entwickelt bzw. dargestellt.

Entwicklung der Vorgehensweise

177

5.2.2.2.1 Selektion der Pattern-Kataloge Die erste Aktivität beinhaltet eine Selektion der relevanten Pattern-Kataloge, denn nicht alle Kataloge sind für alle Anwendungsfälle des Entwurfs bzw. der Bewertung relevant. Ein Pattern-Katalog beschreibt eine Menge von Pattern, die sich i. d. R. nach bestimmten Kriterien klassifizieren lassen (vgl. Kapitel 4.2.2). Da keine einheitliche Klassifikation der Pattern-Kataloge existiert, werden im Folgenden einige identifizierte Kriterien beispielhaft vorgestellt. Die Menge dieser Kriterien erhebt keinen Anspruch auf Vollständigkeit und bietet lediglich eine Orientierung bei der Auswahl der Pattern-Kataloge. Ein grundlegendes Kriterium zur Klassifikation von Pattern ist die Abstraktionsebene, auf die sich das Pattern bezieht (vgl. Kapitel 4.1.3). Es wird zwischen der Architekturebene, der Entwurfsebene und der Ebene des Quellcodes differenziert. Dementsprechend besteht die Klassifikation aus Architektur-Pattern, Entwurfs-Pattern und Idiomen (vgl. [BMRS1996, S. 363]). Ein Katalog kann mehrere Typen von Pattern enthalten, so dass diese Klassifikation nicht direkt auf die Pattern-Kataloge angewendet werden kann. Aus diesem Grund werden in der zweiten Aktivität die Architektur-Pattern eines Katalogs identifiziert. Die Pattern können nach den Problembereichen, zu denen sie Lösungsansätze dokumentieren, gruppiert sein. Diese Problembereiche können unabhängig voneinander (vgl. [BMRS1996]) oder Teil einer Hierarchie von mehreren Problembereichen sein, wobei sich der Pattern-Katalog auf den Problembereich bezieht, der durch die Wurzel der Hierarchie repräsentiert wird (vgl. [SSRB2000; KiJa2004]). Dementsprechend kann sich ein Pattern-Katalog auf einen oder mehrere Problembereiche beziehen. Weiterhin können sich Pattern ausschließlich auf bestimmte Entwicklungsplattformen beziehen und erprobte Erfahrungen unter Berücksichtigung der plattform-spezifischen Details dokumentieren (vgl. [AlCM2003; TMQH2003]). Die Entwicklungsplattform ist daher eines der wesentlichen Auswahlkritieren für einen Pattern-Katalog. Es ist zu beachten, dass die Pattern der plattform-spezifischen Kataloge häufig auf anderen grundlegenden Pattern basieren und zahlreiche Gemeinsamkeiten mit diesen aufweisen. Der Aspekt der Beziehungen zwischen den Pattern unterschiedlicher Kataloge wird insbesondere in Kapitel 6.2 als eine zukünftige Erweiterung des Wissensmodells aufgegriffen. Neben den Entwicklungsplattformen können sich Pattern ausschließlich auf bestimmte Technologien fokussieren. So existiert z. B. ein Pattern-Katalog im Umfeld der Integration, insbesondere der Integration auf Basis der nachrichten-basierten Kommunikation (vgl. [HoWo2004]). Die technologie-spezifischen Kataloge können als Ergänzung zu den grundlegenden und plattform-spezifischen Pattern-Katalogen gesehen werden. Es existieren zahlreiche weitere Pattern-Kataloge, die aufgrund des fehlenden Bezugs zur Softwarearchitektur, nicht weiter betrachtet werden. Hierzu gehört auch der Pattern-Katalog

178

Entwicklung eines pattern-basierten Wissensmodells

von Gamma, Helm, Johnson und Vlissides, der ausschließlich Pattern auf der Entwurfsebene enthält (vgl. Kapitel 4.1.1). Tabelle 5-7 ist ein Hilfsmittel, auf das bei der Auswahl zurückgegriffen werden kann.

Autoren, Titel, Kurzbezeichnung

Beschreibung

Alur, D.; Crupi, J.; Malks, D.: Core J2EE Patterns - Best Practices and Design Strategies [AlCM2003]

Alur, Crupi und Malks dokumentieren eine Menge von Pattern für die J2EE-Plattform. Sie unterscheiden dabei nicht zwischen Architektur- und Entwurfs-Pattern. Einige der sog. Core J2EE Pattern basieren auf anderen grundlegenden Pattern, die in anderen Katalogen beschrieben sind. Darüber hinaus weisen einige Pattern Gemeinsamkeiten mit den sog. Enterprise Solution Pattern (siehe unten) auf. Die Pattern dokumentieren erprobte Lösungsansätze für die Problembereiche der Präsentation, Geschäftslogik und Datenhaltung einer J2EE-basierten Anwendung.

Buschmann, F.; Meunier, R.; Rohnert, H.; Sommerlad, P.; Stal, M.: Pattern-Oriented Software Architecture, Volume 1: A System of Patterns [BMRS1996]

Der Pattern-Katalog ist der erste Band der sog. „PatternOriented Software Architecture“-Serie, die architektur- und entwurfs-bezogene Pattern unabhängig von bestimmten Entwicklungplattformen und Technologien beschreibt. Dieser erste Band dokumentiert Pattern zu unterschiedlichen, unabhängigen Problembereichen, wie z. B. verteilten und interaktiven Anwendungen.

Fowler, M.: Patterns of Enterprise Architecture [Fowl2003]

Fowler charakterisiert in seinem Pattern-Katalog eine Menge von Architektur- und Entwurfsmustern, die keinen Bezug zu einer speziellen Entwicklungsplattform oder Technologien haben. Die referenzierten Problembereiche sind teilweise voneinander abhängig. Einige der Pattern weisen Gemeinsamkeiten mit anderen Pattern-Katalogen auf.

Kircher, Michael; Jain, Prashant: Pattern-Oriented Software Architecture, Volume 3: Patterns for Resource Management [KiJa2004]

Kirchner und Jain dokumentieren im dritten Band der „Pattern-Oriented Software Architecture“-Serie Pattern für den Problembereich des Ressourcenmanagements. Dieser Problembereich wird hierarchisch in drei weitere Bereiche aufgeteilt. Im Gegensatz zu den beiden anderen Bänden der Serie findet keine explizite Klassifikation in Architektur- und Entwurfs-Pattern statt. Die Pattern sind unabhängig von einer spezifischen Entwicklungsplattform oder Technologie.

Schmidt, D. C.; Stal, M.; Rohnert, H.; Buschmann, F.: PatternOriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects [SSRB2000]

Der Pattern-Katalog ist der zweite Band der „PatternOriented Software Architecture“-Serie. Er beschreibt Architektur- und Entwurfs-Pattern für den Problembereich der nebenläufigen und verteilten Objekte. Dieser Problembereich wird hierarchisch in vier weitere Bereiche aufgeteilt. Die Pattern beziehen sich auf keine bestimmte Entwicklungsplattform oder Technologie.

Trowbridge, David; Mancini, Dave; Quick; Dave; Hohpe, Gregor; Newkirk, James; Lavigne, David: Enterprise Solution Patterns Using Microsoft .NET [TMQH2003]

Die sog. Enterprise Solution Patterns dokumentieren eine Menge von Pattern für die .NET-Plattform, wobei zwischen der Architektur-, Entwurfs- und Implementierungsebene unterschieden wird. Einige der Pattern basieren auf anderen grundlegenden Pattern, die in anderen Katalogen beschrieben sind. Darüber hinaus weisen einige Pattern Gemeinsamkeiten mit den sog. Core J2EE Pattern (siehe oben) auf. Die Pattern beziehen sich auf die vier Problembereiche der Datenbank, Anwendung, Verteilung und Infrastruktur.

Tabelle 5-7: Hilfsmittel zur Selektion von Pattern-Katalogen

Entwicklung der Vorgehensweise

179

Sie enthält eine Menge von Pattern-Katalogen, die für viele Anwendungfälle eines konkreten Entwurfs bzw. einer konkreten Bewertung relevant sind. Die Kataloge sind nach der Kurzbezeichnung sortiert aufgelistet. Die Liste erhebt keinen Anspruch auf Vollständigkeit. Tabelle 5-8 fasst die wesentlichen Bestandteile auf Basis der einheitlichen Struktur nochmals zusammen.

Eingabe Beschreibung

- Liste der verfügbaren Pattern-Kataloge Die Liste der verfügbaren Pattern-Kataloge wird hinsichtlich ihrer Relevanz analysiert und eine Liste der zu untersuchenden Pattern-Kataloge erstellt.

Hilfsmittel

- Liste von Pattern-Katalogen, die architektur-relevante Pattern enthalten

Ergebnis

- Liste der zu untersuchenden Pattern-Kataloge Tabelle 5-8: Aktivität: Selektion der Pattern-Kataloge

5.2.2.2.2 Selektion der Architektur-Pattern eines Katalogs Da ein Katalog mehrere Typen von Pattern enthalten kann, werden für jeden zu untersuchenden Pattern-Katalog zunächst die Architektur-Pattern identifiziert. Dabei ist zu beachten, dass nicht in allen Katalogen eine explizite Abgrenzung von Architektur- und Entwurfs-Pattern erfolgt. Wenn diese Abgrenzung explizit innerhalb des Pattern-Katalogs erfolgt, wird das jeweilige Pattern in die Ergebnisliste aufgenommen und die Klassifikation als Architektur-Pattern durch eine Referenz auf die Seite(n) im Pattern-Katalog nachvollziehbar (vgl. Kapitel 5.1.5). Erfolgt keine explizite Abgrenzung, werden auf Basis der Eigenschaft „architektur-bezogen“ die Architektur-Pattern identifiziert, d. h., es handelt sich um ein ArchitekturPattern, wenn das jeweilige Pattern architektur-bezogen ist. Hierzu wird das Kriterium von Clements, Kazman und Klein verwendet, das die Definition des Softwarearchitektur-Begriffs verfeinert (vgl. Kapitel 2.1). Ein Pattern, das eine Begründung bezüglich der Erreichung der Qualitätsanforderungen des gesamten Systems oder die Dekomposition des gesamten Systems unterstützt, ist dementsprechend ein Architektur-Pattern. Auf Basis eines Entwurfs-Pattern, wie z. B. der sog. Factory Method (siehe [GHJV1995, S. 107]), kann keine Begründung der erreichten Qualitätsanforderungen erfolgen, da sich das Pattern auf die Vererbungsbeziehungen einzelner Klassen bezieht und diese keine begründeten Auswirkungen auf die Qualität des gesamten Systems haben. Darüber hinaus ermöglicht ein Entwurfs-Pattern keine Dekomposition des gesamten Systems, da es primär Lösungsansätze auf der Ebene von einzelnen Klassen beschreibt.

180

Entwicklung eines pattern-basierten Wissensmodells

Ein Architektur-Pattern, das auf Basis der oben genannten Definitionen identifiziert wird, enthält in der Vorspalte „Pattern Type“ lediglich einen Bindestrich, der andeutet, dass keine explizite Klassifikation innerhalb des Pattern-Katalogs erfolgt (vgl. Kapitel 5.1.5). Es ist zu beachten, dass der Kontext, der definiert, was Teil der Softwarearchitektur ist und was nicht, ohne einen Bezug zu einem konkreten System, nicht bestimmbar ist (vgl. Kapitel 2.1). Da der Kontext entscheidend für die Analyse des Kriteriums „architektur-bezogen“ ist, kann die Identifikation der Architektur-Pattern nicht immer eindeutig erfolgen, wie folgendes Beispiel verdeutlicht: Ein Pattern „A“ beeinflusst das Qualitätsmerkmal „Q“ grundsätzlich positiv und kann bei der Begründung der Qualität eines Systems verwendet werden. Wenn aber Qualitätsmerkmal „Q“ bei dem konkreten System „S“ keine Rolle spielt, würde in diesem Kontext das Pattern „A“ kein Architektur-Pattern darstellen. Um die Vergleichbarkeit und Nachvollziehbarkeit des Wissensmodells zu gewährleisten, werden bei der Identifikation der Architektur-Pattern alle Qualitätsmerkmale „gleich“ behandelt, d. h., es werden u. U. Pattern als Architektur-Pattern erfasst, obwohl diese in bestimmten Anwendungsfällen mit spezifischen Qualitätsanforderungen keine Pattern auf der Ebene der Architektur darstellen. Diese Vorgehensweise gewährleistet, dass insbesondere innerhalb der Entwurfs eine möglichst große Auswahl von Architektur-Pattern zur Verfügung steht. Tabelle 5-9 dokumentiert die wesentlichen Bestandteile der Aktivität auf Basis der einheitlichen Struktur.

Eingabe Beschreibung

- Ein Katalog aus der Liste der zu untersuchenden Pattern-Kataloge Auf Basis der Pattern-Dokumentationen werden die Pattern auf der Ebene der Softwarearchitektur identifiziert und in einer Liste zusammengefasst.

Hilfsmittel

- Begriffsdefinition „Softwarearchitektur“ - Kriterium der Eigenschaft „architektur-bezogen“

Ergebnis

- Liste der zu untersuchenden Architektur-Pattern eines Katalogs

Tabelle 5-9: Aktivität: Identifikation der Architektur-Pattern eines Katalogs

5.2.2.2.3 Erfassung eines Architektur-Pattern Nachdem die Architektur-Pattern eines Katalogs identifiziert sind, werden diese in das Wissensmodell aufgenommen. Zunächst werden für jedes Pattern die Vorspalten „Pattern Name“, „Source“, „Pattern Type“, „Context“, „Stimulated Artifact“, „Supported General Scenarios“ und „Relationships“ erfasst. Danach werden die unterschiedlichen Auswirkungen innerhalb der jeweiligen Tabellenfelder dokumentiert. Abschließend werden die Tabellenfelder auf Basis der gesamten Menge der Reaktionen farblich klassifiziert.

Entwicklung der Vorgehensweise

181

Insbesondere bei den Vorspalten „Context“, „Stimulated Artifact“, „Supported General Scenarios“ und „Relationships“ sowie bei den Tabellenfeldern zur Erfassung der Reaktionen ist zu beachten, dass die jeweiligen Informationen mehrfach innerhalb der Pattern-Dokumentationen auftreten können. Die Seiten- und Abschnittsreferenzen bestehen aus diesem Grund aus Listen von Seitenzahlen bzw. Abschnitten (Ableitungsregeln „PageReferences“ und „SectionReferences“, siehe Anhang A). In den folgenden Abschnitten werden die Identifikation und Dokumentation der Vorspalten und Tabellenfelder im Detail erläutert. Dokumentation des Namens und der Quelle Der Name des Pattern wird unverändert aus dem Pattern-Katalog bzw. der Pattern-Dokumentation übernommen. Die Kurzbezeichnung, die die Quelle repräsentiert, wird einmalig für einen Pattern-Katalog erstellt und mit dem Erscheinungsjahr sowie einer Seitenreferenz ergänzt (vgl. Kapitel 5.1.4). Dokumentation des Pattern-Typs Die Identifikation der Architektur-Pattern eines Katalogs ist bereits innerhalb der zweiten Aktivität erfolgt (vgl. Kapitel 5.2.2.2.2). Da im Wissensmodell nur Architektur-Pattern erfasst werden, dokumentiert die Vorspalte „Pattern Type“ lediglich, ob die Abgrenzung explizit innerhalb des Pattern-Katalogs erfolgt, oder ob der Erfasser das Pattern auf Basis der Definitionen als „architektur-bezogen“ klassifiziert hat. Die Vorspalte wird entweder mit der festen Zeichenkette "Architectural" und einer Seitenreferenz oder lediglich mit einem Bindestrich gefüllt (vgl. Kapitel 5.1.5). Identifikation und Dokumentation des Kontexts und stimulierten Artefakts Die Vorspalten „Context“ und „Stimulated Artifact“ dokumentieren den Bezug der Zuordnung. Sie machen die zugeordneten Qualitätsmerkmale operationalisierbar, indem insbesondere durch das stimulierte Artefakt ein Kontext hergestellt wird, in dem das Qualitätsmerkmal interpretiert wird (vgl. Kapitel 5.1.5). Die Vorspalte „Context“ kann i. d. R. unmittelbar aus der Pattern-Dokumentation übernommen werden, da die Kataloge innerhalb der Pattern-Schablone einen entsprechenden Abschnitt in der Dokumentation vorsehen (vgl. Kapitel 4.2.1.1). Die Vorspalte „Stimulated Artifact“ beschreibt im Sinne des Modells der QualitätsmerkmalSzenarios das Softwareelement der Architektur, das durch einen Stimulus beeinflusst wird (vgl. Kapitel 3.2.4.3). Das stimulierte Artefakt kann i. d. R. nicht unmittelbar aus der PatternDokumentation entnommen werden, da dieses innerhalb der Pattern-Schablone nicht explizit ausgewiesen wird. Die Abschnitte, die das zugrunde liegende Problem und den entsprechen-

182

Entwicklung eines pattern-basierten Wissensmodells

den Lösungsansatz erläutern (vgl. Kapitel 4.2.1.1), enthalten i. d. R. mehrere Nennungen des stimulierten Artefakts (siehe Kapitel 5.3). Bei der Extraktion ergibt sich die Problematik der Mehrdeutigkeit, d. h., in den Pattern-Dokumentationen werden keine einheitlichen Begriffe für die Bestandteile und Funktionen einer Anwendung bzw. eines Systems verwendet. Analog zu der Problematik, dass die Pattern-Kataloge kein homogenes Qualitätsmodell und daher keine einheitlichen Qualitätsmerkmale verwenden (vgl. Kapitel 4.4), fehlt ein entsprechendes Referenzmodell, das detailliert die logischen Bestandteile und Funktionen einer Anwendung bzw. eines Systems identifiziert, benennt, abgrenzt und beschreibt (vgl. Kapitel 4.1.1). Da die Definition eines derartigen Referenzmodells nicht Ziel der vorliegenden Arbeit ist, wird auf einheitliche Begriffe innerhalb der Vorspalte „Stimulated Artifact“ verzichtet und die Erfassung von mehreren Begriffen erlaubt. Hierdurch wird eine möglichst große Bandbreite von Begriffen, d. h. Funktionen und Bestandteilen, erreicht. So bezieht sich das „Layers“-Pattern (vgl. [BMRS1996, S. 31]) auf Aufgaben (tasks) oder Funktionen (functions) und das Composite View Pattern (vgl. [AlCM2003, S. 262]) auf Sichten (views) und Teilsichten (subviews). Die Begriffe der Pattern-Dokumentation werden unmittelbar übernommen, damit die Nachvollziehbarkeit gewährleistet ist. Identifikation und Dokumentation von generellen Szenarios Die Vorspalte „Supported General Scenarios“ wird mit einer Liste der allgemeinen Szenarios (vgl. Kapitel 3.2.4.3) gefüllt. Diese Szenarios sind implizit innerhalb der Pattern-Dokumentation vorhanden und werden von der Vorgehensweise extrahiert, um den Bezugsrahmen der Zuordnung, der durch die Vorspalten „Context“, „Stimulated Artifact“ und „Supported General Scenarios“ sukzessive verfeinert wird, weiter zu verdeutlichen (vgl. Kapitel 5.1.5). Die allgemeinen Szenarios lassen sich insbesondere aus den Abschnitten der Problembeschreibung extrahieren, wobei aber alle anderen Abschnitte der Pattern-Schablone ebenfalls berücksichtigt werden müssen (siehe Kapitel 5.3). Sie werden in einem satz-basierten Format erfasst, um die Übersichtlichkeit zu gewährleisten. Identifikation und Dokumentation von Beziehungen In der Vorspalte „Relationships“ werden die Beziehungen mit anderen Pattern auf Basis von fünf Beziehungstypen und der Kardinalität dokumentiert (vgl. Kapitel 5.1.6). Die PatternSchablonen sehen zur Dokumentation der Beziehungen zwischen den Pattern i. d. R. dedizierte Abschnitte vor, wobei allerdings auch die anderen Abschnitte einer Pattern-Dokumentation berücksichtigt werden müssen. Da die Beziehungen zwischen den Pattern i. d. R. lediglich informell beschrieben sind (vgl. Kapitel 4.2.3), müssen der jeweilige Beziehungstyp und die Kardinalitäten auf Basis des Dokumentationstextes identifiziert werden. Wenn der Kata-

Entwicklung der Vorgehensweise

183

log eine Pattern-Sprache umfasst, kann diese bei der Analyse hinzugezogen werden. Es ist aber zu beachten, dass nicht jeder Pattern-Katalog eine entsprechende Sprache dokumentiert. Identifikation und Dokumentation von Reaktionen Die Identifikation und Dokumentation der Reaktionen umfassen die Teilschritte der Transformation in das homogene Qualitätsmodell, die Differenzierung von positiven Reaktionen, Sensitivitätspunkten, Abwägungspunkten und negativen Reaktionen, die Erfassung sowie die Sortierung der Reaktionen. Da die Pattern-Kataloge kein homogenes Qualitätsmodell und keine einheitlichen Qualitätsmerkmale verwenden, müssen im Kontext der Erfassung einer Reaktion die unterschiedlichen Qualitätsmerkmale transformiert werden. Hierzu wird innerhalb der Vorgehensweise für jeweils einen Pattern-Katalog eine Menge von Transformationsregeln als Hilfsmittel erstellt und dokumentiert. Diese Regeln werden bei der Erfassung der Architektur-Pattern eines Kataloges identifiziert und kontinuierlich erweitert bzw. angepasst. Die Dokumentation und Verwendung von Transformationsregeln gewährleisten eine einheitliche Betrachtung der Qualitätsmerkmale innerhalb eines Pattern-Katalogs. Buschmann, Meunier, Rohnert et al. verwenden z. B. das Qualitätsmerkmal der Wartbarkeit (maintainability) (siehe [BMRS1996]), das nicht direkt im Qualitätsmodell des Wissensmodells enthalten ist, da zur Vermeidung von Verwechselungen mit der Ebene der Implementierung bzw. des Quellcodes eine Umbenennung durchgeführt wurde (vgl. Kapitel 5.1.3). Das Merkmal der Wartbarkeit (maintainability) lässt sich aber auf das Merkmal der Modifizierbarkeit (modifiability) innerhalb des homogenen Qualitätsmodells abbilden (siehe Kapitel 5.3). Da das homogene Qualitätsmodell allerdings eine weitere Verfeinerung dieses Qualitätsmerkmals vorsieht (Merkmale Analysierbarkeit, Veränderlichkeit, Stabilität, Prüfbarkeit und Übertragbarkeit) und die Zuordnung so tief wie möglich in der Hierarchie erfolgen soll (vgl. Kapitel 5.1.3), Buschmann, Meunier, Rohnert et al. aber keine weitere Verfeinerung vorsehen, wird das Merkmal des Katalogs (Wartbarkeit) auf alle Teilmerkmale der ersten Ebene abgebildet. Das Teilmerkmal der Übertragbarkeit (Portability) stellt in diesem Kontext eine Ausnahme dar. Es wird von Buschmann, Meunier, Rohnert et al. explizit von der Wartbarkeit abgegrenzt und daher nicht innerhalb der Transformation berücksichtigt. Die Transformationsregel würde spezifizieren, dass das Qualitätsmerkmal der Wartbarkeit im Kontext des Pattern-Katalogs auf die Teilmerkmale der Analysierbarkeit, Veränderlichkeit, Stabilität und Prüfbarkeit im Kontext des homogenen Qualitätsmodells abgebildet wird und die relevanten Reaktionen bei allen vier Teilmerkmalen erfasst werden. Tabelle 5-10 zeigt beispielhaft die entsprechende Transformationsregel.

184

Entwicklung eines pattern-basierten Wissensmodells

Transformationsregel Maintainability ĺ Analyzability, Changeability, Stability, Testability Tabelle 5-10: Beispiel für eine Transformationsregel

Aufgrund der sehr einfachen Struktur der Transformationsregeln wird hierfür keine explizite Syntax bzw. Grammatik definiert und die Gestaltung dieses Hilfsmittels dem jeweiligen Erfasser überlassen. Nachdem eine Reaktion eines Architektur-Pattern in das homogene Qualitätsmodell transformiert worden ist, erfolgt die Klassifikation der Reaktion in die Kategorien positive Reaktion, Sensitivitätspunkt, Abwägungspunkt und negative Reaktion (vgl. Kapitel 5.1.7). Bei der Abgrenzung der unterschiedlichen Kategorien müssen insbesondere die Eigenschaften, die die Reaktion direkt beeinflussen, gesucht und analysiert werden. Darüber hinaus ist die Anzahl der beeinflussten Qualitätsmerkmale von hoher Relevanz. Es ist zu beachten, dass aufgrund der Mehrfachnennungen innerhalb der Pattern-Dokumentationen „Inkonsistenzen“ auftreten können. Eine Reaktion kann z. B. durch die Beschreibungen innerhalb des Abschnitts der Problemstellung zunächst als positive Reaktion klassifiziert werden. Die Beschreibungen des Abschnitts der Implementierung enthalten aber den Hinweis auf eine Eigenschaft, die die identische Reaktion maßgeblich beeinflusst. Die zunächst als positive Reaktion klassifizierte Reaktion würde sich zu einem Sensitivitätspunkt „entwickeln“. Die jeweilige Kategorie bestimmt die Ableitungsregel, die für die Erfassung verwendet wird, und die Bestandteile der Dokumentation einer Reaktion. Jede Reaktion soll so nah wie möglich an der Quelle dokumentiert werden, um die Nachvollziehbarkeit zu gewährleisten. Bei der Erfassung von Sensitivitäts- und Abwägungspunkten muss darüber hinaus die grundsätzliche Richtung der Auswirkung einer Eigenschaft spezifiziert werden (vgl. Kapitel 5.1.7.2 und 5.1.7.3). Bei der Analyse der Reaktion und Dokumentation der Zeichen („+“, „-“) muss insbesondere die Rangfolge des jeweiligen Qualitätsmerkmals (vgl. Kapitel 3.2.3.5) beachtet werden, um die grundlegende Richtung einer Reaktion und die Adjektive „besser“ bzw. „schlechter“ semantisch korrekt zu interpretieren. Besteht der Definitionsbereich einer Eigenschaft aus einer eng begrenzten Menge von gültigen Werten, sollte die Beschreibung der Eigenschaft dies kommunizieren. Nachdem alle Reaktionen eines Architektur-Pattern identifiziert, klassifiziert und dokumentiert worden sind, wird die Menge der Reaktionen innerhalb eines Tabellenfelds – entsprechend der vier Kategorien – sortiert, um die Übersichtlichkeit und Vergleichbarkeit zu gewährleisten (vgl. Kapitel 5.1.7).

Validierung der Vorgehensweise und des Wissensmodells

185

Klassifikation der Tabellenfelder Die Klassifikation der Tabellenfelder unterstützt die Herleitung einer Lösung, die auf Basis der Navigation in den Zeilen und Spalten der Tabelle erfolgt (vgl. Kapitel 5.1.2). Die Ermittlung einer Lösung erfordert darüber hinaus die Interpretation der gesamten Menge von Reaktionen (vgl. Kapitel 5.1.7.5). Die farbliche Klassifikation beschreibt unterschiedlichen Kombinationen der Mengen von Reaktionen und basiert auf einer unterschiedlichen Darstellung des Hintergrunds eines Tabellenfelds (vgl. Kapitel 5.1.8). Tabelle 5-11 fasst die wesentlichen Bestandteile der Aktivität auf Basis der einheitlichen Struktur zusammen.

Eingabe

- Ein Pattern aus der Liste der Architektur-Pattern eines Katalogs - Die Dokumentation des Pattern

Beschreibung

Die Erfassung eines Architektur-Patterns besteht aus der Erfassung der Vorspalten und der Dokumentation der unterschiedlichen Reaktionen bezüglich der beeinflussten Qualitätsmerkmale in den Tabellenfeldern. Die erfassten Reaktionen werden sortiert und die einzelnen Tabellenfelder eines Pattern farblich klassifiert.

Hilfsmittel

- Transformationsregeln zwischen den Qualitätsmerkmalen des Katalogs und dem homogenen Qualitätsmodell des Wissensmodells - Grammatik bzw. Ableitungsregeln zur Erfassung der Tabellenfelder

Ergebnis

- Dokumentation des Pattern innerhalb der Wissensbasis Tabelle 5-11: Aktivität: Erfassung eines Architektur-Pattern

5.3

Validierung der Vorgehensweise und des Wissensmodells

Nachdem in den vorherigen Kapiteln eine Vorgehensweise und ein Wissensmodell entwickelt worden sind, wird in diesem Kapitel die Validierung der beiden Entwicklungen dokumentiert. Die Validierung erfolgte auf Basis von drei Pattern-Katalogen mit insgesamt 34 ArchitekturPattern. Die Struktur der folgenden Dokumentation orientiert sich an den in Kapitel 5.2.2 beschriebenen Aktivitäten der Vorgehensweise: Die Selektion der Pattern-Kataloge wird in Kapitel 5.3.1, die Identifikation der Architektur-Pattern in Kapitel 5.3.2 und die Erfassung der Architektur-Pattern in Kapitel 5.3.3 dokumentiert. Innerhalb dieser Kapitel werden die wesentlichen Ergebnisse in einer Tabelle zusammengefasst, die sich an der Tabellenstruktur orientiert, die in den Beschreibungen der Aktivitäten verwendet wurde. Eine übergreifende Zusammenfassung der Ergebnisse der Validierung in Kapitel 5.3.4 schließt dieses Kapitel ab.

186

Entwicklung eines pattern-basierten Wissensmodells

5.3.1 Selektion der Pattern-Kataloge Die Selektion der Pattern-Kataloge erfolgte zum einen mit dem Ziel, die Vorgehensweise und das Wissensmodell „angemessen“ zu validieren, d. h., zur Überprüfung der Entwicklungen sollten mehrere Pattern-Kataloge und eine ausreichende Menge von Architektur-Pattern erfasst werden. Zum anderen sollte die Verwendung der Wissensbasis im Kontext der Bewertung und des Entwurfs von Softwarearchitekturen nachvollziehbar gemacht werden (vgl. Kapitel 5.4), d. h., es sollten viele heterogene Problembereiche betrachtet und der Bezug zur Praxis hergestellt werden. Unter der Berücksichtigung dieser Ziele wurden die in Tabelle 5-12 aufgelisteten Pattern-Kataloge ausgewählt.

Ergebnis

- Buschmann, F.; Meunier, R.; Rohnert, H.; Sommerlad, P.; Stal, M.: Pattern-Oriented Software Architecture, Volume 1: A System of Patterns (siehe [BMRS1996]) - Schmidt, D. C.; Stal, M.; Rohnert, H.; Buschmann, F.: Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects (siehe [SSRB2000]) - Alur, D.; Crupi, J.; Malks, D.: Core J2EE Patterns - Best Practices and Design Strategies [AlCM2003] Tabelle 5-12: Ergebnis der Selektion der Pattern-Kataloge

Der Pattern-Katalog von Buschmann, Meunier, Rohnert et al. enthält architektur- und entwurfsbezogene Pattern, die unabhängig von bestimmten Entwicklungplattformen und Technologien sind. Er betrachtet unterschiedliche, unabhängige Problembereiche (vgl. Tabelle 5-7). Der Katalog enthält u. a. grundlegende Pattern, wie z. B. das „Layers“- (vgl. [BMRS1996, S. 31 ff.]), „Pipes and Filters“- (vgl. [BMRS1996, S. 53 ff.]) und „Model-ViewController“-Pattern (vgl. [BMRS1996, S. 125 ff.]), die den strukturellen Kern von vielen Anwendungen bzw. Systemen bilden. Der Pattern-Katalog von Schmidt, Stal, Rohnert und Buschmann enthält sowohl Architekturals auch Entwurfs-Pattern für den Problembereich der nebenläufigen und verteilten Objekte, ohne den Bezug zu einer bestimmten Entwicklungsplattform oder Technologie (vgl. Tabelle 5-7). Die Pattern des Katalogs beschreiben u. a. die grundlegenden Strukturen, die Lösungsansätze für den Zugriff auf Diensten, die Ereignisbehandlung und die Nebenläufigkeit, die in vielen Betriebssystemen und Servern implementiert sind. Alur, Crupi und Malks erläutern eine Menge von Pattern, die speziell für die J2EE-Plattform dokumentiert worden sind (vgl. Tabelle 5-7). Der Pattern-Katalog wurde ausgewählt, um den Praxisbezug einer speziellen Entwicklungsplattform und die zahlreichen Beziehungen – insbesondere zu dem Katalog von Buschmann, Meunier, Rohnert et al. – zu berücksichtigen. Abbildung 5-26 skizziert die wesentlichen Beziehungen zwischen den Pattern der drei Kataloge in Anlehnung an eine Schichtenarchitektur (vgl. [BMRS1996, S. 31 ff.]). Die Pfeile spe-

Validierung der Vorgehensweise und des Wissensmodells

187

zifizieren eine „benutzt“-Beziehung, d. h., es wird dargestellt, welcher Pattern-Katalog auf andere Kataloge zurückgreift.

Abbildung 5-26: Beziehungen zwischen den ausgewählten Pattern-Katalogen

Die Pattern-Kataloge von Buschmann, Meunier, Rohnert et al. und Schmidt, Stal, Rohnert und Buschmann bilden demnach die Grundlage für die sog. Core J2EE Pattern von Alur, Crupi und Malks. Dabei ist zu beachten, dass die Abbildung nur die wesentlichen Beziehungen darstellt und von den zahlreichen Beziehungen zwischen den einzelnen Pattern abstrahiert. Der Katalog von Buschmann, Meunier, Rohnert et al. hat keinen besonderen Fokus, da er unterschiedliche, unabhängige Problembereiche betrachtet und für sehr viele Anwendungen bzw. Systeme relevant ist. Alur, Crupi und Malks dagegen haben einen speziellen Fokus auf die J2EE-Plattform und beziehen sich somit auf die Entwicklung von J2EE-basierten Anwendungen bzw. Systemen. Sie referenzieren häufig den Katalog von Buschmann, Meunier, Rohnert et al. und dokumentieren zahlreiche Pattern auf dieser Basis. Schmidt, Stal, Rohnert und Buschmann betrachten Pattern, die primär im Kontext der Entwicklung von Betriebssystemen und sog. Application Servern relevant sind. Innerhalb der J2EE-Plattform betreffen diese Pattern insbesondere die Entwicklung von J2EE-kompatiblen Application Servern, so dass hier wiederum eine grundsätzliche Beziehung zu den Core J2EE Patterns existiert.

5.3.2 Identifikation der Architektur-Pattern der Kataloge Nachdem die Auswahl der Pattern-Kataloge abgeschlossen war, wurden für jeden Katalog die jeweiligen Architektur-Pattern identifiziert. Da die Kataloge von Buschmann, Meunier, Rohnert et al. und Schmidt, Stal, Rohnert und Buschmann explizit zwischen Pattern der Architektur- und Entwurfsebene differenzieren, konnten die Architektur-Pattern dieser beiden Kataloge sehr schnell identifziert werden. Im Katalog von Alur, Crupi und Malks findet keine explizite Unterscheidung dieser beiden Pattern-Typen statt. Sie führen keine derartige Klassifizierung durch; jedes Pattern „schwebt“

188

Entwicklung eines pattern-basierten Wissensmodells

nach Auffassung von Alur, Crupi und Malks „irgendwo“ zwischen der Entwurfs- und Architekturebene (vgl. [AlCM2003, S. 11]). Zur Identifikation der Architektur-Pattern wurde deshalb die Definition der Eigenschaft „architektur-bezogen“ mit dem folgenden Ergebnis verwendet: alle Pattern des Katalogs wurden als Architektur-Pattern betrachtet, denn erstens unterstützen sie die Dekomposition einer J2EE-basierten Anwendung und zweitens beeinflusst jedes Pattern die Qualitätsmerkmale der gesamten Anwendung, d. h., auf Basis der Core J2EE Patterns lässt sich grundsätzlich auf die Qualität des gesamten Systems schließen. Da der Bezug zu einem konkreten Entwurf oder einer konkreten Bewertung nicht bekannt ist, kann kein Kontext identifiziert werden. Zur Gewährleistung der Vergleichbarkeit und Nachvollziehbarkeit des Wissensmodells wird aber eine möglichst große Auswahl von Architektur-Pattern angestrebt (vgl. Kapitel 5.2.2.2.2). Tabelle 5-13 listet die identifizierten Architektur-Pattern für jeden Katalog auf.

Ergebnis

- Buschmann, F.; Meunier, R.; Rohnert, H.; Sommerlad, P.; Stal, M. [BMRS1996]: Layers, Pipes and Filters, Blackboard, Broker, Model-View-Controller, Presentation-Abstraction-Control, Microkernel, Reflection - Schmidt, D. C.; Stal, M.; Rohnert, H.; Buschmann, F. [SSRB2000]: Interceptor, Reactor, Proactor, Half-Sync/Half-Async, Leader/Followers - Alur, D.; Crupi, J.; Malks, D. [AlCM2003]: Intercepting Filter, Front Controller, Context Object, Application Controller, View Helper, Composite View, Service to Worker, Dispatcher View, Business Delegate, Service Locator, Session Facade, Application Service, Business Object, Composite Entity, Transfer Object, Transfer Object Assembler, Value List Handler, Data Access Object, Service Activator, Domain Store, Web Service Broker

Tabelle 5-13: Ergebnis der Identifikation der Architektur-Pattern der Kataloge

5.3.3 Erfassung der Architektur-Pattern Die Erfassung der Architektur-Pattern umfasste insgesamt 34 Pattern und wurde auf Basis einer Microsoft Excel32-Tabelle dokumentiert. Ein Ausdruck der vollständigen Tabelle befindet sich im Anhang B und umfasst drei Seiten im DIN-A0-Format. Da innerhalb der Vorgehensweise nur Informationen extrahiert werden können, die Bestandteil der Pattern-Dokumentation sind, wurden eigene Erfahrungen oder tiefergehende Interpretationen der Beschreibung nicht berücksichtigt (vgl. Kapitel 5.2.1). Die Problematik der Inkonsistenzen und Nichtvollständigkeit der existierenden Pattern-Dokumentationen wird in Kapitel 5.3.4 aufgegriffen.

32

Siehe http://office.microsoft.com

Validierung der Vorgehensweise und des Wissensmodells

189

Die Vorspalten konnten – mit zwei Ausnahmen – für alle drei Kataloge problemlos erfasst werden. Die Spalten „Pattern Name“, „Source“, „Pattern Type“ und „Context“ konnten unmittelbar aus der jeweiligen Pattern-Dokumentation übernommen bzw. abgeleitet werden, da die Informationen immer in den gleichen Abschnitten der Dokumentation enthalten waren (insbesondere „Pattern Name“ und „Context“) und durch sehr einfache Ableitungsregeln im Wissensmodell abgebildet werden (insbesondere „Source“). Die erste Ausnahme war die Vorspalte „Stimulated Artifact“, da die Pattern-Dokumentationen zum einen keine dedizierten Abschnitte für diese Information vorsieht und zum anderen in der Pattern-Dokumentation keine einheitlichen Begriffe für die Bestandteile und Funktionen einer Anwendung verwendet werden (vgl. Kapitel 5.2.2.2.3). Aus diesem Grund wurden im Zweifelsfall mehrere Begriffe erfasst, um eine große Bandbreite von Begriffen und Bedeutungen zu berücksichtigen. Die zweite Ausnahme war die Vorspalte „Relationships“, da die Beziehungen zwischen den Pattern häufig nur informell beschrieben und in Bezug auf ihre Syntax und Semantik nicht eindeutig dokumentiert sind (vgl. Kapitel 4.2.3). Die Beziehungstypen konnten i. d. R. auf Basis des Dokumentationstextes identifiziert werden. Die Kardinalitäten dagegen waren teilweise wesentlich schwieriger zu identifizieren, wobei im Zweifelsfall eine optionale Beziehung dokumentiert wurde. Darüber hinaus werden die Beziehungen zwischen den Pattern nicht konsistent in den vorgesehenen Abschnitten der Pattern-Schablone dokumentiert, d. h., es finden sich auch Hinweise auf Beziehungen in anderen Abschnitten der Pattern-Dokumentation. Die Erfassung der Zuordnungen auf Basis der unterschiedlichen Kategorien von Reaktionen erforderte die Transformation in das homogene Qualitätsmodell. Der Pattern-Katalog von Buschmann, Meunier, Rohnert et al. ist der Einzige der ausgewählten Kataloge, der explizit eine teilweise hierarchische Menge von Qualitätsmerkmalen innerhalb eines dedizierten Kapitels erläutert (vgl. [BMRS1996, S. 404 ff.]). Auf Basis dieser Menge von Qualitätsmerkmalen wurden entsprechende Transformationsregeln zur Abbildung auf das homogene Qualitätsmodell des Wissensmodells erstellt und als Hilfsmittel dokumentiert (siehe Tabelle 5-14). Da die Pattern-Dokumentation weitere Qualitätsmerkmale verwendet, die nicht explizit beschrieben und diskutiert werden, wurde die Menge der Transformationsregeln im Verlauf der Erfassung um weitere Regeln erweitert. Diese Qualitätsmerkmale sind in Tabelle 5-14 kursiv dargestellt. Die Identifikation und insbesondere die Zuordnung der Reaktionen zu einem bestimmten Qualitätsmerkmal war im Vergleich zu der Erfassung der Vorspalten komplizierter, da für diese keine dedizierten Abschnitte innerhalb der Pattern-Dokumentation vorgesehen sind. Darüber hinaus werden die Qualitätsmerkmale bei der Beschreibung einer Reaktion uneinheitlich verwendet und nicht konsequent referenziert. Der Problematik der fehlenden dedizierten Abschnitte für die Beschreibung von Zuordnungen konnte durch eine detaillierte Analyse des Dokumentationstextes begegnet werden. In fast al-

190

Entwicklung eines pattern-basierten Wissensmodells

len Abschnitten konnten entsprechende Zuordnungen identifiziert werden, wobei schwerpunktmäßig in den Abschnitten „Consequences“, „Strategies“ und „Implementation“ (vgl. Kapitel 4.2.1.1) positive Reaktionen, Sensitivitätspunkte, Abwägungspunkte und negative Reaktionen gefunden werden konnten. Der uneinheitlichen Verwendung der Qualitätsmerkmale konnte mit einer Erweiterung der Menge von Transformationsregeln begegnet werden. Buschmann, Meunier, Rohnert et al. erläutern z. B. das Qualitätsmerkmal „efficiency“ (vgl. [BMRS1996, S. 407]), verwenden innerhalb der Pattern-Dokumentation aber auch den Begriff der „performance“ mit der gleichen Semantik (vgl. z. B. [BMRS1996, S. 33, S. 62, S. 84, S. 106, S. 143, S. 191]). Die inkonsequente Referenzierung der Qualitätsmerkmale wurde durch eine detaillierte Analyse der Pattern-Dokumentation gelöst. Die Zuordnung zu einem Qualitätsmerkmal erfolgt häufig nicht durch die Nennung eines konkreten Qualitätsmerkmalsbegriffs, sondern durch eine entsprechende Umschreibung der Reaktion. Aufgrund der Begriffsdefinitionen und semantischen Beschreibungen, die dem homogenen Qualitätsmodell und den einheitlichen Qualitätsmerkmalen zugrunde liegen, konnten auch in diesen Fällen entsprechende Reaktionen identifiziert und dokumentiert werden. Buschmann, Meunier, Rohnert et al. beschreiben z. B. innerhalb der Dokumentation des sog. „Pipes and Filters“-Pattern die folgende Reaktion: „Reuse of filter component. Support for recombination leads to easy reuse of filter components.“ [BMRS1996, S. 68]. Diese Reaktion wurde dem Qualitätsmerkmal der Wartbarkeit (maintainability) zugeordnet und aufgrund einer entsprechenden Transformationsregel (vgl. Tabelle 5-14) auf die Merkmale Veränderlichkeit (changeability), Stabilität (stability) und Prüfbarkeit (testability) abgebildet, d. h., zu jedem Merkmal wurde die gleiche positive Reaktion erfasst. Die Klassifikation der Reaktionen in die jeweiligen Kategorien erwies sich als problemlos, obwohl das Konzept der Sensitivitäts- und Abwägungspunkte nicht direkt bei der Dokumentation der Pattern verwendet wird und diese Punkte als solche nicht explizit in der PatternSchablone vorgesehen sind. Die Identifikation der positiven und negativen Reaktionen sowie Sensitivitäts- und Abwägungspunkte erfolgte auf Basis der detaillierten Analyse des Dokumentationstextes, wobei insbesondere die Beschreibung entsprechender Eigenschaften eine Unterscheidung möglich machte. Der Pattern-Katalog von Schmidt, Stal, Rohnert und Buschmann enthält keine explizite Diskussion oder Beschreibung der verwendeten Qualitätsmerkmale. Da es sich um den zweiten Band der „Pattern-Oriented Software Architecture“-Serie handelt (vgl. Kapitel 5.2.2.2.1), lag zunächst die Vermutung nahe, dass die gleichen Qualitätsmerkmale wie im ersten Band verwendet werden. Obwohl Schmidt, Stal, Rohnert und Buschmann darauf hinweisen, dass sie die gleiche Pattern-Schablone wie im ersten Band verwenden (vgl. [SSRB2000, S. xxvii]),

Validierung der Vorgehensweise und des Wissensmodells

191

konnte innerhalb einer Literaturrecherche keine explizite Referenz auf die Definition der Qualitätsmerkmale im ersten Band gefunden werden. Aus diesem Grund erfolgte keine Übernahme der Transformationsregeln des ersten Bands, sondern eine erneute Erstellung und Dokumentation der Regeln im Verlauf der Erfassung (siehe Tabelle 5-14). Es stellte sich heraus, dass die Qualitätsmerkmale, die in beiden Pattern-Katalogen verwendet werden, auch mit den gleichen Transformationsregeln abgebildet werden konnten. Die Differenzen zwischen den beiden Mengen von Regeln, die nach der jeweiligen Erfassung dokumentiert worden sind, lassen sich durch die unterschiedlichen Pattern erklären, die erfasst worden sind: Es wurden nur Transformationsregeln für einen Katalog erfasst, wenn entsprechende Qualitätsmerkmale innerhalb der Pattern-Dokumentation referenziert worden sind. Anderenfalls wurde keine Transformationsregel erfasst. Die Identifikation und Zuordnung der Reaktionen zu den Qualitätsmerkmalen erfolgte mit den gleichen Problemen wie bei der Erfassung der Architektur-Pattern des ersten Bands: Es existieren keine dedizierten Abschnitte innerhalb der Pattern-Dokumentation, die Qualitätsmerkmale werden uneinheitlich verwendet und es erfolgt keine konsequente Referenzierung der Qualitätsmerkmale. Aber es konnten die gleichen Lösungsansätze verwendet werden, d. h. eine detaillierte Analyse des Dokumentationstextes und die Erweiterung der Transformationsregeln. Die Klassifikation der Reaktionen in die jeweiligen Kategorien erfolgte auf die gleiche Art und Weise wie beim ersten Band. Der Katalog von Alur, Crupi und Malks enthält ebenfalls keine explizite Diskussion oder Beschreibung der verwendeten Qualitätsmerkmale, sondern nennt diese primär im Kontext der Ziele der J2EE-Plattform (vgl. [AlCM2003, S. 12, S. 117]). Aus diesem Grund wurden die Transformationsregeln – analog zu den beiden vorherigen Pattern-Katalogen – im Verlauf der Erfassung erstellt und dokumentiert (siehe Tabelle 5-15). Sofern Transformationsregeln für die gleichen Qualitätsmerkmale erfasst wurden, stimmen diese mit den Regeln überein, die bei der Erfassung der anderen beiden Kataloge verwendet wurden (z. B. „maintainability“, „reusability“, „portability“). Andere Transformationsregeln wurden ausschließlich im Kontext dieses Katalogs erfasst (z. B. „availability“, „modularity“). Die Identifikation, Klassifikation und Zuordnung der Reaktionen war mit den gleichen Problemen verbunden und es konnten die gleichen Lösungsansätze verwendet werden. Die Tabellen 5-14 und 5-15 enthalten die identifizierten und verwendeten Transformationsregeln für jeden der ausgewählten Pattern-Kataloge.

192

Entwicklung eines pattern-basierten Wissensmodells

Pattern-Katalog

Transformationsregeln33

Buschmann, F.; Meunier, R.; Rohnert, H.; Sommerlad, P.; Stal, M.: Pattern-Oriented Software Architecture, Volume 1: A System of Patterns [BMRS1996]

- Changeability ĺ Analyzability, Changeability, Stability, Testability, Adaptability, Installability, Replaceability - Maintainability ĺ Analyzability, Changeability, Stability, Testability - Extensibility ĺ Analyzability, Changeability, Stability, Testability - Restructuring ĺ Analyzability, Changeability, Stability, Testability - Portability ĺ Adaptability, Installability, Replaceability - Interoperability ĺ Replaceability - Efficiency ĺ Time behaviour, Resource utilization - Reliability ĺ Fault tolerance, Recoverability - Fault tolerance ĺ Fault tolerance, Recoverability - Robustness ĺ Fault tolerance - Testability ĺ Testability - Reusability ĺ Analyzability, Changeability, Stability, Testability - Performance ĺ Time behaviour, Resource utilization - Exchangeability ĺ Maintainability - Flexibility ĺ Maintainability - Complexity ĺ Maintainability - Scalability ĺ Adaptability

Schmidt, D. C.; Stal, M.; Rohnert, H.; Buschmann, F.: PatternOriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects [SSRB2000]

- Maintainability ĺ Analyzability, Changeability, Stability, Testability - Extensibility ĺ Analyzability, Changeability, Stability, Testability - Flexibility ĺ Maintainability - Reusability ĺ Analyzability, Changeability, Stability, Testability - Complexity ĺ Maintainability - Efficiency ĺ Time behaviour, Resource utilization - Performance ĺ Time behaviour, Resource utilization - Fault tolerance ĺ Fault tolerance, Recoverability - Security ĺ Authentication, Access control, Data confidentiality, Data integrity, Non-repudiation, Availability, Auditing - Scalability ĺ Adaptability - Latency ĺ Time behaviour, Resource utilization - Portability ĺ Adaptability, Installability, Replaceability - Robustness ĺ Fault tolerance - Simplification ĺ Maintainability

Tabelle 5-14: Transformationsregeln bei der Erfassung der Pattern (Teil 1)

33

Die Qualitätsmerkmale, die in der Pattern-Dokumentation verwendet, aber nicht explizit beschrieben bzw. definiert werden, werden kursiv dargestellt.

Validierung der Vorgehensweise und des Wissensmodells

Pattern-Katalog Alur, D.; Crupi, J.; Malks, D.: Core J2EE Patterns - Best Practices and Design Strategies [AlCM2003]

193

Transformationsregeln - Reusability ĺ Analyzability, Changeability, Stability, Testability - Efficiency ĺ Time behaviour, Resource utilization - Modularity ĺ Analyzability, Changeability, Stability, Testability - Maintainability ĺ Analyzability, Changeability, Stability, Testability - Flexibility ĺ Maintainability - Testability ĺ Testability - Performance ĺ Time behaviour, Resource utilization - Extensibility ĺ Analyzability, Changeability, Stability, Testability - Availability ĺ Fault tolerance, Recoverability - Complexity ĺ Maintainability - Integrity ĺ Data integrity - Portability ĺ Adaptability, Installability, Replaceability

Tabelle 5-15: Transformationsregeln bei der Erfassung der Pattern (Teil 2)

5.3.4 Zusammenfassung der Ergebnisse Die Anwendbarkeit der Vorgehensweise und Erstellung einer Wissensbasis auf Grundlage des Wissensmodells wurde anhand von drei Pattern-Katalogen und insgesamt 34 ArchitekturPattern überprüft. Zusammengefasst lässt sich feststellen, dass die Vorgehensweise anwendbar ist und das Wissensmodell zum Aufbau einer Wissensbasis verwendet werden kann. Die Ergebnisse der Validierung werden im Folgenden zusammengefasst. Die Vorspalten konnten i. d. R. für alle drei Kataloge problemlos erfasst werden, da die Informationen in den gleichen Abschnitten der Dokumentation enthalten sind und durch sehr einfache Ableitungsregeln im Wissensmodell abgebildet werden konnten. Die Zuordnungen zu Qualitätsmerkmalen konnten trotz der uneinheitlichen und inkonsequenten Verwendung der Merkmale in den Pattern-Dokumentationen identifiziert und dokumentiert werden, indem entsprechende Transformationsregeln erstellt und dokumentiert, sowie die einheitlichen Begriffsdefinitionen und -beschreibungen der Qualitätsmerkmale verwendet wurden. Die Verwendung eines homogenen Qualitätsmodells stellt einen wesentlichen Mehrwert dar, da die Vergleichbarkeit innerhalb eines Pattern-Katalogs und zwischen unterschiedlichen Pattern-Katalogen gewährleistet wird. Die Pattern-Schablonen definieren zwar i. d. R. dedizierte Abschnitte in denen die Reaktionen der Pattern dokumentiert werden sollen („Consequences“), jedoch werden diese Abschnitte nicht konsequent zur Dokumentation der Reaktionen verwendet, da viele Reaktionen außerhalb dieses Abschnittes beschrieben werden.

194

Entwicklung eines pattern-basierten Wissensmodells

Die Kataloge von Buschmann, Meunier, Rohnert et al. und Schmidt, Stal, Rohnert und Buschmann dokumentieren z. B. sehr viele Sensitivitäts- und Abwägungspunkte ausschließlich in dem „Implementation“-Abschnitt (vgl. z. B. Auswirkungen des „Layers“-Pattern auf das Qualitätsmerkmal der Analysierbarkeit und Auswirkungen des „Interceptor“-Pattern auf das Qualitätsmerkmal der Fehlertoleranz). Analog beschreiben Alur, Crupi und Malks viele dieser Punkte ausschließlich in ihrem „Strategies“-Abschnitt (vgl. z. B. Auswirkungen des „Front Controller“-Pattern auf das Qualitätsmerkmal der Analysierbarkeit). Die Identifikation der beeinflussten Qualitätsmerkmale ist daher nicht ausschließlich auf Basis von einzelnen Abschnitten möglich, sondern erfordert die Betrachtung aller Abschnitte der Pattern-Dokumentation. Bei der Erfassung konnten – neben der inkonsistenten Verwendung des „Consequences“-Abschnitts – weitere Inkonsistenzen und Unklarheiten in den Pattern-Dokumentationen identifiziert werden. Ein Beispiel ist die Pattern-Dokumentation des sog. „Service Locator“-Pattern, die innerhalb der Problembeschreibung des Pattern einen Hinweis auf die Portabilität enthält, die bei der direkten Verwendung von herstellerspezifischen Objektimplementierungen im Umfeld des sog. Java Naming and Directory Interface (JNDI) gefährdet ist (vgl. [AlCM2003, S. 315]). Darüber hinaus enthält der „Forces“-Abschnitt einen Hinweis, dass durch das Pattern diese herstellerspezifischen Objektimplementierungen gekapselt werden sollen (vgl. [AlCM2003, S. 316]). Daneben konnte ein Szenario identifiziert werden, das sich auf die Portierung auf einen anderen Anwendungs-Server bezieht (vgl. Abbildung 5-27).

- Porting the application to another application server (315) [Problem] Abbildung 5-27: Beispielhaftes Szenario des „Service Locator“-Pattern

Die Interpretation dieser beiden Hinweise und des Szenarios führt zu der Schlussfolgerung, dass das Service Locator Pattern die Portabilität durch die Kapselung von herstellerspezifischem Quellcode positiv beeinflusst. Die Pattern-Dokumentation und der „Consequences“Abschnitt enthalten aber keinen weiteren Hinweis, dass die Portabilität durch das Pattern positiv beeinflusst wird, was eine Inkonsistenz bzw. Unklarheit darstellt. Darüber hinaus kann die „Vollständigkeit“ der Pattern bzw. der Wissensbasis hinsichtlich der gesamten Menge der Qualitätsmerkmale analysiert werden. Nach der Erfassung der Architektur-Pattern aus drei Pattern-Katalogen zeigt die Wissensbasis eine sehr starke Konzentration der Pattern-Reaktionen auf die Qualitätsmerkmale der Effizienz und Wartbarkeit. Andere Qualitätsmerkmale, wie z. B. die Benutzbarkeit und Sicherheit, werden durch die Pattern, die innerhalb der Validierung erfasst wurden, kaum beeinflusst, d. h., es existieren noch wenige

Validierung der Vorgehensweise und des Wissensmodells

195

Pattern, die diese Qualitätsmerkmale unterstützen. Abbildung 5-28 verdeutlich dies anhand einer sehr stark verkleinerten Darstellung der Excel-Tabelle.

Abbildung 5-28: Darstellung der Wissensbasis (sehr starke Verkleinerung)

196

5.4

Entwicklung eines pattern-basierten Wissensmodells

Verwendung der Wissensbasis

Im vorliegenden Kapitel wird die Verwendung der Wissensbasis erläutert. Dabei wird zwischen einer Verwendung im Kontext des Entwurfs (siehe Kapitel 5.4.1) und der Bewertung von Softwarearchitekturen (siehe Kapitel 5.4.2) unterschieden.

5.4.1 Verwendung im Kontext des Entwurfs von Softwarearchitekturen Der Entwurf einer Softwarearchitektur wird von zahlreichen technischen, betriebswirtschaftlichen und sozialen Faktoren beeinflusst (vgl. Kapitel 2.4). Zu diesen Einflussfaktoren gehören u. a. die funktionalen und nicht-funktionalen Anforderungen an das System bzw. die Anwendung (vgl. Kapitel 3.2.2.2). Im Kontext des Entwurfs einer Softwarearchitektur müssen diese Anforderungen umgesetzt, d. h., durch eine Menge von Softwareelementen implementiert werden. Die Gestaltung dieser Softwareelemente mit ihren Eigenschaften und Beziehungen führt zu einer Menge von Entwurfsproblemen, die innerhalb des Entwurfs der Softwarearchitektur gelöst werden müssen. Das Konzept der Pattern unterstützt die Lösung dieser Entwurfsprobleme, indem existierendes Entwurfswissen in einer strukturierten Form verfügbar gemacht wird und innerhalb des Entwurfs wiederverwendet werden kann (vgl. Kapitel 4.1). Die mehrfache vorherige Verwendung eines Lösungsansatzes ermöglicht es, eine qualitative Aussage bezüglich der Auswirkungen des Pattern auf die nicht-funktionalen Qualitätsmerkmale des Systems bzw. der Anwendung zu treffen. Im Kontext des Entwurfs einer Softwarearchitektur auf Basis des Pattern-Konzepts müssen die Pattern identifiziert werden, die innerhalb der Softwarearchitektur eingesetzt werden können. Die Identifikation und Auswahl eines Pattern erfolgt auf Basis der Problemstellung und den Konsequenzen, die sich durch den Einsatz des Pattern ergeben (vgl. Kapitel 4.1.1). Die Diskussion der Verwendung der Wissensbasis unterscheidet deshalb zwischen der Auswahl auf Basis der Problemstellung und der Auswahl auf Basis der Konsequenzen.

5.4.1.1 Auswahl eines Pattern auf Basis der Problemstellung Da Pattern abstrakte Problemstellungen (und Lösungen) beschreiben, muss überprüft werden, ob ein entsprechendes abstraktes Problem zur Lösung einer konkreten Fragestellung verwendet werden kann. Die Überprüfung kann grundsätzlich auf Basis der entsprechenden Abschnitte der Pattern-Dokumentation erfolgen, die diese Problemstellungen beschreiben. Die Pattern-Kataloge erläutern i. d. R. Pattern-Klassifikationen, -Sprachen und -Auswahlprozesse, die den Prozess der Identifikation und Auswahl effizienter gestalten sollen.

Verwendung der Wissensbasis

197

Die Untersuchung ausgewählter Pattern-Kataloge hat gezeigt, dass die Problemstellung innerhalb der Pattern-Klassifikationen, -Sprachen und -Auswahlprozesse eine übergeordnete Rolle einnimmt, d. h., die Selektion eines Pattern betrachtet zunächst die Problemstellung und reduziert die gesamte Menge der Pattern eines Katalogs (vgl. Kapitel 4.4). Die potenziellen Pattern werden anschließend hinsichtlich ihrer Konsequenzen analysiert, um schließlich ein Pattern auszuwählen. Da die Pattern-Kataloge kein homogenes Qualitätsmodell verwenden und die Auswirkungen auf die Qualitätsmerkmale nicht detailliert klassifizieren, kann das Wissensmodell komplementär zu den Pattern-Klassifikationen, -Sprachen und -Auswahlprozessen eingesetzt werden, um die Konsequenzen eines Pattern im Zusammenhang mit den Qualitätsanforderungen zu untersuchen (siehe Abbildung 5-29).

Abbildung 5-29: Untersuchung der Auswirkungen eines Pattern auf Basis des Wissensmodells

Die erste Identifikation kann z. B. auf Basis einer Pattern-Sprache oder eines Auswahlprozesses erfolgen, um eine überschaubare Menge von potenziellen Pattern zu erhalten (vgl. Abbildung 5-29, Pfeil 1). Die anschließende Analyse der Konsequenzen erfolgt durch die Unterstützung des Wissensmodells, indem – ausgehend von einem potenziellen Pattern – die Auswirkungen auf die Qualitätsmerkmale untersucht werden (vgl. Abbildung 5-29, Pfeile 2). Da ein Feld der Tabelle zu jeder Kategorie eine oder mehrere Reaktionen enthalten kann, muss die Menge der Reaktionen entsprechend interpretiert und aufgelöst werden, um eine Aussage bezüglich der Unterstützung eines Qualitätsmerkmals treffen zu können (vgl. Kapitel 5.1.7.5). Wenn die Eignung eines Pattern nach der Untersuchung der Auswirkungen auf die Qualitätsmerkmale bestätigt wird, kann das Wissensmodell auch dazu verwendet werden, um auf Basis der dokumentierten Beziehungen des Pattern (vgl. Kapitel 5.1.6) weitere potenzielle Pattern zu identifizieren, so dass der Prozess der Auswahl eines Pattern erneut ausgeführt wird.

198

Entwicklung eines pattern-basierten Wissensmodells

5.4.1.2 Auswahl eines Pattern auf Basis der Konsequenzen Neben der Identifikation und Auswahl eines Pattern auf Basis der Problemstellung kann das Wissensmodell auch verwendet werden, um – ausgehend von den Qualitätsmerkmalen – direkt die Pattern zu identifizieren, die ein bestimmtes Qualitätsmerkmal beeinflussen. Diese Vorgehensweise wird von den Pattern-Klassifikation, -Sprachen und -Auswahlprozessen der untersuchten Kataloge nicht unterstützt (vgl. Kapitel 4.4). Ausgehend von einem Qualitätsmerkmal, das unterstützt werden soll, wird die Menge von Spalten selektiert, die Zuordnungen zu dem Qualitätsmerkmal enthalten. Je tiefer das Qualitätsmerkmal in der hierarchischen Struktur des Qualitätsmodells positioniert ist, desto weniger Spalten werden selektiert. Wenn es sich bei dem Qualitätsmerkmal um ein Teilmerkmal handelt, das innerhalb des Qualitätsmodells nicht weiter verfeinert wird, umfasst die Selektion genau eine Spalte. Anderenfalls müssen die im Folgenden erläuterten Schritte für jede Spalte ausgeführt werden.

p1

p2

p3

pm

Die Menge der Zeilen, die jeweils ein Pattern repräsentieren, wird zunächst durch eine Betrachtung der farblichen Klassifikation der Tabellenfelder (vgl. Kapitel 5.1.8) reduziert (siehe Abbildung 5-30).

Abbildung 5-30: Identifikation und Auswahl eines Pattern auf Basis der Konsequenzen

Es werden nur die Zeilen selektiert, die nicht weiß sind und daher mindestens eine Reaktion des Pattern bezüglich des Qualitätsmerkmals enthalten (vgl. Abbildung 5-30, Pfeile 1). Für alle selektierten Pattern erfolgt eine Analyse des Kontexts und des stimulierten Artefakts (vgl. Kapitel 5.1.5). Wenn diese nicht mit der konkreten Problemstellung übereinstimmen, wird das Pattern bzw. die Zeile aus der Selektionsmenge gelöscht (vgl. Abbildung 5-30, Pfeile 2). Diese Überprüfung kann u. U. schwierig sein, da für die Beschreibung des stimulierten Artefakts keine einheitlichen Begriffe im Sinne eines Referenzmodells verfügbar sind (vgl. Kapitel 5.2.2.2.3). Die allgemeinen Szenarios, die durch das Pattern unterstützt werden, sollten inner-

Verwendung der Wissensbasis

199

halb der Überprüfung ebenfalls betrachtet werden. Die verbleibenden Zeilen stellen potenzielle Pattern dar. Für jedes Pattern muss die Menge der Reaktionen untersucht werden, um festzustellen, in welchem Ausmaß ein Pattern das Qualitätsmerkmal unterstützt (vgl. Abbildung 5-30, Pfeile 3). Diese Analyse umfasst – analog zu der Auswahl eines Pattern auf Basis der Problemstellung – die Interpretation und Auflösung der Menge von Reaktionen, die innerhalb eines Tabellenfeldes dokumentiert werden können (vgl. Kapitel 5.1.7.5). Das Wissensmodell kann darüber hinaus verwendet werden, um – ausgehend von einem geeigneten Pattern – weitere potenzielle Pattern zu identifizieren, indem die Beziehungen des Pattern zu anderen Pattern (vgl. Kapitel 5.1.6) untersucht werden. Die Beziehungen zwischen den Pattern können z. B. verwendet werden, um weitere Pattern zu finden, die die gleichen Qualitätsmerkmale unterstützen.

5.4.1.3 Bewertung der Verwendung im Kontext des Entwurfs Die wesentlichen Vorteile des Wissensmodells liegen in der Verwendung eines homogenen Qualitätsmodells und der detaillierten Klassifikation und Beschreibung der Auswirkungen auf die Qualitätsmerkmale. Das homogene Qualitätsmodell unterstützt z. B. die Vergleichbarkeit von Pattern eines oder mehrerer Kataloge. Darüber hinaus wird durch das „normierte“ Qualitätsmodell der Abgleich mit den Qualitätsanforderungen vereinfacht. Im Idealfall werden die Qualitätsanforderungen ebenfalls auf Basis des ISO/IEC 9126-Standards spezifiziert (vgl. Kapitel 3.2.3), wobei aber die geringfügigen Modifikationen bzw. Erweiterungen des Qualitätsmodells berücksichtigt werden müssen (vgl. Kapitel 5.1.3). Die detaillierte Klassifikation bzw. Beschreibung der Auswirkungen auf die Qualitätsmerkmale unterstützt die effiziente und effektive Untersuchung der Konsequenzen eines Pattern. Das Wissensmodell ermöglicht durch die Dokumentation von positiven und negativen Reaktionen sowie Sensitivitäts- und Abwägungspunkten einen schnellen Überblick über die Auswirkungen eines Pattern, die innerhalb der Pattern-Dokumentation „verstreut“ sind (vgl. Kapitel 5.3.4) und eine vollständige Analyse des Dokumentationstextes erfordern. Durch die konsolidierte Beschreibung der Auswirkungen unterstützt das Wissensmodell auch eine Überprüfung, ob innerhalb der Auswahl eines Pattern alle Auswirkungen berücksichtigt worden sind. Darüber hinaus ermöglicht das Wissensmodell auf Basis der dokumentierten Beziehungen, weitere potenzielle Pattern zu identifizieren und eine erneute Untersuchung der Konsequenzen zu initiieren. Die Nachteile ergeben sich im Wesentlichen aus der Tatsache, dass das Wissensmodell redundante Informationen enthält und als zusätzliche Quelle verwendet werden muss, d. h., es ist

200

Entwicklung eines pattern-basierten Wissensmodells

z. B. nicht direkt in einen Auswahlprozess der Pattern-Kataloge oder einer Pattern-Sprache integriert.

5.4.2 Verwendung im Kontext der Bewertung von Softwarearchitekturen Die Verwendung der Wissensbasis im Kontext der Bewertung von Softwarearchitekturen wird im Folgenden am Beispiel der Architecture Tradeoff Analysis-Methode (vgl. Kapitel 3.3.2) verdeutlicht. Diese Methode wird stellvertretend für die szenario-basierten Bewertungsmethoden (vgl. Kapitel 3.3.1) betrachtet. Die Wissensbasis kann innerhalb der Analyse der Architekturansätze eingesetzt werden, so dass die entsprechenden Arbeitsschritte der Methode effizienter und effektiver ausgeführt werden können (siehe Kapitel 5.4.2.1). Eine Bewertung der Unterstützung des Wissensmodells im Kontext der ATAM schließt das vorliegende Kapitel ab (siehe Kapitel 5.4.2.2).

5.4.2.1 Verwendung im Kontext der Architecture Tradeoff Analysis-Methode Die Wissensbasis kann im Kontext der Architecture Tradeoff Analysis-Methode den sechsten und achten Arbeitsschritt unterstützen und verfeinern (vgl. Kapitel 3.3.2.5). Diese Arbeitsschritte stellen den Kern der Methode dar und umfassen eine Analyse, wie gut die Architekturansätze bzw. Architektur-Pattern, die innerhalb der Softwarearchitektur eingesetzt werden, zu den Qualitätsanforderungen der Anwendung bzw. des Systems passen (vgl. Kapitel 3.3.2.1). Für jedes hoch-priorisierte Szenario, das innerhalb des Nutzwert-Baums dokumentiert worden ist, werden die architektur-bezogenen Ansätze identifiziert, die die jeweilige Anforderung umsetzen. Die beiden Arbeitsschritte unterscheiden sich lediglich hinsichtlich des Umfangs des Nutzwert-Baums, der innerhalb des siebten Schritts erweitert werden kann. Jeder identifizierte architektur-bezogene Ansatz wird vom Bewertungsteam auf der Basis von Analysefragen, die sich auf unterschiedliche Bereiche beziehen, untersucht (vgl. Abbildung 3-22, Pfeil 2). Diese Bereiche umfassen z. B. die Untersuchung von Sensitivitäts- und Abwägungspunkten, die Stärken und Schwächen des Ansatzes sowie die Interaktionen und Abwägungen mit anderen Architekturansätzen (vgl. Kapitel 3.3.2.5). Die Analysefragen bilden die Grundlage für eine Diskussion innerhalb des Architekturteams und für die Identifikation von potenziellen Risiken und Sicherheiten (vgl. Abbildung 3-22, Pfeil 3). Das Ziel der Fragen ist die Gewinnung einer Menge von Informationen, so dass sich das Bewertungsteam durch eine rudimentäre Analyse des Architekturansatzes davon überzeugen kann, dass der gewählte Architekturansatz zur Erreichung der relevanten Qualitätsanforderungen ausreichend ist.

Verwendung der Wissensbasis

201

Die Wissensbasis unterstützt die Erstellung, Überprüfung und Dokumentation der Analysefragen. Außerdem können der sechste und achte Arbeitsschritt durch die Verwendung der Wissensbasis weiter strukturiert und verfeinert werden. Die Identifikation der architektur-bezogenen Ansätze erfolgt weiterhin durch den Architekten bzw. das Architekturteam (siehe Abbildung 5-31, Pfeil 1).

Abbildung 5-31: Verwendung der Wissensbasis im Kontext der Architecture Tradeoff Analysis-Methode

Da auf Basis der Dokumentation der unterschiedlichen Reaktionen Analysefragen unmittelbar abgeleitet werden können, wird die Erstellung von Analysefragen durch die detaillierte Klassifikation und Dokumentation der Auswirkungen eines Pattern (vgl. Kapitel 5.1.7) wesentlich vereinfacht, (vgl. Abbildung 5-31, Pfeil 2): ƒ Die Schwächen eines architektur-bezogenen Ansatzes bzw. Architektur-Pattern werden

durch negative Reaktionen dokumentiert (vgl. Kapitel 5.1.7.4). Neben der Zuordnung zu einem Qualitätsmerkmal, kann die Beschreibung der negativen Reaktionen als Grundlage für die Formulierung entsprechender Analysefragen verwendet werden. ƒ Die Sensitivitäts- und Abwägungspunkte eines architektur-bezogenen Ansatzes bzw.

Architektur-Pattern werden als entsprechende Reaktionen dokumentiert (vgl. Kapitel 5.1.7.2 und 5.1.7.3). Die Dokumentation enthält neben der Beschreibung der Eigenschaft eine detaillierte Spezifikation der grundsätzlichen Auswirkung der Eigenschaft, die innerhalb der Analyse des Architekturansatzes unmittelbar wiederverwendet werden kann, um Risiken und Sicherheiten zu identifizieren. Die einzelnen Bestandteile der Dokumentation von Sensitivitäts- und Abwägungspunkten können im Kontext der Formulierung von entsprechenden Analysefragen verwendet werden. ƒ Die Stärken eines architektur-bezogenen Ansatzes bzw. eines Architektur-Pattern wer-

den durch positive Reaktionen dokumentiert (vgl. Kapitel 5.1.7.1). Analog zu den nega-

202

Entwicklung eines pattern-basierten Wissensmodells

tiven Reaktionen, kann die Beschreibung der Reaktion als Grundlage für die Formulierung von Analysefragen verwendet werden. Darüber hinaus können der Kontext, das stimulierte Artefakt und die allgemeinen Szenarios die Erstellung von Analysefragen unterstützen, indem sie einen Rahmen für die Formulierung von Fragen bilden. Die detaillierte Dokumentation der Reaktionen ermöglicht eine Überprüfung der Vollständigkeit, d. h., die Beantwortung der Frage, ob alle Schwächen und Stärken sowie Sensitivitätsund Abwägungspunkte innerhalb der Analyse durch entsprechende Fragen berücksichtigt worden sind. Auch die Dokumentation der Analysefragen wird unterstützt, indem auf die Beschreibung der Reaktionen, den Kontext und/oder das stimulierte Artefakt zurückgegriffen wird. Die einzelnen Bestandteile der Dokumentation können in die Dokumentation der Analysefragen und -antworten übernommen werden. Die Verfeinerung der Arbeitsschritte kann auf Basis der farblichen Klassifikation der Tabellenfelder (vgl. Kapitel 5.1.8) erfolgen: ƒ Wenn das Tabellenfeld weiß ist und somit keine Reaktionen enthält, existiert keine

Auswirkung bezüglich des entsprechenden Qualitätsmerkmals. Die Aussage des Architekten bzw. Architekturteams, dass das Architektur-Pattern ein bestimmtes hoch-priorisiertes Szenario, und damit das entsprechende Qualitätsmerkmal unterstützt, sollte kritisch überprüft werden. Die Ursache für die falsche Identifikation kann darin liegen, dass der Architekt bzw. das Architekturteam das Szenario und/oder das ArchitekturPattern nicht richtig verstanden hat bzw. haben. Das entsprechende Szenario sollte nochmals analysiert und ggf. verfeinert werden. Darüber hinaus sollte das Verständnis des Architektur-Pattern auf Basis der Pattern-Dokumentation vertieft werden. ƒ Ein grüner Hintergrund verdeutlicht, dass ausschließlich positive Reaktionen in Bezug

zu einem Qualitätsmerkmal dokumentiert sind. Die Analyse umfasst lediglich die Überprüfung, ob das hoch-priorisierte Szenario unterstützt wird. ƒ Wenn der Hintergrund des Tabellenfelds gelb ist, enthält das Feld mindestens einen

Sensitivitätspunkt, aber keinen Abwägungspunkt und keine negative Reaktion. Für jeden Sensitivitätspunkt muss die Eigenschaft bezüglich ihrer konkreten Ausprägung untersucht und festgestellt werden, ob eine positive oder negative Reaktion eintritt. Auf Basis dieser Reaktion und weiterer direkter positiver Reaktionen kann analysiert werden, ob das hoch-priorisierte Szenario unterstützt wird. ƒ Ein rot-brauner Feldhintergrund verdeutlicht, dass das Tabellenfeld mindestens einen

Abwägungspunkt, aber keine negative Reaktion enthält. Für jeden Abwägungspunkt muss die Ausprägung der Eigenschaft untersucht werden, um festzustellen, ob eine positive oder negative Reaktion eintritt. Analog müssen die Eigenschaften der u. U. vor-

Verwendung der Wissensbasis

203

handenen Sensitivitätspunkte untersucht werden. Auf Basis der „aufgelösten“ Reaktionen und weiterer direkter positiver Reaktionen kann analysiert werden, ob das hochpriorisierte Szenario unterstützt wird. ƒ Wenn das Tabellenfeld mindestens eine negative Reaktion enthält, ist der Hintergrund

des Felds rot. Die u. U. vorhandenen Sensitivitäts- und Abwägungspunkte müssen durch eine Analyse der Ausprägungen der Eigenschaften in direkte Reaktionen „aufgelöst“ werden. Anschließend kann auf Basis der Menge von direkten Reaktionen und unter Berücksichtigung des Kontexts und des stimulierten Artefakts untersucht werden, ob das hoch-priorisierte Szenario unterstützt wird. Der direkten negativen Reaktion sollte hierbei besondere Aufmerksamkeit geschenkt werden. Die Überprüfung, ob das hoch-priorisierte Szenario unterstützt wird, muss neben den Reaktionen auch den Kontext und das stimulierte Artefakt berücksichtigen, da durch diese ein Bezug zur Interpretation der Reaktionen hergestellt wird (vgl. Kapitel 5.1.7.5). Die Erstellung von Analysefragen wird darüber hinaus durch die Dokumentation der Beziehungen zwischen Pattern (vgl. Kapitel 5.1.6) unterstützt, da auf Basis der Dokumentation der unterschiedlichen Beziehungstypen Interaktionen und Abwägungen mit anderen ArchitekturPattern (vgl. Kapitel 3.3.2.5) unmittelbar abgeleitet werden können.

5.4.2.2 Bewertung der Unterstützung der Architecture Tradeoff AnalysisMethode Die Verwendung der Wissensbasis führt zu einer stärkeren Strukturierung der Analyse der Architekturansätze, indem die Erstellung, Überprüfung und Dokumentation der Analysefragen durch die detaillierte Klassifikation und Dokumentation der Auswirkungen eines Pattern unterstützt wird. Darüber hinaus können der sechste und achte Arbeitsschritt auf Basis der farblichen Klassifikation der Tabellenfelder verfeinert werden. Die Wissensbasis bildet einen Rahmen für die Erstellung von Analysefragen: Auf Basis des Kontexts, des stimulierten Artefakts, der allgemeinen Szenarios und der Reaktionen können entsprechende Fragen abgeleitet werden. Dieser Rahmen bietet gegenüber den Pattern-Dokumentationen und -Katalogen den Vorteil, dass wesentlich effizienter auf die relevanten Informationen zugegriffen werden kann. Die Verwendung der Wissenbasis reduziert die Gefahr, dass die Generierung von Analysefragen bzw. die Diskussion der Architekturansätze ins Stocken gerät (vgl. Kapitel 3.3.2.7). Die Wissensbasis kann zur Überprüfung der Vollständigkeit der Analysefragen verwendet werden, so dass die Gefahr reduziert wird, dass Architekturansätze unvollständig betrachtet werden (vgl. Kapitel 3.3.2.7). Durch die vollständige Betrachtung der Architekturansätze können alle Sicherheiten und Risiken identifiziert und dokumentiert werden. Die Verwendung der

204

Entwicklung eines pattern-basierten Wissensmodells

Wissensbasis erhöht daher die Qualität der Aussage, ob die Architektur für einen definierten Einsatzbereich, der durch die Anforderungen innerhalb des Nutzwert-Baums spezifiziert wird, geeignet ist oder nicht (vgl. Kapitel 3.1). Die stärkere Strukturierung der Analyse der Architekturansätze reduziert auch die Abhängigkeit der ATAM von den Kenntnissen und Fähigkeiten des Bewertungsteams (vgl. Kapitel 3.3.2.7). Die Methode kann auch erfolgreich angewendet werden, wenn z. B. nicht alle Mitglieder des Bewertungsteams alle verwendeten Architekturansätze detailliert kennen. Die architektur-bezogenen Ansätze bzw. Architektur-Pattern müssen jedoch grundsätzlich innerhalb des Bewertungsteams bekannt sein. Die Wissensbasis kann nicht dazu verwendet werden ein detailliertes Verständnis bezüglich des Architekturansatzes aufzubauen. Hierzu sollte auf die Pattern-Dokumentation und den Pattern-Katalog zurückgegriffen werden. Das homogene Qualitätsmodell, das innerhalb des Wissensmodells verwendet wird, kann die Überprüfung, ob ein hoch-priorisiertes Szenario unterstützt wird, vereinfachen, wenn der Nutzwert-Baum auf Basis des gleichen Qualitätsmodells erstellt worden ist. Anderenfalls muss eine Transformation der Qualitätsmerkmale erfolgen, um festzustellen, ob das Szenario unterstützt wird oder nicht.

5.5

Zusammenfassung

In diesem Kapitel wurde ein pattern-basiertes Wissensmodell zur Unterstützung des Entwurfs und der Bewertung von Softwarearchitekturen entwickelt (vgl. Kapitel 5.1). Das Wissensmodell bildet die Beziehungen zwischen einer Menge von Architektur-Pattern und den Qualitätsmerkmalen eines Qualitätsmodells ab. Die Beziehungen zwischen Pattern und Qualitätsmerkmalen sind grundsätzlich bereits in Pattern-Katalogen und -Dokumentationen beschrieben und werden mit einer Vorgehensweise, die in Kapitel 5.2 beschrieben wurde, extrahiert und in das Wissensmodell übernommen. Die Validierung der Vorgehensweise und des Wissensmodells erfolgte auf Basis einer Menge von ausgewählten Pattern-Katalogen und führte zu einer entsprechenden Wissensbasis, die innerhalb einer Excel-Tabelle dokumentiert worden ist (vgl. Kapitel 5.3). Die Verwendung der Wissensbasis wurde abschließend in Kapitel 5.4 im Rahmen des Entwurfs und der Bewertung von Softwarearchitekturen erläutert. Die Wissensbasis unterstützt den Entwurf und die Bewertung von Softwarearchitekturen, da die Struktur und der Aufbau des Wissensmodells einen effizienten und effektiven Zugriff auf die Beziehungen zwischen den Architektur-Pattern und den Qualitätsmerkmalen ermöglicht.

6 Schlussbetrachtung In diesem letzten Kapitel der Arbeit werden zunächst die Ergebnisse der Arbeit in zusammengefasster Form dargestellt (siehe Kapitel 6.1). Daran anschließend wird in Kapitel 6.2 der weitere Forschungsbedarf erläutert, der sich aus den Untersuchungen und Ergebnissen, die in der vorliegenden Arbeit durchgeführt bzw. erzielt worden sind, ableiten lässt. Den Abschluss des Kapitels bildet ein Ausblick in Abschnitt 6.3; er widmet sich der weiteren Entwicklung des Entwurfs und der Bewertung von Softwarearchitekturen auf Basis von Pattern.

6.1

Zusammenfassung der Ergebnisse

Das Ziel der vorliegenden Arbeit bestand in der Untersuchung der Frage, wie die Beziehungen zwischen den Entwurfsentscheidungen innerhalb der Softwarearchitektur und deren Auswirkungen auf die Qualität des Systems ermittelt und dokumentiert werden können, damit auf Basis dieser Kenntnis der Entwurf und die Bewertung einer Softwarearchitektur effizienter und effektiver erfolgen kann (vgl. Kapitel 1.2). Die Zielsetzung wurde durch die Bearbeitung von vier Forschungsfragen erreicht, die als Teilziele der Arbeit abgeleitet wurden. Die Grundlagen und der Bezugsrahmen des Entwurfs von Softwarearchitekturen wurden im zweiten Kapitel erarbeitet. Die zentralen Ergebnisse des Kapitels umfassen die Bildung eines konzeptuellen Rahmens für die vorliegende Arbeit und die Herausarbeitung der großen Relevanz der Softwarearchitektur; sie stellt die wesentliche Begründung für die dezidierte Bewertung einer Softwarearchitektur dar. Im dritten Kapitel wurden die Konzepte und Methoden zur Bewertung von Softwarearchitekturen betrachtet. Neben den grundlegenden Zielen und Annahmen der Bewertung von Softwarearchitekturen wurden die Auswirkungen der Entwurfsentscheidungen bei der Gestaltung der Softwarearchitektur auf die Qualität des Systems erläutert. Es wurde untersucht, wie die verschiedenen Konzepte und Modelle der Softwarequalität zur Definition und Überprüfung der Anforderungen im Kontext der Softwarearchitekturen eingesetzt werden können (vgl. Forschungsfrage 1). Das Modell der Qualitätsmerkmal-Szenarios wurde in diesem Zusammenhang als ein geeigneter Ansatz identifiziert, um Qualitätsanforderungen an Softwarearchitekturen zu definieren und zu überprüfen. Darüber hinaus wurden im dritten Kapitel verschiedene existierende Methoden zur Bewertung einer Softwarearchitektur vorgestellt und untersucht, wie diese die Beziehungen zwischen den Entwurfsentscheidungen innerhalb der Softwarearchitektur und deren Auswirkungen auf die Qualität des Systems identifizieren, untersuchen und bewerten (vgl. Forschungsfrage 2). Das wesentliche Ergebnis der Untersuchung bildet die Feststellung, dass die Anwendbarkeit und der Erfolg einer szenario-basierten Methode stark von den Kenntnissen und Erfahrungen der beteiligten Architekten bzw. des Bewertungsteams abhängen und die Verwendung von do-

206

Schlussbetrachtung

kumentierten Erfahrungen mit Architekturansätzen und/oder Pattern-Katalogen die mangelnden Kenntnisse eines Bewertungsteams nicht vollständig kompensieren kann. Das vierte Kapitel erläuterte das Konzept der Pattern im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen. Im besonderen Fokus der Untersuchungen stand die Frage, wie im Rahmen des Pattern-Konzepts die Entwurfsentscheidungen innerhalb der Softwarearchitektur und deren Auswirkungen auf die Qualitätsmerkmale dokumentiert werden (vgl. Forschungsfrage 3). Das wesentliche Ergebnis der Untersuchung war die Feststellung, dass die Auswirkungen der Pattern auf die Qualitätsmerkmale innerhalb der ausgewählten Pattern-Kataloge nur eine untergeordnete Rolle spielen. Die Auswirkungen werden zwar dokumentiert, jedoch werden keine konsistente Terminologie, keine einheitlichen Begriffsdefinitionen und kein homogenes Qualitätsmodell verwendet. Die Verwendung des Pattern-Konzepts ist grundsätzlich möglich und sinnvoll, aber die Identifikation und Bewertung der Auswirkungen sind mit einem relativ großen Aufwand verbunden. Im fünften Kapitel wurden die Ergebnisse der Kapitel 1 und 1 als Grundlage für die Entwicklung eines pattern-basierten Wissensmodells verwendet (vgl. Forschungsfrage 4). Das Kapitel erläuterte zunächst die Entwicklung eines Wissensmodells, das die Grundlage für die Dokumentation der Beziehungen zwischen den Entwurfsentscheidungen innerhalb der Softwarearchitektur und deren Auswirkungen auf die Qualität des Systems bildet. Das Wissensmodell bildet die Beziehungen zwischen einer Menge von Architektur-Pattern und den Qualitätsmerkmalen eines homogenen Qualitätsmodells ab. Es unterstützt den Entwurf und die Bewertung von Softwarearchitekturen, da die Struktur und der Aufbau des Wissensmodells einen effizienten und effektiven Zugriff auf die Beziehungen zwischen den Architektur-Pattern und den Qualitätsmerkmalen des Qualitätsmodells ermöglichen. Im Anschluss wurde der Aufbau einer Wissensbasis dargestellt, das Wissensmodell validiert und die Verwendung der Wissensbasis erläutert. Die wesentlichen Ergebnisse des Kapitels umfassen das Wissensmodell, die Vorgehensweise zum Aufbau einer Wissensbasis und die Wissensbasis, die durch die Validierung des Wissensmodells und der Vorgehensweise entstanden ist.

6.2

Weiterer Forschungsbedarf

Die Untersuchungen und Ergebnisse der vorliegenden Arbeit ermöglichen die Ableitung von weiterem Forschungsbedarf in den folgenden Bereichen: ƒ Validierung der Effizienz und Effektivität des Wissensmodells, ƒ Erweiterung des Wissensmodells, ƒ Erweiterung der Pattern-Sprachen und -Schablonen und

Weiterer Forschungsbedarf

207

ƒ Entwicklung eines Werkzeugs zur Verwaltung und Verwendung der Wissensbasis.

In den folgenden Kapiteln werden die vier Bereiche und ihre jeweiligen Forschungsfragen kurz erläutert.

6.2.1 Validierung der Effizienz und Effektivität des Wissensmodells Aus wissenschaftstheoretischer Sicht besteht der Bedarf einer Validierung der Effizienz und Effektivität des Wissensmodells im Kontext des Entwurfs und der Bewertung von Softwarearchitekturen. Eine Validierung könnte theoretisch auf Basis von Experimenten erfolgen, die den Entwurf und die Bewertung einer beispielhaften Softwarearchitektur durch zwei Gruppen von Softwarearchitekten umfasst. Eine Gruppe erhält zur Unterstützung des Entwurfs und der Bewertung lediglich eine ausgewählte Menge von Pattern-Katalogen und die andere Gruppe erhält zusätzlich (oder ausschließlich) die Wissensbasis, in der die Pattern der ausgewählten Kataloge erfasst worden sind. Die Zeit, die jede Gruppe für den Entwurf der Softwarearchitektur benötigt, und die Qualität der Softwarearchitektur könnten z. B. als Indikatoren für die Effizienz und Effektivität des Wissensmodells verwendet werden. Analog könnten z. B. die benötigte Zeit und die identifizierten Risiken und Sicherheiten als Indikatoren für die Effizienz und Effektivität im Kontext der Bewertung einer Softwarearchitektur verwendet werden. Derartige Experimente erscheinen allerdings aus einer forschungstheoretischen und pragmatischen Sicht unrealistisch, da die Kenntnisse und Erfahrungen der Softwarearchitekten einen großen Einfluss auf den Entwurf und die Bewertung einer Softwarearchitektur haben (vgl. Kapitel 2.4 und 3.3.2.7). Um die Aussagefähigkeit der Experimente zu gewährleisten, müssten beide Gruppen aus einer homogenen Menge von Softwarearchitekten bestehen, d. h. Architekten, die alle den gleichen Kenntnisstand und die gleichen Fähigkeiten aufweisen. Daneben ist die Wiederholbarkeit der Experimente nur sehr schwer zu gewährleisten, denn der Entwurf (und die Bewertung) beeinflussen aufgrund eines Rückkopplungseffekts die Kenntnisse und Fähigkeiten der Architekten, so dass Softwarearchitekturen nicht auf Basis der gleichen Einflussfaktoren entstehen können (vgl. Kapitel 2.4).

6.2.2 Erweiterung des Wissensmodells Der Forschungsbedarf im Bereich der Erweiterung des Wissensmodells umfasst zum einen die weiterführende Berücksichtigung der Beziehungen zwischen den Pattern und zum anderen die Entwicklung eines Referenzmodells für die Bestandteile und allgemeinen Funktionen einer Anwendung. Die Beziehungen zwischen den Pattern werden aus der Pattern-Dokumentation extrahiert und auf Basis des Wissensmodells dokumentiert (vgl. Kapitel 5.1.6). Im Kontext des Entwurfs

208

Schlussbetrachtung

und der Bewertung einer Softwarearchitektur können die Beziehungen verwendet werden, um ausgehend von einem bereits ausgewählten bzw. untersuchten Pattern weitere Pattern zu identifizieren (vgl. Kapitel 5.4.1 und 5.4.2). Die Beziehungen könnten aber auch verwendet werden, um die Vollständigkeit und Integrität der Pattern-Dokumentation und des Wissensmodells zu überprüfen. Wenn z. B. ein Pattern B eine Spezialisierung von einem Pattern A ist, stellt sich die Frage, wie sich die Vererbungsbeziehung zwischen den beiden Pattern auf die Menge der allgemeinen Szenarios (vgl. Kapitel 5.1.5) und Reaktionen (vgl. Kapitel 5.1.7) auswirkt. Im Detail stellt sich z. B. die Frage, ob eine Reaktion des vererbenden Pattern auch immer zu einer Reaktion beim Einsatz des erbenden Pattern führt oder ob Reaktionen „überschrieben“ werden können bzw. „verschwinden“ können. Die Festlegung der detaillierten Semantik der Beziehungen könnte eine Erweiterung des Wissensmodells erfordern. Sie könnte aber auch dazu verwendet werden, die Pattern-Dokumentation hinsichtlich der Vollständigkeit und Integrität zu überprüfen, indem z. B. die Vererbungsbeziehungen im Detail validiert werden. Bei der Identifikation und Dokumentation des stimulierten Artefakts ergab sich die Problematik, dass in den Pattern-Dokumentationen keine einheitlichen Begriffe für die Bestandteile und allgemeinen Funktionen einer Anwendung bzw. eines Systems verwendet werden (vgl. Kapitel 5.2.2.2.3). Der Forschungsbedarf, der durch diese Problematik entsteht, könnte die Entwicklung eines Referenzmodells umfassen, das detailliert die logischen Bestandteile und allgemeinen Funktionen einer Anwendung bzw. eines Systems identifiziert, benennt, abgrenzt und beschreibt. Das Referenzmodell könnte – in Anlehnung an das homogene Qualitätsmodell des Wissensmodells – die Identifikation und Dokumentation des stimulierten Artefakts unterstützen.

6.2.3 Erweiterung der Pattern-Dokumentation Im Bereich der Erweiterung der Pattern-Dokumentation umfasst der Forschungsbedarf die Anpassung der Pattern-Schablonen und die Entwicklung einer Pattern-Sprache. Die Anpassung der Pattern-Schablonen beinhaltet die Forschungsfrage, ob und wie die unterschiedlichen Schablonen der Pattern-Kataloge vereinheitlicht werden können. Eine derartige Vereinheitlichung der Pattern-Schablonen könnte auch die Definition und Verwendung eines homogenen Qualitätsmodells mit einheitlichen Qualitätsmerkmalen umfassen. Darüber hinaus stellt sich die Frage, wie die Reaktionen eines Pattern detaillierter und exakter beschrieben werden könnten, ohne dass die informelle Beschreibungsform der Pattern-Dokumentation aufgegeben werden muss. Die Dokumentation der Auswirkungen eines Pattern innerhalb des Wissensmodells stellt einen ersten Lösungsvorschlag in diesem Kontext dar. Eine einheitliche

Weiterer Forschungsbedarf

209

Pattern-Schablone könnte z. B. die Klassifikation und grundlegende Richtung der Auswirkungen vorschreiben. Die Entwicklung einer Pattern-Sprache könnte die Forschungsfrage untersuchen, wie die unterschiedlichen Beziehungstypen zwischen den Pattern innerhalb einer Sprache berücksichtigt werden könnten. Die Entwicklung einer derartigen Pattern-Sprache würde voraussetzen, dass die Semantik der Beziehungen zwischen den Pattern genau spezifiziert worden ist (vgl. Kapitel 6.2.2). Eine Pattern-Sprache könnte daneben die unterschiedlichen Auswirkungen der Pattern auf die Qualitätsmerkmale des Systems berücksichtigen. Wenn z. B. ein Pattern A, das die Veränderlichkeit in Bezug auf die Geschäftslogik positiv unterstützt, mit einem Pattern B, das auf die Veränderlichkeit in Bezug auf die Geschäftslogik negativ reagiert, kombiniert wird, stellt sich die Frage, welche Auswirkungen die Kombination der Pattern auf die Veränderlichkeit des Gesamtsystems hat.

6.2.4 Entwicklung eines Werkzeugs zur Verwaltung und Verwendung der Wissensbasis Es besteht weiterer Forschungsbedarf im Bereich der Entwicklung eines Werkzeugs zur Verwaltung und Verwendung der Wissensbasis. Im Kontext der Validierung der Vorgehensweise und des Wissensmodells wurde auf Basis einer Microsoft Excel-Tabelle, die die Struktur und den Aufbau des Wissensmodells abbildet, eine Wissensbasis aufgebaut. Die Anwendung Microsoft Excel ermöglicht die einfache Erfassung von Pattern und die grundlegende Navigation in der Wissensbasis. Ein Werkzeug könnte die Verwaltung und Verwendung der Wissensbasis effizienter und effektiver gestalten, indem dedizierte Erfassungs- und Navigationsfunktionen bereitgestellt werden. Die Entwicklung eines derartigen Werkzeugs könnte zunächst einen funktionalen Entwurf umfassen, der die Grundlage für eine Implementierung bildet. Der Prozess der Erfassung eines Pattern könnte durch das Werkzeug unterstützt werden, indem entsprechende Formulare bereitgestellt werden und die eingegebenen Daten in Bezug auf die Syntax, die durch die Grammatik in Anhang A definiert wird, überprüft werden. Die Navigation in der Wissensbasis könnte durch entsprechende Selektionsfunktionen unterstützt werden, die sich an den verschiedenen Verwendungsformen der Wissensbasis orientieren (vgl. Kapitel 5.4). Die Selektionsfunktionen könnten im Kontext des Entwurfs auf Basis von sog. Wizards die Auswahl eines Pattern unterstützen und im Kontext der Bewertung rudimentäre Analysefragen und Checklisten zu einem ausgewählten Pattern generieren.

210

6.3

Schlussbetrachtung

Ausblick

Die Einführung von neuen und die Integration von bestehenden IT-Systemen führen zu einer steigenden Größe und Komplexität der Systeme, die gleichzeitig eine wachsende Anzahl von Anforderungen in immer kürzeren Projektlaufzeiten umsetzen müssen. Die Entwicklung von qualitativ-hochwertigen IT-Systemen erfordert daher zunehmend mehr Ressourcen und ist häufig mit großen Risiken verbunden, die im Kontext eines Softwareentwicklungsprozesses effizient gesteuert und kontrolliert werden müssen. Die Softwarearchitektur ist in diesem Kontext die Grundlage für die Projektplanung und ein wichtiges Kommunikationsinstrument innerhalb eines Projekts. Die Entwurfsentscheidungen, die innerhalb der Softwarearchitektur getroffen werden, beeinflussen maßgeblich die Qualität eines komplexen IT-Systems, so dass die Qualität der Softwarearchitektur eine zentrale Bedeutung erhält. Die Qualität einer Softwarearchitektur kann allerdings nur im Kontext einer Menge von spezifizierten Anforderungen beurteilt werden, so dass eine Softwarearchitektur – als Ganzes betrachtet – stets eine individuelle Lösung zu einem spezifischen Problem ist. Die Hersteller von Entwicklungsplattformen und -werkzeugen vermarkten ihre Produkte häufig mit dem Argument, eine „standardisierte“ Softwarearchitektur zu implementieren und Standardisierungsorganisationen behaupten häufig, eine „standardisierte“ Softwarearchitektur innerhalb ihrer Standards bzw. Spezifikationen zu definieren, um implizit zu kommunizieren, dass ein detaillierter Entwurf einer Softwarearchitektur nicht mehr notwendig ist. Bei einer genaueren Betrachtung der Produkte und Standards stellt sich allerdings heraus, dass die Softwarearchitekturen lediglich einen Rahmen spezifizieren, der auf der Ebene der Softwarearchitektur noch großen Entscheidungsspielraum gibt. Die umfangreichen Pattern-Kataloge für die .NET- und J2EE-Plattform belegen diese Behauptung: Wenn diese „standardisierten“ Softwarearchitekturen tatsächlich „vollständige“ Softwarearchitekturen spezifizieren würden, wären diese Pattern-Kataloge überflüssig. Die Softwarearchitekturen können darüber hinaus selten vollständig konform zum „Standard“ implementiert werden, da neue Systeme häufig durch die Integration von bestehenden IT-Systemen entstehen und diese eine vom „Standard“ abweichende Softwarearchitektur aufweisen. Die große Relevanz der Softwarearchitektur führt – unter der Berücksichtigung der steigenden Größe und Komplexität der Systeme – zu einer zunehmenden Bedeutung des Entwurfs und der Bewertung von Softwarearchitekturen. Der Entwurf und die Bewertung von komplexen Softwarearchitekturen wird aber trotz der fortschreitenden Forschungsaktivitäten und der zunehmenden Erkenntnisse in dem Themengebiet (vgl. z. B. [ShCl2006a; ShCl2006b; Shaw2001]) vorerst eine Aufgabe für erfahrene Softwarearchitekten mit speziellen Kenntnissen und Fähigkeiten bleiben. Aufgrund der gro-

Ausblick

211

ßen Relevanz der Softwarearchitektur für das Projektmanagement wird die Rolle des Softwarearchitekten in diesem Zusammenhang ebenfalls einen großen Stellenwert einnehmen. Im Kontext des Entwurfs wird die Dokumentation der Softwarearchitektur durch Notationen und Werkzeuge bereits gut unterstützt. Eine werkzeug-basierte Unterstützung des Entwurfs der Softwarearchitektur ist allerdings noch nicht erkennbar, d. h., die eigentlichen Entwurfsentscheidungen müssen von einem oder mehreren Softwarearchitekten getroffen werden. Das Konzept der Pattern erhält in diesem Zusammenhang eine zunehmende Bedeutung, da durch die Einführung einer neuen Abstraktionsebene die Komplexität des Entwurfs wesentlich reduziert wird und auf erprobtes Entwurfswissen zurückgegriffen werden kann. Die zunehmende Bedeutung der Qualität einer Softwarearchitektur erfordert die Bewertung der Architektur innerhalb eines Softwareentwicklungsprojektes. Es ist zu erwarten, dass die Bewertung der Softwarearchitektur als eine verbindliche Aktivität in die existierenden Vorgehensmodelle integriert und zunehmend durch weitere Konzepte, Modelle und Werkzeuge unterstützt werden wird.

Literaturverzeichnis AISJ1977

Alexander, Christopher; Ishikawa, Sara; Silverstein, Murray; Jacobson, Max; Fiksdahl-King, Ingrid; Angel, Shlomo: A Pattern Language. Oxford University Press, New York 1977.

AKMJ2005

Ali Babar, Muhammad; Kitchenham, Babara; Mehashwari, Piyush; Jeffery, Ross: Mining Patterns for Improving Architecting Activities - A Research Program and Preliminary Assessment. In: Proceedings of the 9th International Conference on Evaluation and Assessment in Software Engineering, 2005.

Albe1975

Albert, Hans: Konstruktion und Kritik: Aufsätze zur Philosophie des kritischen Rationalismus. 2. Aufl., Hoffmann und Campe, Hamburg 1975.

AlCM2003

Alex1979

Alur, Deepak; Crupi, John; Malks, Dan: Core J2EE Patterns - Best Practices and Design Strategies. 2. Aufl., Prentice Hall, New York 2003. Alexander, Christopher: The Timeless Way of Building. Oxford University Press, New York 1979.

AliB2004

Ali Babar, M.: Scenarios, Quality Attributes, and Patterns: Capturing and Using their Synergistic Relationships for Product Line Architectures. In: Proceedings of the 11th Asia-Pacific Software Engineering Conference. IEEE Computer Society, 2004, S. 574-578.

AlKM2006a

Ali Babar, Muhammad; Kitchenham, Barbara; Maheshwari, Piyush: The Value of Architecturally Significant Information Extracted from Patterns for Architecture Evaluation - A Controlled Experiment. In: Proceedings of the 17th Australian Software Engineering Conference, IEEE Computer Society 2006, S. 379-390.

AlKM2006b

Ali Babar, Muhammad; Kitchenham, Barbara; Maheshwari, Piyush: Assessing the Value of Architectural Information Extracted from Patterns for Architecting. In: Proceedings of the 10th International Conference on Evaluation and Assessment in Software Engineering, 2006.

AlZJ2004

Ali Babar, Muhammad; Zhu, Liming; Jeffrey, Ross: A Framework for Classifying and Comparing Software Architecture Evaluation Methods. In: Proceedings of the 2004 Australian Software Engineering Conference. IEEE Computer Society, 2004, S. 309-318.

BaCK2003

Bass, Len; Clements, Paul; Kazman, Rick: Software Architecture in Practice. 2. Aufl., Addison-Wesley, Boston et al. 2003.

214

Balz1998

BELS2003

Literaturverzeichnis

Balzert, Helmut: Lehrbuch der Software-Technik - Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung. Spektrum Akademischer Verlag, Heidelberg et al. 1998. Barbacci, Mario R.; Ellison, Robert; Lattanze, Anthony J.; Stafford, Judith A.; Weinstock, Charles B.; Wood, Williams G.: Quality Attribute Workshops (QAWs). 3. Aufl., Forschungsbericht CMU/SEI-2003-TR-016 des Software Engineering-Instituts, Carnegie Mellon University, Pittsburgh 2003.

BLBV2004

Bengtsson, PerOlof; Lassing, Nico; Bosch, Jan; van Vliet Hans: Architecture-level Modifiability Analysis (ALMA). In: The Journal of Systems and Software 69 (2004) 1-2, S. 129-147.

BMRS1996

Buschmann, Frank; Meunier, Regine; Rohnert, Hans; Sommerlad, Peter; Stal, Michael: Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. Wiley, Chichester 1996.

Booc1994

Booch, Grady: Object-Oriented Analysis and Design with Applications. 2. Aufl., Benjamin Cummings, Redwood City 1994.

BPSM2004

Bray, Tim; Paoli, Jean; Sperberg-McQueen, C. M.; Maler, Eve; Yergeau, François: Extensible Markup Language (XML) 1.0. W3C Recommendation vom 04.02.2004. http://www.w3.org/TR/2004/REC-xml-20040204.

Broo1995

Brooks, Frederick P.: The Mythical Man-Month: Essays on Software Engineering. Jubiläumsauflage von 1995. Addison-Wesley, Boston et al. 1995.

BuRa1970

Buxton, J. N.; Randell, B.: Software Engineering Techniques. Report on a working conference on software engineering techniques. NATO Science Committee, Birmingham 1970.

CBBG2003

Clements, Paul; Bachmann, Felix; Bass, Len; Garlan, David; Ivers, James; Little, Reed; Nord, Robert; Stafford, Judith: Documenting Software Architectures - Views and Beyond. Addision-Wesley, Boston et al. 2003.

Clem2000

Clements, Paul: Active Reviews for Intermediate Design. Forschungsmemorandum CMU/SEI-2000-TN-010 des Software Engineering-Instituts, Carnegie Mellon University, Pittsburgh 2000.

ClKK2002

Clements, Paul; Kazman, Rick; Klein, Mark: Evaluating Software Architectures - Methods and Case Studies. Addison-Wesley, Boston et al. 2002.

Literaturverzeichnis

ClNo2002

215

Clements, Paul; Northrop, Linda: Software Product Lines - Practices and Patterns. Addison-Wesley, Boston et al. 2002.

CuBe1989

Cunningham, Ward; Beck, Kent: A Laboratory For Teaching ObjectOriented Thinking. In: Proceedings of the Conference on Object Oriented Programming Systems Languages and Applications. ACM Press, New York 1989, S. 1-6.

Dijk1967

Dijkstra, Edsger W.: The structure of the "the"-multiprogramming system. In: Proceedings of the first ACM symposium on Operating System Principles. ACM Press, New York 1967, S. 10.1-10.6.

Dijk1968

Dijkstra, Edsger W.: The structure of the "the"-multiprogramming system. In: Communications of the ACM 11(1968) 5, S. 341 - 346.

DoNi2002

Dobrica, Liliana; Niemelä, Eila: A Survey on Software Architecture Analysis Methods. In: IEEE Transactions on Software Engineering 28 (2002) 7, 2002, S. 638-653.

EiHM2007

Eicker, Stefan; Hegmanns, Christian; Malich, Stefan: Auswahl von Bewertungsmethoden für Softwarerarchitekturen. Forschungsbericht Nr. 14 des Institutes für Informatik und Wirtschaftsinformatik, Universität Duisburg-Essen, Essen 2007.

Fowl1999

Fowler, Martin: Refactoring - Improving the Design of Existing Code. Addison-Wesley, Boston et al. 1999.

Fowl2003

Fowler, Martin: Patterns of Enterprise Architecture. Addision-Wesley, Boston 2003.

Garv1984

Garvin, David A.: What does "Product Quality" Really Mean?. In: Sloan Management Review 26 (1984) 1, S. 25-43.

GHJV1995

Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Massachusetts 1995.

GJSB2005

Gosling, James; Joy, Bill; Steele, Guy; Bracha, Gilad: The Java Language Specification. 3. Aufl., Addison-Wesley, Boston et al. 2005.

GrGR1993

Grabowski, Jens; Graubmann, Peter; Rudolph, Ekkart: The Standardization of Message Sequence Charts. In: Software Engineering Standards Symposium. IEEE Computer Society Press, Brighton 1993, S. 48-63.

HaFR2000

Harrison, Neil; Foote, Brian; Rohnert, Hans (Hrsg.): Pattern Languages of Program Design 4. Addison-Wesley, Amsterdam 2000.

216

Literaturverzeichnis

HeHR2004

Heinrich, Lutz Jürgen; Heinzl, Armin; Roithmayr, Friedrich: Wirtschaftsinformatik-Lexikon. Oldenbourg, München et al. 2004.

Hein1993

Heinrich, Lutz Jürgen: Wirtschaftsinformatik - Einführung und Grundlegung. Oldenbourg, München et al. 1993.

HiKL1997

Hilliard II, Richard F.; Kurland, Michael J.; Litvintchouk, Steven D.: MITRE’s Architecture Quality Assessment. In: Proceedings of Software Engineering & Economics Conference, 1997, S. 1-9.

HMPR2004

Hevner, Alan R.; March, Salvatore T.; Park, Jinsoo; Ram, Sudha: Design Science in Information System Research. In: MIS Quarterly 28 (2004) 1, S. 75-105.

HoNS1995

Hofmeister, Christine; Nord, Robert; Soni, Dilip: Applied Software Architecture. Addison-Wesley, Reading et al. 1995.

HoWo2004

Hohpe, Gregor; Woolf, Bobby: Enterprise Integration Patterns. AddisonWesley, Boston et al. 2004.

ISIE1989

ISO/IEC (International Organization for Standardization/International Electrotechnical Commission): ISO/IEC 7498-2 - Information processing systems - Open Systems Interconnection - Basic Reference Model - Part 2: Security Architecture. International Standard ISO/IEC 7498-2:1989(E).

ISIE1991

ISO/IEC

(International

Organization

for

Standardization/International

Electrotechnical Commission): ISO/IEC 9126 - Information Technology Software Product Evaluation - Quality Characteristics and Guidelines for their Use. International Standard ISO/IEC 9126:1991(E). ISIE1994

ISO/IEC

(International

Organization

for

Standardization/International

Electrotechnical Commission): ISO/IEC 7498-1 - Information Technology Open Systems Interconnection - Basic Reference Model: The Basic Model. International Standard ISO/IEC 7498-1:1994(E). ISIE1995

ISO/IEC (International Organization for Standardization/International Electrotechnical Commission): ISO/IEC 12207 - Information Technology Software Life 12207:1995(E).

ISIE1999

Cycle

Processes.

International

Standard

ISO/IEC

ISO/IEC (International Organization for Standardization/International Electrotechnical Commission): ISO/IEC 14598-1 - Information Technology Software Product Evaluation - Part 1: General Overview. International Standard ISO/IEC 14598-1:1991(E).

Literaturverzeichnis

217

ISIE2001

ISO/IEC (International Organization for Standardization/International Electrotechnical Commission): ISO/IEC 9126-1 - Software engineering Product quality - Part 1: Quality model. International Standard ISO/IEC 9126-1:2001(E).

ISIE2003a

ISO/IEC (International Organization for Standardization/International Electrotechnical Commission): ISO/IEC TR 9126-2 - Software engineering Product quality - Part 2: External metrics. Technical Report ISO/IEC 91262:2003(E).

ISIE2003b

ISO/IEC (International Organization for Standardization/International Electrotechnical Commission): ISO/IEC TR 9126-3 - Software engineering Product quality - Part 3: Internal metrics. Technical Report ISO/IEC 91263:2003(E).

ISIE2004

ISO/IEC (International Organization for Standardization/International Electrotechnical Commission): ISO/IEC TR 9126-4 - Software engineering Product quality - Part 4: Quality in use metrics. Technical Report ISO/IEC 9126-4:2004(E).

ITU1991

ITU (International Telecommunication Union): Security Architecture for Open Systems Interconnection for CCITT Applications. Recommendation X.800, Genf 1991.

JCJO1992

Jacobson, Ivar; Christerson, Magnus; Jonsson, Patrik; Overgaard, Gunnar: Object-Oriented Software Engineering - A Use Case Driven Approach. Addision-Wesley, Wokingham et al. 1992.

KaAK2001

Kazman, Rick; Asundi, Jai; Klein, Mark: Quantifying the Costs and Benefits of Architectural Decisions. In: Proceedings of the 23rd International Conference on Software Engineering. IEEE Computer Society, 2001, S. 297306.

KABC1996

Kazman, Rick; Abowd, Gregory; Bass, Len; Clements, Paul: Scenario-Based Analysis of Software Architecture. In: IEEE Software 13 (1996) 6, S. 47-55.

KBAW1994

Kazman, Rick; Bass, Len; Abowd, Gregory; Webb, Mike: SAAM: A Method for Analysing the Properties of Software Architectures. In: Proceedings of the 16th International Conference on Software Engineering. IEEE Computer Society, Washington 1994, S. 81-90.

KiJa2004

Kircher, Michael; Jain, Prashant: Pattern-Oriented Software Architecture, Volume 3: Patterns for Resource Management. Wiley, Chichester 2004.

218

KKBC1999

Literaturverzeichnis

Klein, Mark; Kazman, Rick; Bass, Len; Carriere, Jeromy; Barbacci, Mario; Lipson, Howard: Attribute-based Architecture Styles. In: Donohoe, Patrick (Hrsg.): Proceedings of the TC2 First Working IFIP Conference on Software Architecture, Kluwer, B.V., Deventer 1999.

KKBL1998

Kazman, Rick; Klein, Mark; Barbacci, Mario; Longstaff, Tom; Lipson, Howard; Carriere, Jeromy: The Architecture Tradeoff Analysis Method. In: Proceedings of the 4th International Conference on Engineering of Complex Computer Systems, IEEE Computer Society, 1998, S. 68-78.

KlKa1999

Klein, Mark; Kazman, Rick: Attribute-Based Architectural Styles. Forschungsbericht CMU/SEI-99-TR-22 des Software Engineering-Instituts, Carnegie Mellon University, Pittsburgh 1999.

Krcm1990

Krcmar, Helmut: Bedeutung und Ziele von Informationssystem-Architekturen. In: Wirtschaftsinformatik 32 (1990) 5, S. 395-402.

Krcm2005

Krcmar, Helmut: Informationsmanagement. 4. Aufl., Springer, Berlin et al., 2005.

KrOS2006

Kruchten, Philippe; Obbink, Henk; Stafford, Judith: The Past, Present and Future of Software Architecture. In: IEEE Software 23 (2006) 2, S. 22 - 30.

Kruc1995

Kruchten, Philippe: Architectural Blueprints – The 4+1 View Model of Software Architecture. In: IEEE Software 12 (1995) 6, S. 42-50.

LaCh2006

Lange, Christian F. J.; Chaudron, Michel R. V.: UML Software Architecture and Design Description. In: IEEE Software 23 (2006) 2, S. 40-46.

Lamp1983

Lampson, Butler W.: Hints for Computer System Design. In: Proceedings of the 9th ACM Symposium on Operating Systems Principles, ACM Press, New York 1983, S. 33-48.

LaRV1999

Lassing, Nico; Rijsenbrij, Daan; van Vliet, Hans: On Software Architecture Analysis of Flexibility. Complexity of Changes: Size isn’t Everything. In: Proceedings of the 2nd Nordic Workshop on Software Architecture. Ronneby 1999, S. 1-6.

LBKK1997

Lung, Chung-Horng; Bot, Sonia; Kalaichelvan, Kalai; Kazman, Rick: An Approach to Software Architecture Analysis for Evolution and Reusability. In: Proceedings of the 1997 Conference of the Centre for Advanced Studies on Collaborative Research, IBM Press, 1997, S. 15-25.

MaVN2006

Manolescu, D.; Völter, M.; Noble, J. S. (Hrsg.): Pattern Languages of Program Design 5. Addison-Wesley, Reading et al. 2006.

Literaturverzeichnis

219

Mill1985

Mills, John A.: A Pragmatic View of the System Architect. In: Communications of the ACM 28 (1985) 7, S. 708-717.

Molt1999

Molter, Georg: Integrating SAAM in Domain-Centric and Reuse-based Development Processes. In: Proceedings of the 2nd Nordic Workshop on Software Architecture. Ronneby 1999, S. 1-10.

OMG2004

Object Management Group: Unified Modeling Language Specification. Version 1.4.2, formal/04-07-02. Juli 2004.

OMG2005a

Object Management Group: Unified Modeling Language: Superstructure. Version 2.0, formal/05-07-04. August 2005.

OMG2005b

Object Management Group: Unified Modeling Language: Infrastructure. Version 2.0, formal/05-07-04. März 2005.

Opdy1992

Parn1972

Opdyke, William F.: Refactoring Object-Oriented Frameworks. Dissertation, Universität Illinois, Urbana-Champaign 1992. Parnas, D. L.: On the Criteria to be used in Decomposing Systems into Modules. In: Communications of the ACM 15 (1972) 12, S. 1053 - 1058.

Parn1976

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

PaWe1985

Parnas, David; Weiss, David: Active Design Reviews: Principles and Practice. In: Proceedings of the 8th International Conference on Software Engineering. IEEE Computer Society, Washington, S. 132-136.

PeWo1992

Perry, Dewayne E.; Wolf, Alexander L.: Foundations for the Study of Software Architecture. In: ACM SIGSOFT Software Engineering Notes 17 (1992) 4, S. 40-52.

Pupp1990

Puppe, Frank: Problemlösungsmethoden in Expertensystemen. Springer, Berlin et al. 1990.

RBPE1991

Rumbaugh, James; Blaha, Michael; Premerlani, William; Eddy, Frederick; Lorenson, William: Object-Oriented Modeling and Design. Prentice Hall, New York 1991.

Risi2000

Rising, Linda: The Pattern Almanac 2000. Addison-Wesley, Amsterdam 2000.

Sche2004

Schekkerman, Jaap: How to survive in the jungle of Enterprise Architecture Frameworks: Creating or choosing an Enterprise Architecture Framework. 2. Aufl., Trafford, Victoria 2004.

220

Shaw2001

ShCl2006a

Literaturverzeichnis

Shaw, Mary: The Coming-of-Age of Software Architecture Research. In: Proceedings of the 23rd International Conference on Software Engineering. IEEE Computer Society, Washington 2001, S. 656-664. Shaw, Mary; Clements, Paul: The Golden Age of Software Architecture: A Comprehensive Survey. Forschungsbericht CMU-ISRI-06-101 des Software International Research-Institutes, Carnegie Mellon University, Pittsburgh 2006.

ShCl2006b

Shaw, Mary; Clements, Paul: The Golden Age of Software Architecture. In: IEEE Software 23 (2006) 2, S. 31-39.

ShGa1996

Shaw, Mary; Garlan, David: Software Architecture - Perspectives on an Emerging Discipline. Prentice Hall, Upper Saddle River 1996.

SoNH1995

Soni, Dilip; Nord, Robert L.; Hofmeister, Christine: Software Architecture in Industrial Applications. In: Proceedings of the 17th International Conference on Software Engineering. ACM Press, New York 1995, S. 196-207.

Somm2004

Sommerville, Ian: Software Engineering. 7. Aufl., Pearson/Addison-Wesley, Boston et al. 2004.

SoZa1992

Sowa, J. F.; Zachman, J. A.: Extending and formalizing the framework for information systems architecture. In: IBM System Journal 31 (1992) 3, S. 590-616.

SSRB2000

Schmidt, Douglas C.; Stal, Michael; Rohnert, Hans; Buschmann, Frank: Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects. Wiley, Chichester 2000.

StBV2003

Stoemer, Christoph; Bachmann, Felix; Verhoef, Chris: SACAM: The Software Architecture Comparison Analysis Method. Forschungsbericht CMU/SEI-2003-TR-006 des Software Engineering-Instituts, Carnegie Mellon University, Pittsburgh 2003.

Sun2005

Sun2006

Sun Microsystems: Enterprise JavaBeans, Version 3.0, EJB Core Contracts and Requirements. Proposed Final Draft des Specification Requests (JSR) Nr. 220. Dezember 2005. http://jcp.org/en/jsr/detail?id=220. Sun

Microsystems:

Java

Platform,

Enterprise

Edition

(Java

EE)

Specification, v5. Final Release des Java Specification Requests (JSR) Nr. 244. Mai 2006. http://jcp.org/en/jsr/detail?id=244. TEIU2005a

The Economist Intelligence Unit: Business 2010 – Embracing the challenge of change. Forschungsbericht der Economist Intelligence Unit, London 2005.

Literaturverzeichnis

221

TEIU2005b

The Economist Intelligence Unit: Business 2010 in Europe – Embracing the challenge of change. Forschungsbericht der Economist Intelligence Unit, London 2005.

Thie2005

Thiel, Steffen: A Framework to Improve the Architecture Quality of Software-Intensive Systems. Dissertation, Universität Duisburg-Essen, Essen 2005.

Tich1997

Tichy, W. F.: A Catalogue of General-Purpose Software Design Patterns. In: Proceedings of the 23rd Technology of Object-Oriented Languages and Systems Conference. IEEE Computer Society, 1997.

TMQH2003

Trowbridge, David; Mancini, Dave; Quick, Dave; Hohpe, Gregor; Newkirk, James; Lavigne, David: Enterprise Solution Patterns Using Microsoft .NET. Version 2.0, Microsoft Press, 2003.

Zach1987

Zachman, J. A.: A framework for information system architecture. In: IBM System Journal 26 (1987) 3, S. 454-470.

Zele2007

Zelewski, Stephan: Kann Wissenschaftstheorie behilflich für die Publikationspraxis sein? Eine kritische Auseinandersetzung mit den „Guidelines“ von HEVNER et al. In: Lehner, F., Zelewski, St. (Hrsg.): Wissenschaftstheoretische Fundierung und wissenschaftliche Orientierung der Wirtschaftsinformatik. GITO-Verlag, Berlin 2007, S. 72-121.

ZhAJ2004

Zhu, Liming; Ali Babar, Muhammad; Jeffery, Ross: Mining Patterns to Support Software Architecture Evaluation. In: Proceeding of the 4th Working IEEE/IFIP Conference on Software Architecture. IEEE Computer Society, 2004, S. 25-36.

Zimm1995

Zimmer, Walter: Relationships between Design Patterns. In: Coplien, James O.; Schmidt, Douglas C. (Hrsg.): Pattern Languages of Program Design. Addison-Wesley, Reading et al. 1995, S. 345-364.

Zuse1999

Zuse, Horst: Thirty Years of Software Measurement. In: Dumke, Reiner; Abran, Alain (Hrsg.): Software Measurement - Current Trends in Research and Practice. Deutscher Universitäts-Verlag, Wiesbaden 1999.

Anhang A Im Folgenden wird die vollständige erweiterte Backus-Naur-Form, die die Syntax für Vorspalten und Tabellenfelder des Wissensmodells definiert, dokumentiert. Zur Definition wird aufgrund der weiten Verbreitung die Metasyntax verwendet, die bei der Definition der Extensible Markup Language verwendet wird (siehe [BPSM2004]).

/*---------------------------------------------------------------------*/ /* Symbols for the first columns of the table */ /*---------------------------------------------------------------------*/ /*---------------------------------------------------------------------*/ /* Column: Pattern Name */ PatternName ::= Name /* The name used in the pattern catalog */

/*---------------------------------------------------------------------*/ /* Column: Source */ Source

::= ShortTermOfSource YearOfPublication " (" PageNumber ")"

ShortTermOfSource ::= OneAuthor | TwoAuthors | ThreeAutors | FourAuthors | MoreThanFourAuthors OneAuthor

::= LetterOfAuthor LetterOfAuthor LetterOfAuthor LetterOfAuthor /* First four letters of the author’s surname */

TwoAuthors

::= LetterOfAuthor LetterOfAuthor LetterOfAuthor LetterOfAuthor /* First two letters of each author’s surname */

ThreeAutors ::= LetterOfAuthor LetterOfAuthor LetterOfAuthor LetterOfAuthor /* The first two letters of first author’s surname and and first letter of the other two authors */ FourAuthors ::= LetterOfAuthor LetterOfAuthor LetterOfAuthor LetterOfAuthor /* The first letter of the surname for each author */ MoreThanFourAuthors ::= LetterOfAuthor LetterOfAuthor LetterOfAuthor LetterOfAuthor /* The first letter of the surname for the first four authors */ LetterOfAuthor ::= [a-zA-Z]

/*---------------------------------------------------------------------*/ /* Column: Pattern Type */

224

Anhang A

PatternType ::= "Architectural" PageReferences | "-" /* A simple dash means that there is no explicit classification in the pattern catalog */

/*---------------------------------------------------------------------*/ /* Column: Context Context

::= ContextDescription PageReferences SectionReferences

ContextDescription ::= Description

/*---------------------------------------------------------------------*/ /* Column: Stimulated Artifact */ SimulatedArtifact

::= SimulatedArtifactDescription PageReferences SectionReferences

SimulatedArtifactDescription ::= Description

/*---------------------------------------------------------------------*/ /* Column: Supported General Scenarios */ SupportedGeneralScenarios ::= SupportedGeneralScenario* SupportedGeneralScenario

::= " - " SupportedGeneralScenarioDescription PageReferences SectionReferences

SupportedGeneralScenarioDescription ::= Description

/*---------------------------------------------------------------------*/ /* Column: Relationships */ Relationships

::=

Relationship*

Relationship

::= " - " RelationshipType " (" Cardinality "): " PatternName PageReferences SectionReferences

RelationshipType ::= "uses" | "is used by" | "generalises" | "specialises" | "is alternative to" Cardinality

::= "optional" | "required"

/*---------------------------------------------------------------------*/ /* Symbols for documention the effect on quality characteristics */ /*---------------------------------------------------------------------*/ /*---------------------------------------------------------------------*/ /* Effect on quality characteristic */ EffectOnQualityCharacteristic ::= ( ( ( (

PositiveResponse )* Sensitivitypoint )* Tradeoffpoint )* NegativeResponse )*

Anhang A

225

/*---------------------------------------------------------------------*/ /* Positive response on characteristic */ PositiveResponse

::= " - Positive response: " PositiveResponseDescription PageReferences SectionReferences

PositiveResponseDescription ::= Description /* A brief description of the positive response with regard to the quality characteristic */

/*---------------------------------------------------------------------*/ /* Sensitivity Point */ SensitivityPoint

::= " - Sensitivity point: " SensitivityPointDescription ImpactOfProperty PageReferences SectionReferences

SensitivityPointDescription ::= Description

/*---------------------------------------------------------------------*/ /* Tradeoff Point */ TradeoffPoint

::= " - Tradeoff point: " TradeoffPointDescription ImpactOfProperty PageReferences SectionReferences OtherAffectedCharacteristicsReference

TradeoffPointDescription

::= Description

OtherAffectedCharacteristicsReference ::= " (" Characteristic (", " Characteristic)* ")" Characteristic

::= FirstLevelCharacteristic | SecondLevelCharacteristic | ThirdLevelCharacteristic

FirstLevelCharacteristic

::= "Reliability" | "Usability" | "Efficiency" | "Modifibility" | "Security"

SecondLevelCharacteristic

::= "Maturity" | "Fault tolerance" | "Recoverability" | "Understandability" | "Learnability" | "Operability" | "Attractiveness" | "Time behaviour" | "Resource utilization" | "Analyzability" | "Changeability" | "Stability" | "Testability" | "Portability" | "Variability" | "Authentication" | "Access control" | "Data confidentiality" | "Data integrity" | "Non-repudiation" | "Availability" | "Auditing"

ThirdLevelCharacteristic

::= "Adaptability" | "Installability" | "Co-existance" | "Replaceability" | "Subsetability"

226

Anhang A

/*---------------------------------------------------------------------*/ /* Impact of Sensitivity and Tradeoff Points */ ImpactOfProperty

::= " [" ConsistentImpact | ValueBasedImpact "]"

ConsistentImpact

::= Impact

ValueBasedImpact

::= PropertyAndImpact (", " PropertyAndImpact)+

PropertyAndImpact

::= DescriptionOfProperty " (" Impact ")"

DescriptionOfProperty

::= Description

Impact

::= "+" | "-"

/*---------------------------------------------------------------------*/ /* Negative response on characteristic */ NegativeResponse

::= " - Negative response: " NegativeResponseDescription PageReferences SectionReferences

NegativeResponseDescription ::= Description

/*---------------------------------------------------------------------*/ /* General expressions and symbols */ /*---------------------------------------------------------------------*/ PageReferences

::= " (" PageNumber("," PageNumber)* ")" /* A list of page numbers referencing an item */

SectionReferences

::= " [" SectionName("," SectionName)* "]" /* A list of section names referencing an item */

SectionName

::= Name /* Section name of the relevant pattern documentation template */

Name

::= (Letter)+ (Letter | "/" | "-" | WhiteSpace)+

Description

::= (Letter)+ (Letter | "/" | "." | WhiteSpace)+

WhiteSpace

::= (#x20 | #x9 | #xD | #xA)+ /* White space consists of one or more space characters, carriage returns, line feeds, or tabs. */

PageNumber

::= Number+

Letter

::= [a-zA-Z]

Number

::= [0-9]

Anhang B Die Wissensbasis ist aufgrund ihres Umfangs nicht Bestandteil des vorliegenden Buchs. Eine vollständige, digitale Version ist allerdings unter der folgenden Web-Adresse frei verfügbar: http://www.architecturalpatterns.com/knowledgebase.