im internet: starke gernot effektive software
TRANSCRIPT
EFFEKTIVE SOFTWARE
ARCHITEKTUREN
STA
RK
E
PRAXISLEITFADEN FÜR SOFTWARE-ARCHITEKTEN //
■ Aktueller Überblick über die wesentlichen Aspekte von Software-Architekturen
■ Direkt umsetzbare Tipps für praktizierende Software-Architekten
■ Neu in der vierten Auflage: arc42, ausführliche Beispielarchitekturen und der
Lehrplan des ISAQB
■ Im Internet: Hintergrundinformationen, Ergänzungen, Beispiele, Checklisten
EFFEKTIVE SOFTWARE-ARCHITEKTUREN // Software-Architekten müssen
komplexe fachliche und technische Anforderungen an IT-Systeme umsetzen und
diese Systeme durch nachvollziehbare Strukturen flexibel und erweiterbar gestalten.
Dieser Praxisleitfaden zeigt Ihnen, wie Sie Software-Architekturen effektiv und
systematisch entwickeln können. Der bekannte Software-Architekt Gernot Starke
unterstützt Sie mit praktischen Tipps, Architekturmustern und seinen Erfahrungen.
Er gibt Antworten auf zentrale Fragen:
■ Welche Aufgaben haben Software-Architekten?
■ Wie gehen Software-Architekten beim Entwurf vor?
■ Wie kommunizieren und dokumentieren Sie Software-Architekturen?
■ Wie helfen Architekturmuster und Architekturbausteine?
■ Wie bewerten Sie Software-Architekturen?
■ Wie behandeln Sie Persistenz, grafische Benutzeroberflächen, Geschäftsregeln,
Integration, Verteilung, Sicherheit, Fehlerbehandlung, Workflow-Management
und sonstige technische Konzepte?
■ Was müssen Software-Architekten über MDA/MDSD, UML 2, arc42 und SOA
wissen?
■ Welche Aufgaben nehmen Enterprise-IT-Architekten wahr?
Dr. Gernot STARKE stellt sich vielen Jahren der Herausforderung,
die Architektur großer Systeme effektiv zu gestalten. Zu seinen
Kunden zählen mittlere und große Unternehmen aus den Branchen
Finanz dienstleistung, Logistik, Handel, Telekom munikation und dem
öffent lichen Bereich.
www.hanser.de/computer
Software-Architekten und Software -
entwickler, Projektleiter und Entwicklungs -
leiter, IT-Manager, Qualitätssicherer
ISBN 978-3-446-42008-3
9 783446 420083
EIN PRAKTISCHER LEITFADEN
gernot STARKE
4. Auflage
// Was Sie schon immer über Software-Architektur wissen wollten, finden Sie im neuen
Buch 'Effektive Software-Architekturen' von Gernot Starke. // OBJEKTSpektrum
EF
FE
KT
IVE
SO
FT
WA
RE
-A
RC
HIT
EK
TU
RE
N
Sys
tem
vora
usse
tzun
gen
für
eBoo
k-in
sid
e: In
tern
et-V
erb
ind
ung,
Ad
obe
Acr
obat
Rea
der
Ver
sion
6 o
der
7 (k
omp
atib
el m
it W
ind
ows
ab W
ind
ows
2000
od
er M
ac O
S X
). A
b A
dob
e R
ead
er 8
mus
s zu
sätz
lich
der
eB
ookr
ead
er A
dob
e D
igita
l Ed
ition
s in
stal
liert
sei
n.
V
Inhalt
Vorwort ...........................................................................................................................................XI Vorwort zur vierten Auflage ........................................................................................... XII
1 Einleitung .......................................................................................................................... 1 1.1 Software-Architekten..............................................................................................6 1.2 Effektiv, agil und pragmatisch................................................................................6 1.3 Wer sollte dieses Buch lesen?.................................................................................9 1.4 Wegweiser durch das Buch...................................................................................10 1.5 Webseite zum Buch ..............................................................................................12 1.6 Weiterführende Literatur ......................................................................................12 1.7 Danksagung ..........................................................................................................13
2 Architektur und Architekten .....................................................................................15 2.1 Was ist Architektur? .............................................................................................16 2.2 Die Aufgaben von Software-Architekten..............................................................21 2.3 Wie entstehen Architekturen?...............................................................................28 2.4 In welchem Kontext steht Architektur? ................................................................30 2.5 Weiterführende Literatur ......................................................................................34
3 Vorgehen bei der Architekturentwicklung...........................................................35 3.1 Informationen sammeln ........................................................................................39 3.2 Systemidee entwickeln .........................................................................................39 3.3 Was sind Einflussfaktoren und Randbedingungen?..............................................46 3.4 Einflussfaktoren finden.........................................................................................50 3.5 Risiken identifizieren............................................................................................56 3.6 Qualität explizit beschreiben.................................................................................59
3.6.1 Qualitätsmerkmale von Software-Systemen ...........................................60 3.6.2 Szenarien konkretisieren Qualität ...........................................................62
3.7 Lösungsstrategien entwickeln...............................................................................68 3.7.1 Strategien gegen organisatorische Risiken..............................................69 3.7.2 Strategien für hohe Performance.............................................................70
Inhalt
VI
3.7.3 Strategien für Anpassbarkeit und Flexibilität ..........................................72 3.7.4 Strategien für hohe Verfügbarkeit ...........................................................74
3.8 Weiterführende Literatur.......................................................................................75
4 Architektursichten zur Kommunikation und Dokumentation .......................77 4.1 Architekten müssen kommunizieren und dokumentieren .....................................78 4.2 Sichten ..................................................................................................................80
4.2.1 Sichten in der Software-Architektur........................................................81 4.2.2 Vier Arten von Sichten............................................................................82 4.2.3 Entwurf der Sichten.................................................................................85
4.3 Kontextabgrenzung ...............................................................................................87 4.3.1 Elemente der Kontextabgrenzung ...........................................................87 4.3.2 Notation der Kontextabgrenzung ............................................................87 4.3.3 Entwurf der Kontextabgrenzung .............................................................88
4.4 Bausteinsicht.........................................................................................................89 4.4.1 Elemente der Bausteinsicht .....................................................................92 4.4.2 Notation der Bausteinsicht ......................................................................95 4.4.3 Entwurf der Bausteinsicht .......................................................................95
4.5 Laufzeitsicht .........................................................................................................96 4.5.1 Elemente der Laufzeitsicht......................................................................97 4.5.2 Notation der Laufzeitsicht .......................................................................98 4.5.3 Entwurf der Laufzeitsicht........................................................................99
4.6 Verteilungssicht ....................................................................................................99 4.6.1 Elemente der Verteilungssicht...............................................................100 4.6.2 Notation der Verteilungssicht................................................................100 4.6.3 Entwurf der Verteilungssicht.................................................................101
4.7 Dokumentation von Schnittstellen ......................................................................102 4.8 Datensicht ...........................................................................................................105 4.9 Typische Architekturdokumente.........................................................................107
4.9.1 Zentrale Architekturbeschreibung .........................................................108 4.9.2 Architekturüberblick .............................................................................111 4.9.3 Dokumentationsübersicht......................................................................111 4.9.4 Übersichtspräsentation der Architektur .................................................112 4.9.5 Architekturtapete...................................................................................112
4.10 Effektive Architekturdokumentation...................................................................113 4.10.1 Anforderungen an Architekturdokumentation.......................................113 4.10.2 Regeln für gute Architekturdokumentation ...........................................115
4.11 Andere Ansätze zur Architekturdokumentation..................................................118 4.11.1 TOGAF .................................................................................................118 4.11.2 xADL (Extendable Architecture Description Language) ......................120
4.12 Weiterführende Literatur.....................................................................................120
5 UML 2 für Architekten.............................................................................................. 123 5.1 Die Diagrammarten der UML 2..........................................................................125 5.2 Die Bausteine von Architekturen ........................................................................127 5.3 Schnittstellen.......................................................................................................128
Inhalt
VII
5.4 Die Bausteinsicht ................................................................................................129 5.5 Die Verteilungssicht ...........................................................................................132 5.6 Die Laufzeitsicht.................................................................................................134 5.7 Darum UML .......................................................................................................139 5.8 Weiterführende Literatur ....................................................................................140
6 Strukturentwurf, Architektur- und Designmuster........................................... 141 6.1 Von der Idee zur Struktur ...................................................................................143
6.1.1 Komplexität beherrschen ......................................................................143 6.1.2 Zerlegen – aber wie? .............................................................................144 6.1.3 Fachmodelle als Basis der Entwürfe .....................................................145 6.1.4 Die Fachdomäne strukturieren ..............................................................148
6.2 Architekturmuster ...............................................................................................149 6.2.1 Schichten (Layer)..................................................................................149 6.2.2 Pipes & Filter ........................................................................................153 6.2.3 Weitere Architekturmuster....................................................................155
6.3 Heuristiken zum Entwurf....................................................................................157 6.3.1 Das So-einfach-wie-möglich-Prinzip ....................................................157 6.3.2 Entwerfen Sie nach Verantwortlichkeiten.............................................159 6.3.3 Konzentrieren Sie sich auf Schnittstellen..............................................160 6.3.4 Berücksichtigen Sie Fehler ...................................................................160
6.4 Optimieren von Abhängigkeiten.........................................................................161 6.4.1 Streben Sie nach loser Kopplung ..........................................................164 6.4.2 Hohe Kohäsion......................................................................................164 6.4.3 Offen für Erweiterungen, geschlossen für Änderungen .......................164 6.4.4 Abhängigkeit nur von Abstraktionen ....................................................166 6.4.5 Abtrennung von Schnittstellen ..............................................................167 6.4.6 Zyklische Abhängigkeiten vermeiden...................................................169 6.4.7 Liskov-Substitutionsprinzip (LSP)........................................................170 6.4.8 Dependency Injection (DI)....................................................................172
6.5 Entwurfsmuster...................................................................................................173 6.5.1 Entwurf mit Mustern.............................................................................174 6.5.2 Adapter .................................................................................................174 6.5.3 Beobachter (Observer) ..........................................................................175 6.5.4 Dekorierer (Decorator)..........................................................................177 6.5.5 Stellvertreter (Proxy).............................................................................177 6.5.6 Fassade..................................................................................................178 6.5.7 Zustand (State) ......................................................................................179
6.6 Entwurf, Test, Qualitätssicherung.......................................................................180 6.7 Weiterführende Literatur ....................................................................................181
7 Technische Konzepte und typische Architekturaspekte ............................. 185 7.1 Persistenz............................................................................................................189
7.1.1 Motivation.............................................................................................189 7.1.2 Typische Probleme................................................................................190 7.1.3 Architekturmuster „Persistenzschicht“..................................................193
Inhalt
VIII
7.1.4 Weitere Themen zu Persistenz ..............................................................202 7.1.5 Zusammenhang mit anderen Aspekten..................................................207 7.1.6 Weiterführende Literatur.......................................................................209
7.2 Geschäftsregeln...................................................................................................209 7.2.1 Motivation.............................................................................................209 7.2.2 Funktionsweise von Regelmaschinen....................................................213 7.2.3 Kriterien pro & kontra Regelmaschinen................................................215 7.2.4 Mögliche Probleme ...............................................................................216 7.2.5 Weiterführende Literatur.......................................................................216
7.3 Integration...........................................................................................................217 7.3.1 Motivation.............................................................................................217 7.3.2 Typische Probleme................................................................................218 7.3.3 Lösungskonzepte...................................................................................220 7.3.4 Entwurfsmuster zur Integration.............................................................225 7.3.5 Konsequenzen und Risiken ...................................................................227 7.3.6 Zusammenhang mit anderen Aspekten..................................................229 7.3.7 Weiterführende Literatur.......................................................................230
7.4 Verteilung ...........................................................................................................231 7.4.1 Motivation.............................................................................................231 7.4.2 Typische Probleme................................................................................231 7.4.3 Lösungskonzept.....................................................................................232 7.4.4 Konsequenzen und Risiken ...................................................................234 7.4.5 Zusammenhang mit anderen Aspekten..................................................234 7.4.6 Weiterführende Literatur.......................................................................235
7.5 Kommunikation ..................................................................................................235 7.5.1 Motivation.............................................................................................235 7.5.2 Entscheidungsalternativen.....................................................................235 7.5.3 Grundbegriffe der Kommunikation .......................................................236 7.5.4 Weiterführende Literatur.......................................................................242
7.6 Ablaufsteuerung grafischer Oberflächen.............................................................242 7.6.1 Model-View-Controller (MVC) ............................................................246 7.6.2 Weiterführende Literatur.......................................................................252
7.7 Ergonomie grafischer Oberflächen .....................................................................253 7.7.1 Arbeitsmetaphern ..................................................................................253 7.7.2 Interaktionsstile .....................................................................................255 7.7.3 Ergonomische Gestaltung......................................................................259 7.7.4 Heuristiken zur GUI-Gestaltung............................................................261 7.7.5 Weiterführende Literatur.......................................................................264
7.8 Internationalisierung ...........................................................................................265 7.8.1 Globale Märkte erfordern neue Prozesse...............................................266 7.8.2 Dimensionen der Internationalisierung .................................................266 7.8.3 Lösungskonzepte...................................................................................267 7.8.4 Weiterführende Literatur.......................................................................274
7.9 Workflow-Management: Ablaufsteuerung im Großen........................................274 7.9.1 Zweck der Ablaufsteuerung ..................................................................275 7.9.2 Lösungsansätze .....................................................................................277
Inhalt
IX
7.9.3 Integration von Workflow-Systemen ....................................................280 7.9.4 Mächtigkeit von WMS..........................................................................282 7.9.5 Weiterführende Literatur.......................................................................283
7.10 Sicherheit ............................................................................................................284 7.10.1 Motivation.............................................................................................284 7.10.2 Typische Probleme................................................................................284 7.10.3 Sicherheitsziele .....................................................................................285 7.10.4 Lösungskonzepte...................................................................................287 7.10.5 Zusammenhang mit anderen Aspekten .................................................292 7.10.6 Weiterführende Literatur.......................................................................294
7.11 Protokollierung ...................................................................................................294 7.11.1 Typische Probleme................................................................................295 7.11.2 Lösungskonzept ....................................................................................296 7.11.3 Zusammenhang mit anderen Aspekten .................................................296 7.11.4 Weiterführende Literatur.......................................................................297
7.12 Ausnahme- und Fehlerbehandlung .....................................................................297 7.12.1 Motivation.............................................................................................297 7.12.2 Fehlerkategorien schaffen Klarheit .......................................................300 7.12.3 Muster zur Fehlerbehandlung................................................................302 7.12.4 Mögliche Probleme ...............................................................................303 7.12.5 Zusammenhang mit anderen Aspekten .................................................304 7.12.6 Weiterführende Literatur.......................................................................305
8 Model Driven Architecture (MDA)........................................................................ 307 8.1 Architekten entwickeln Generierungsvorlagen...................................................310 8.2 Modellierung ......................................................................................................311 8.3 Modellbasiert entwickeln....................................................................................313 8.4 Weiterführende Literatur ....................................................................................314
9 Bewertung von Software-Architekturen............................................................ 315 9.1 Was Sie an Architekturen bewerten können .......................................................319 9.2 Vorgehen bei der Bewertung ..............................................................................321 9.3 Weiterführende Literatur ....................................................................................327
10 Service-Orientierte Architektur (SOA) ............................................................... 329 10.1 Was ist SOA?......................................................................................................330 10.2 So funktionieren Services ...................................................................................336 10.3 Was gehört (noch) zu SOA? ...............................................................................337 10.4 SOA und Software-Architektur ..........................................................................339 10.5 Weiterführende Literatur ....................................................................................340
11 Enterprise-IT-Architektur........................................................................................ 341 11.1 Wozu Architekturebenen? ..................................................................................343 11.2 Aufgaben von Enterprise-Architekten ................................................................344
11.2.1 Management der Infrastrukturkosten ....................................................344 11.2.2 Management des IS-Portfolios ..............................................................344
Inhalt
X
11.2.3 Definition von Referenzarchitekturen ...................................................346 11.2.4 Weitere Aufgaben .................................................................................348
11.3 Weiterführende Literatur.....................................................................................350
12 Beispiele von Software-Architekturen ............................................................... 351 12.1 Beispiel: Datenmigration im Finanzwesen..........................................................352
1 Einführung und Ziele................................................................................................. 352 1.1 Fachliche Aufgabenstellung ...................................................................354 1.2 Architekturziele ......................................................................................354 1.3 Stakeholder.............................................................................................354 2 Einflussfaktoren und Randbedingungen ............................................................ 355 2.1 Technische Einflussfaktoren und Randbedingungen ..............................355 2.2 Organisatorische Einflussfaktoren..........................................................356 2.3 Konventionen .........................................................................................356
3 Kontextabgrenzung ................................................................................................... 356
4 Bausteinsicht............................................................................................................... 358 4.1 M&M Bausteinsicht Level 1 ..................................................................358 4.1.1 Migration Controller...............................................................................359 4.1.2 VSAM Reader ........................................................................................359 4.1.3 Segmentizer ............................................................................................360 4.1.4 Migrationsdatenbank ..............................................................................360 4.1.5 Packager .................................................................................................360 4.1.6 Rule Processor (und Packager) ...............................................................361 4.1.7 Target System-Adapter...........................................................................361 4.1.8 Migrierte Kontodaten in Zieldatenbank..................................................361 4.2 Bausteinsicht Level 2 .............................................................................362 4.2.1 VSAM-Reader Whitebox .......................................................................362 4.2.2 Rule Processor Whitebox .......................................................................363
5 Laufzeitsicht................................................................................................................. 365
6 Verteilungssicht.......................................................................................................... 366
7 Typische Strukturen und Muster ........................................................................... 367
8 Technische Konzepte................................................................................................ 367 8.1 Persistenz................................................................................................367 8.2 Ablaufsteuerung .....................................................................................367 8.3 Ausnahme- und Fehlerbehandlung .........................................................367 8.4 Transaktionsbehandlung.........................................................................368 8.5 Geschäftsregel und Validierung .............................................................368 8.6 Kommunikation und Integration.............................................................368
9 Entwurfsentscheidungen ......................................................................................... 368
10 Szenarien zur Architekturbewertung................................................................. 369
11 Projektaspekte.......................................................................................................... 369
12 Glossar und Referenzen ........................................................................................ 370
Inhalt
XI
12.2 Beispiel: Kampagnenmanagement im CRM.......................................................371 1 Einführung und Ziele..................................................................................................371 1.1 Fachliche Aufgabenstellung ...................................................................372 1.1.1 Einsatz von MaMa für Vertrags- und Tarifänderungen bei
Telekommunikationsunternehmen .........................................................372 1.1.2 Konfiguration einer Kampagne ..............................................................374 1.2 Architekturziele......................................................................................376 1.3 Stakeholder.............................................................................................377
2 Einflussfaktoren und Randbedingungen .............................................................377 2.1 Technische Einflussfaktoren ..................................................................377 2.2 Organisatorische Einflussfaktoren..........................................................378
3 Kontextabgrenzung....................................................................................................378 3.1 Allgemeiner fachlicher (logischer) Kontext ...........................................378 3.2 Spezielle Kontextabgrenzung der Mobilfunk-Kampagne.......................379 3.3 Verteilungskontext: MaMa als Basis einer Produktfamilie ....................379
4 Bausteinsicht................................................................................................................380 4.1 MaMa-Bausteinsicht Level 1 .................................................................380 4.1.1 Input .......................................................................................................381 4.1.2 Campaign Process Control .....................................................................382 4.1.3 Campaign Data Management .................................................................382 4.1.4 Configuration .........................................................................................383 4.1.5 Output ....................................................................................................383 4.1.6 Reporting sowie Operations Monitoring ................................................383 4.2 MaMa-Bausteinsicht Level 2 .................................................................384 4.2.1 Whiteboxsicht Baustein „Input“, Level 2...............................................384 4.2.2 Whitebox Campaign Process Control, Level 2.......................................387 4.3 MaMa Bausteinsicht Level 3..................................................................388 4.3.1 Whiteboxsicht Baustein „Receiver“, Level 3 .........................................388
5 Laufzeitsicht .................................................................................................................390 5.1 Szenario: Schematischer Input von Daten..............................................390 5.2 Szenario: Import einer CSV-Datei .........................................................391
6 Verteilungssicht...........................................................................................................392
7 Typische Strukturen und Muster............................................................................392
8 Technische Konzepte.................................................................................................392 8.1 Ablaufsteuerung .....................................................................................392 8.2 Produktfamilie, Persistenz und Generierung ..........................................396 8.3 Geschäftsregeln ......................................................................................397 8.3 Ausnahme- und Fehlerbehandlung.........................................................398
9 Entwurfsentscheidungen..........................................................................................398 9.1 Kein CRM-Werkzeug ............................................................................398 9.2 Kein ETL-Werkzeug ..............................................................................398
10 Szenarien zur Architekturbewertung..................................................................399
11 Projektaspekte ..........................................................................................................399 11.1 Risiken und offene Punkte .....................................................................399
Inhalt
XII
12 Glossar und Referenzen ........................................................................................ 400 Referenzen ..........................................................................................................400
13 iSAQB Curriculum..................................................................................................... 403 13.1 Standardisierter Lehrplan für Software-Architekten ...........................................404 13.2 Können, Wissen und Verstehen ..........................................................................405 13.3 Voraussetzungen und Abgrenzungen..................................................................406 13.4 Struktur des iSAQB-Lehrplans ...........................................................................406
I. Grundbegriffe von Software-Architekturen.................................................407 II. Beschreibung und Kommunikation von Software-Architekturen ................408 III. Entwicklung von Software-Architekturen ...................................................409 IV. Software-Architekturen und Qualität...........................................................410 V. Werkzeuge für Software-Architekten ..........................................................411 VI. Beispiele von Software-Achitekturen ..........................................................412
13.5 Zertifizierung nach dem iSAQB-Lehrplan..........................................................412
14 Nachwort: Architektonien....................................................................................... 413 14.1 In sechs Stationen um die (IT-)Welt ...................................................................413 14.2 Ratschläge aus dem architektonischen Manifest .................................................417
15 Literatur ........................................................................................................................ 423
Register ...................................................................................................................................... 431
1
1 1 Einleitung
Wir bauen Software wie Kathedralen: zuerst bauen wir –
dann beten wir.
Gerhard Chroust
Bitte erlauben Sie mir, Sie mit einer etwas bösartigen kleinen Geschichte zur weiteren Lektüre dieses Buches zu motivieren. Eine erfolgreiche Unternehmerin möchte sich ein Domizil errichten lassen. Enge Freunde raten ihr, ein Architekturbüro mit dem Entwurf zu betrauen und die Er-stellung begleiten zu lassen. Nur so ließen sich die legendären Probleme beim Hausbau (ungeeignete Entwürfe, mangelnde Koordination, schlechte Ausfüh-rung, Pfusch bei Details, Kostenexplosion und Terminüberschreitung) vermeiden. Um die für ihr Vorhaben geeigneten Architekten zu finden, beschließt sie, eini-gen namhaften Büros kleinere Testaufträge für Einfamilienhäuser zu erteilen. Natürlich verrät sie keinem der Kandidaten, dass diese Aufträge eigentlich Tests für das endgültige Unterfangen sind. Nach einer entsprechenden Ausschreibung in einigen überregionalen Tageszei-tungen trifft unsere Bauherrin folgende Vorauswahl: Wasserfall-Architektur KG, Spezialisten für Gebäude und Unterfangen aller
Art. V&V Architektur GmbH & Co. KG, Spezialisten für Regierungs-, Prunk-
und Profanbauten. Extremarchitekten AG
Alle Büros erhalten identische Vorgaben: Ihre Aufgabe besteht in Entwurf und Erstellung eines Einfamilienhauses (EFH). Weil unsere Unternehmerin jedoch sehr häufig, manchmal fast sprunghaft, ihre Wünsche und Anforderungen ändert, beschließt sie, die Flexibilität der Kandidaten auch in dieser Hinsicht zu testen.
1 Einleitung
2
Foto von Wolfgang Korn
Wasserfall-Architektur KG Die Firma residiert im 35. Stock eines noblen Bürogebäudes. Dicke Teppiche und holzvertäfelte Wände zeugen vom veritablen Wohlstand der Firmeneigner.
„Wir entwerfen auch komplexe technische Systeme“, er-klärt ein graumelierter Mittfünfziger der Bauherrin bei ih-rem ersten Treffen. Sein Titel „Bürovorsteher“ prädestiniert ihn wohl für den Erstkontakt zu dem vermeintlich kleinen Fisch. Von ihm und einer deutlich jüngeren Assistentin wurde sie ausgiebig nach ihren Wünschen hinsichtlich des geplanten Hauses befragt. Als sie die Frage nach den Türgriffen des Badezimmer-schrankes im Obergeschoss nicht spontan beantworten kann, händigt man ihr ein Formblatt aus, das ausführlich ein Change-Management-Verfahren beschreibt. Das Team der Wasserfall-Architektur KG legte nach weni-gen Wochen einen überaus detaillierten Projektplan vor. Gantt-Charts, Work-Breakdown-Struktur, Meilensteine, alles dabei. Die nächsten Monate verbrachte das Team mit der Dokumentation der Anforderungsanalyse sowie dem Ent-wurf. Pünktlich zum Ende dieser Phase erhielt die Unternehmerin einen Ordner (zweifach) mit fast 400 Seiten Beschreibung eines Hauses. Nicht ganz das von ihr Gewünschte, weil das
Entwicklungsteam aus Effizienzgründen und um Zeit zu sparen einige (der Bau-herrin nur wenig zusagende) Annahmen über die Größe mancher Räume und die Farbe einiger Tapeten getroffen hatte. Man habe zwar überall groben Sand als Bodenbelag geplant, könne das aber später erweitern. Mit etwas Zement und Wasser vermischt stünden den Hausbewohnern später alle Möglichkeiten offen. Im Rahmen der hierbei erwarteten Änderungen habe das Team vorsorglich die Treppen als Rampe ohne Stufen geplant, um Arbeitern mit Schubkarren den Weg in die oberen Etagen zu erleichtern. Das Begehren unserer Unternehmerin, doch eine normale Treppe einzubauen, wurde dem Change-Management über-geben. Die nun folgende Erstellungsphase (die Firma verwendete hierfür den Begriff „Implementierungsphase“) beendete das Team in 13 statt der geplanten 8 Mona-te. Die fünf Monate Zeitverzug seien durch widrige Umstände hervorgerufen, wie ein Firmensprecher auf Nachfrage erklärte. In Wirklichkeit hatte ein Junior-Planning-Consultant es versäumt, einen Zufahrtsweg für Baufahrzeuge zu planen – das bereits fertiggestellte Gartenhaus musste wieder abgerissen werden, um eine passende Baustraße anlegen zu können.
1.1 Software-Architekten
3
Foto von Ralf Harder
Ansonsten hatte das Implementierungsteam einige kleine Schwächen des Ent-wurfs optimiert. So hatte das Haus statt Treppe nun einen Lastenaufzug, weil sich die ursprünglich geplante Rampe für Schubkarren als zu steil erwies. Das Change-Management verkündete stolz, man habe bereits erste Schritte zur An-passung des Sandbodens unternommen: Im ganzen Haus seien auf den Sand Teppiche gelegt worden. Leider hatte ein Mitglied des Wartungsteams über den Teppich dann, in sklavischer Befolgung der Planungsvorgaben, Zement und Wasser aufgebracht und mit Hilfe ausgeklügelt brachialer Methoden zu einer rot-grauen zähen Paste vermischt. Man werde sich in der Wartungsphase darum kümmern, hieß es seitens der Firma. Die zu diesem Zeitpunkt von den Wasserfall-Architekten ausgestellte Vorab-rechnung belief sich auf das Doppelte der ursprünglich angebotenen Bausumme. Diese Kostensteigerung habe die Bauherrin durch ihre verspätet artikulierten Zu-satzwünsche ausschließlich selbst zu verantworten.
V&V Architektur GmbH & Co. KG Die V&V Architektur GmbH & Co. KG (nachfolgend kurz V&V) hatte sich in den vergangenen Jahren auf Regierungs-, Prunk- und Profanbauten spezialisiert. Mit dem unternehmenseigenen Verfahren, so wird versichert, könne man garan-tiert jedes Projekt abwickeln. Der von V&V ernannte Projektleiter überraschte unsere Unternehmerin in den ersten Projektwochen mit langen Fragebögen – oh-ne jeglichen Bezug zum geplanten Haus. Man müsse unbedingt zuerst das Tailo-ring des Vorgehensmodells durchführen, das Modell exakt dem geplanten Pro-jekt anpassen. Am Ende dieser Phase erhielt sie, in zweifacher Ausfertigung, mehrere Hundert Seiten Dokumentation des geplanten Vorgehens. Dass ihr Einfamilienhaus darin nicht erwähnt wurde, sei völlig normal, unterrichtete sie der Pro-jektleiter. Erst jetzt, in der zwei-ten Phase, würde das konkrete Objekt geplant, spezifiziert, rea-lisiert, qualitätsgesichert und kon-figurationsverwaltet. Der Auftraggeberin wurde zu diesem Zeitpunkt auch das „Di-rektorat EDV“ der Firma V&V vorgestellt. Nein, diese Abteilung befasste sich nicht mit Datenverarbeitung – die Abkürzung stand für „Einhaltung Des Vor-gehensmodells“. Nach einigen Monaten Projektlaufzeit stellte unsere Bauherrin im bereits teilwei-se fertiggestellten Haus störende signalrote Inschriften auf sämtlichen verbauten Teilen fest. Das sei urkundenechte Spezialtinte, die sich garantiert nicht durch
1 Einleitung
4
„Gummibär-Tango“ von Klaus Terjung
Farbe oder Tapete verdecken ließe, erklärte V&V stolz. Für die Qualitätssiche-rung und das Konfigurationsmanagement seien diese Kennzeichen unbedingt notwendig. Ästhetische Einwände, solche auffälligen Markierungen nicht in Au-genhöhe auf Fenster, Türen und Wänden anzubringen, verwarf die Projektleitung mit Hinweis auf Seite 354, Aktivität PL 3.42, Paragraph 9 Absatz 2 des Vorge-hensmodells, in dem Größe, Format, Schrifttyp und Layout dieser Kennzeichen verbindlich definiert seien. Die Bauherrin hätte bereits beim Tailoring wider-sprechen müssen, nun sei es wirklich zu spät.
Extrem-Architekten AG Die Extrem-Architekten laden unsere Unternehmerin zu Projektbeginn zu einem Planungsspiel ein. Jeden Raum ihres geplanten EFHs soll sie dabei der Wichtig-keit nach mit Gummibärchen bewerten. Die immer nur paarweise auftretenden Architekten versprechen ihr, eine erste funktionsfähige Version des Hauses nach nur 6 Wochen. Auf Planungsunterlagen würde man im Zuge der schnellen Ent-wicklung verzichten.
Zu Beginn der Arbeiten wurde das Team in einer Art Ritual auf die gemeinsame Vision des Hauses eingeschworen. Wie ein Mantra murmelten alle Teammitglieder ständig mit selt-sam gutturaler Betonung die Silben „Einfa-Milien-Haus“, was sich nach einiger Zeit zu „Ei-Mi-Ha“ abschliff. Mehrere Außenstehende wollen gehört haben, das Team baue einen bewohnbaren Eimer. Sie stellten eine überdimensionale Tafel am Rande des Baugeländes auf. Jeder durfte darauf Verbesserungsvorschläge oder Änderungen eintragen. Dies gehöre zu einem Grundprinzip der Firma: „Kollektives geis-tiges Eigentum: Planung und Entwurf gehören allen“. Nach exakt 6 Wochen laden die Extrem-Architekten die Unternehmerin zur Besichtigung der ersten funktionsfähi-gen Version ein. Wieder treten ihr zwei Architekten ent-
gegen, jedoch erkennt sie nur einen davon aus dem Planungsspiel wieder. Der andere arbeitet jetzt bei den Gärtnern. Der ursprüngliche andere Gärtner hilft dem Elektriker, ein Heizungsbauer entwickelt dafür die Statik mit. Auf diese Wiese verbreite sich das Projektwissen im Team, erläutern beide Architekten eifrig. Man präsentiert ihr einen Wohnwagen. Ihren Hinweis auf fehlende Küche, Kel-ler und Dachgeschoss nehmen die Extrem-Architekten mit großem Interesse auf (ohne ihn jedoch schriftlich zu fixieren). Weitere 6 Wochen später hat das Team eine riesige Grube als Keller ausgehoben und den Wohnwagen auf Holzbohlen provisorisch darüber befestigt. Das Keller-fundament haben ein Zimmermann und ein Statiker gegossen. Leider blieb der Beton zu flüssig. Geeignete Tests seien aber bereits entwickelt, dieser Fehler käme garantiert nie wieder vor.
1.1 Software-Architekten
5
Mehrere weitere 6-Wochen-Zyklen gehen ins Land. Bevor unsere Unternehme-rin das Projekt (vorzeitig) für beendet erklärt, findet sie zwar die von ihr ge-wünschte Küche, leider jedoch im Keller. Ein Refactoring dieses Problems sei nicht effektiv, erklärte man ihr. Dafür habe man im Dach einen Teil der Wohn-wagenküche verbaut, sodass insgesamt die Zahl der Küchen-Gummibären er-reicht worden sei. Das immer noch flüssige Kellerfundament hat eines der Teams bewogen, auf die Seitenwände des Hauses auf Dauer zu verzichten, um die Lüftung des Kellers sicherzustellen. Im Übrigen besitzt das Haus nur ein Geschoss, das aktuelle Statik-Team (bestehend aus Zimmermann und Gärtner) hat dafür die Garage in 3 Kinderzimmer unterteilt. Da das Team nach eigenen Aussagen auf die lästige und schwergewichtige Do-kumentation verzichtet hatte, waren auch keine Aufzeichnungen der ursprüngli-chen Planung mehr erhalten. Im Nachhinein beriefen sich alle Projektteams auf ihren Erfolg. Niemand hatte bemerkt, dass die Bauherrin keines der „implementierten“ Häuser wirklich akzep-tierte.
Chaos nur am Bau? Ähnlichkeiten mit bekannten Vorgehensweisen der Software-Entwicklung sind durchaus gewollt, denn nicht nur beim Hausbau herrscht Chaos. Auch andere Ingenieurdisziplinen werden ab und zu von Elchen auf die Probe gestellt, obwohl der Maschinenbau über mehr als 200 Jahre Erfahrung verfügt. In der Software-Branche geht es nur unwesentlich besser zu. Der regelmäßige Chaos-Report der Standish-Group zeigt eine seit Jahren gleich-bleibende Tendenz: Über 30% aller Software-Projekte werden (erfolglos) vorzei-tig beendet, in über 50% aller Software-Projekte kommt es zu drastischen Kos-ten- oder Terminüberschreitungen.1
1 Quelle: The Standish Group Chaos Report. Erhältlich unter www.standishgroup.com.
431
Register . .NET-Remoting 221
A Abhängigkeiten 161 Ablaufsteuerung 242, 274 Active Data Objects 194 Adapter 174 Agilität 6, 82 Änderbarkeit 61 Anforderungsanalyse 31 Anwendungen in SOA 332 Anwendungslandschaft 342
Management der 344 Applikationsmonolithen 330 Arbeitsmetapher 253 Architecture Business Cycle 28 Architekten, Aufgaben von 27 Architektur siehe Software-Architektur
Business- 341 Architekturbeschreibung, zentrale 107 Architekturbewertung 315
als Teil der Architekturentwicklung 319 Auswirkung von 327 Vorgehen 321
Architekturdokumentation 77, 107 Anforderungen 113 Beispiel 351 Grundannahmen 81
Architekturebenen 341
Architekturentscheidung 17 Architekturmuster 149
Pipes & Filter 153 Schichten 149
Architektursichten 80 Architekturüberblick 107 ATAM siehe Architekturbewertung Ausbildung von Software-Architekten 404 Ausnahmenbehandlung 297 Authentisierung 286 Autorisierung 286
B Bausteinsicht 89
hierarchische Verfeinerung 90 UML 2 129
Beam me up, Scotty 240 Beispiel Architekturdokumentation 351 Benutzbarkeit 61 Beschreibung von Schnittstellen 102 Bewertung
von Architekturen 315 von Artefakten 316 von Prozessen 316 qualitativ 316
Blackbox 90 BSOD 297 Business-Architektur 341 Business-IT-Alignment 349
Register
432
C Caching 208 Choreographie 338 Ciphertext 287 Conflict-Set 213 CORBA 221, 232
IDL 103 cyclomatic complexity 317
D DAO 198 Data Access Object 198 Dateitransfer 220 Daten, Arten der Datenverwaltung 43 Datenbanksystem 191 Datenklassen 194 Datensicht 105 Datenverwaltung, Arten 43 Dekorierer 177 denial-of-Service 287 Diagnose von Fehlern 303 DIN/ISO 9126 60 Dokumentation
Grundprinzipien 116 Qualitätsanforderungen 115
Dokumente selbstbeschreibend 335 zur Beschreibung von Architekturen
107 DRY-Prinzip 117
E Effektiv 8 Effizienz 8, 61 Einflussfaktoren
architekturrelevante 48 finden 50 organisatorische 51 Systemfaktoren 56 technische 54
Enterprise-IT Architektur 341 Enterprise-Service-Bus 339 Entwurfsentscheidung 17
Entwurfsmuster Adapter 174 Dekorierer 177 Fassade 178 MVC 246 Observer 175 Proxy 177 State (Zustand) 179 zur Integration 225
Entwurfsprinzip abhängig nur von Abstraktionen 166 Abhängigkeit minimieren 161 Dependency Injection 172 Fachlichkeit und Technik trennen 159 hohe Kohäsion 164 Liskov 170 lose Kopplung 164 Modularität 159 nach Verantwortlichkeiten entwerfen
158 Offen-Geschlossen 164 Schnittstellen abtrennen 167 So-einfach-wie-möglich 157 Substitutionsprinzip 170
Entwurfsprinzipien 157 ESB 339 Evaluierung von Architekturen
siehe Bewertung
F Fabrik-Metapher 254 Fassade 178 Fehler 299
Format- 301 Protokollfehler 301 syntaktische 301
Fehlerbehandlung 297 Fehlerdiagnose 303 Firewall 284 Flexibilität, unternehmerische 330 Folgefehler 304 Formatfehler 301 Formular-Metapher 255
Register
433
Fragen an Architekturdokumentation 113 Funktionalität 61
G Gateway 225 Geschäftsfunktionen als Services in SOA
332 Geschäftsprozesse 275, 329
Informationsbedarf 342 Geschäftsregel 209 Geschäftsregeln 210 Geschäftsziele bei Architekturbewertung
322 Gesetz von Hofstadter 314 Governance 340 Grafische Benutzeroberfläche
Ergonomie 253 GRASP 181 Grundprinzipien von Dokumentation 116
H Heuristiken 142
zum Entwurf 157 Hofstadtersche Gesetz 314
I IDL 103 impedance mismatch 192 Informationsarchitektur 342 Infrastruktursichten 99 Integration 217
Entwurfsmuster 225 Integrität 286 Interaktionsstile 255 Internationalisierung 265 iSAQB 403 Iterationen 28
beim Entwurf 37 IT-Infrastruktur 342
J Java-RMI 221
K Kategorien von Systemen 41 Klartext 287 Klassen, UML 2 127 Knoten 100
UML 2 133 Kohäsion 164 Kommunikation 235
(a)synchron 236 Protokolle 239 von Architekturen 78
Kommunikationsaufgabe 78 Komplexität 143 Komponenten, UML 2 127 Kontextabgrenzung 87 Kopplung 164
lose 333
L Laufzeitsicht 96
UML 2 134 Layer 149 Lehrplan 404 Logging 294 Lösungsstrategien 68
M Match-Select-Act 213 MDA 307 Mehrsprachigkeit 267 Messaging 220, 222 Messgröße für Software-Architekturen
320 Metadaten 334 Metriken 316
für Quellcode 316 Mindmaps als Hilfsmittel für
Qualitätsbäume 324 Model-Driven-Architecture 307 Model-View-Controller 246 Modularität 159 Murphy’s Regel 297
Register
434
N n-Tier 152
O OAW 311 Object Request Broker 222 Observer 175 Offen-Geschlossen-Prinzip 164 openArchitectureWare 311 OpenSource 313 Orchestrierung 338 OSI-7-Schichten 239
P Pakete, UML 2 127 Peer-to-Peer 156 Persistenz 189 Persistenzschicht 193
Aufbau 196 DAO 198 Entwurf 197
PIM 308 Pipes & Filter 153 POLA-Prinzip 117 Projektplanung 31 Projektrisiken 56 Protokollfehler 301 Proxy 177 PSM 308 Public Key Infrastructure 284 Publish – Subscribe 238
Q Qualität 59 Qualitätsbaum 323
Szenarien konkretisieren 324 Qualitätskriterien als Bewertungsziel 320 Qualitätsmerkmale 60, 320 Qualitätssicherung 33, 180
R Referenzarchitekturen 346 Regelinterpreter 212
Regeln 210 Regelsystem 209 Registry für Services 338 Remote Procedure Call 221, 238 Risiken 56 Risikoanalyse 32 Risikomanagement 32 rule-engine 212
S Schicht 149
Nachteile 150 Vorteile 150
Schichten (Layer) 149 Schnittstelle von Service 334 Schnittstellen 42, 102, 160
CORBA IDL 103 UML 2 128
Sequenzdiagramm 136 Services
Funktionsweise 336 in Rolle von "Anwendungen" 332
Service Registry 338 Service-Vertrag 334 Sicherheit 284 Sichten 80
4 Arten 82 neue Arten 84 Baustein- 89 Datensicht 105 -Kontextabgrenzung 87 -Laufzeit 96 -Verteilung 99
Signaturgesetz 285 So einfach wie möglich 157 SOA 329, 330
und Software-Architektur 340 SOAP 221 Software-Architekten 21
Aufgaben von 27 Software-Architektur 16
Ausbildung 404 Bewertung 315
Register
435
Dokumentation und Kommunikation 78
Iterationen 28 Sichten 17, 80 und Qualitat 59
Speicher 189 SPOT-Prinzip 117 SQL 190 Stakeholder
bei Architekturbewertung 322 maßgebliche 322
Starrheit 162 Steuerung, Arten der 45 Strategie 341 Substitutionsprinzip 170 Systemidee 39 Szenarien
für Bewertung priorisieren 325 zur Bewertung 324 konkretisieren Qualität 62 und Qualitatsmerkmale 64
T Template 309 Test 180 Testen 183 Tiers 152 Tracing 294 Transaktionen 208
U Übersichtspräsentation 107 Übertragbarkeit 62 UML 123 UML 2 123
Aktivitäten 131 Diagrammarten 125 Interaktionsübersicht 138
Klassen und Objekte 127 Knoten 133 Kommunikationsdiagramm 137 Laufzeitsicht 134 Schnittstellen 128 statische vs. dynamische Modelle 139 Verteilung 132 Zustände 131
V Verschlüsselung 287
Verfahren 288 Verteilung 231 Verteilungssicht, UML 2 132 Verteilungssichten 99 Vertraulichkeit 285 Vorgehen zur Architekturbewertung 321
W Walkthrough von Szenarien 326 Website
www.arc42.de 12 www.esabuch.de 12
Wegweiser durch das Buch 10 Werkzeug-Material-Metapher 255 Whitebox 90 WMS 277 Workflow-Management 274 Wrapper 225
Z Zerbrechlichkeit 162 Zerlegung
Fachdomäne 148 Tipps zur 144 von Systemen 144
Zertifikate 290