EFFEKTIVE SOFTWARE- ARCHITEKTUREN

Transkript

1 gernot STARKE EFFEKTIVE SOFTWARE- ARCHITEKTUREN EIN PRAKTISCHER LEITFADEN 3. Auflage

2 Inhalt Vorwort... 1 Vorwort zur zweiten Auflage... 2 Vorwort zur dritten Auflage Einleitung Software-Architekten Effektiv, agil und pragmatisch Wer sollte dieses Buch lesen? Wegweiser durch das Buch Webseite zum Buch Weiterführende Literatur Danksagung Architektur und Architekten Was ist Architektur? Die Aufgaben von Software-Architekten Wie entstehen Architekturen? In welchem Kontext steht Architektur? Weiterführende Literatur Vorgehen bei der Architekturentwicklung Informationen sammeln Systemidee entwickeln Was sind Einflussfaktoren und Randbedingungen? Einflussfaktoren finden Risiken identifizieren Qualität explizt beschreiben Qualitätsmerkmale von Software-Systemen Szenarien konkretisieren Qualität Lösungsstrategien entwickeln Strategien gegen organisatorische Risiken Strategien für hohe Performance V

3 Inhalt Strategien für Anpassbarkeit und hohe Flexibilität Strategien für hohe Verfügbarkeit Weiterführende Literatur Architektursichten zur Kommunikation und Dokumentation Architekten müssen kommunizieren und dokumentieren Sichten Sichten in der Software-Architektur Vier Arten von Sichten Entwurf der Sichten Kontextsicht Elemente der Kontextsicht Notation der Kontextsicht Entwurf der Kontextsicht Bausteinsicht Elemente der Bausteinsicht Notation der Bausteinsicht Entwurf der Bausteinsicht Laufzeitsicht Elemente der Laufzeitsicht Notation der Laufzeitsicht Entwurf der Laufzeitsicht Verteilungssicht Elemente der Verteilungssicht Notation der Verteilungssicht Entwurf der Verteilungssicht Dokumentation von Schnittstellen Datensicht Typische Architekturdokumente Zentrale Architekturbeschreibung Architekturüberblick Dokumentationsübersicht Übersichtspräsentation der Architektur Architekturtapete Effektive Architekturdokumentation Anforderungen an Architekturdokumentation Regeln für gute Architekturdokumentation Weiterführende Literatur UML 2 für Architekten Die Diagrammarten der UML Die Bausteine von Architekturen Schnittstellen Die Bausteinsicht Die Verteilungssicht Die Laufzeitsicht VI

4 Inhalt 5.7 Darum UML Weiterführende Literatur Strukturentwurf, Architektur- und Designmuster Von der Idee zur Struktur Komplexität beherrschen Zerlegen aber wie? Fachmodelle als Basis der Entwürfe Die Fachdomäne strukturieren Architekturmuster Schichten (Layer) Pipes & Filter Weitere Architekturmuster Heuristiken zum Entwurf Das So-einfach-wie-möglich-Prinzip Entwerfen Sie nach Verantwortlichkeiten Konzentrieren Sie sich auf Schnittstellen Berücksichtigen Sie Fehler Optimieren von Abhängigkeiten Streben Sie nach loser Kopplung Hohe Kohäsion Offen für Erweiterungen, geschlossen für Änderungen Abhängigkeit nur von Abstraktionen Abtrennung von Schnittstellen Zyklische Abhängigkeiten vermeiden Liskov-Substitutionsprinzip (LSP) Dependency Injection (DI) Entwurfsmuster Entwurf mit Mustern Adapter Beobachter (Observer) Dekorierer (Decorator) Stellvertreter (Proxy) Fassade Zustand (State) Entwurf, Test, Qualitätssicherung Weiterführende Literatur Typische Architekturaspekte Persistenz Motivation Typische Probleme Architekturmuster Persistenzschicht Weitere Themen zu Persistenz Zusammenhang mit anderen Aspekten Weiterführende Literatur VII

5 Inhalt 7.2 Geschäftsregeln Motivation Funktionsweise von Regelmaschinen Kriterien pro & kontra Regelmaschinen Mögliche Probleme Weiterführende Literatur Integration Motivation Typische Probleme Lösungskonzepte Entwurfsmuster zur Integration Konsequenzen und Risiken Zusammenhang mit anderen Aspekten Weiterführende Literatur Verteilung Motivation Typische Probleme Lösungskonzept Konsequenzen und Risiken Zusammenhang mit anderen Aspekten Weiterführende Literatur Kommunikation Motivation Entscheidungsalternativen Grundbegriffe der Kommunikation Weiterführende Literatur Ablaufsteuerung grafischer Oberflächen Model-View-Controller (MVC) Weiterführende Literatur Ergonomie grafischer Oberflächen Arbeitsmetaphern Interaktionsstile Ergonomische Gestaltung Heuristiken zur GUI-Gestaltung Weiterführende Literatur Internationalisierung Globale Märkte erfordern neue Prozesse Dimensionen der Internationalisierung Lösungskonzepte Weiterführende Literatur Workflow-Management: Ablaufsteuerung im Großen Zweck der Ablaufsteuerung Lösungsansätze Integration von Workflow-Systemen Mächtigkeit von WMS Weiterführende Literatur VIII

6 Inhalt 7.10 Sicherheit Motivation Typische Probleme Sicherheitsziele Lösungskonzepte Zusammenhang mit anderen Aspekten Weiterführende Literatur Protokollierung Typische Probleme Lösungskonzept Zusammenhang mit anderen Aspekten Weiterführende Literatur Ausnahme- und Fehlerbehandlung Motivation Fehlerkategorien schaffen Klarheit Muster zur Fehlerbehandlung Mögliche Probleme Zusammenhang mit anderen Aspekten Weiterführende Literatur Model Driven Architecture (MDA) Architekten entwickeln Generierungsvorlagen Modellierung Modellbasiert entwickeln Weiterführende Literatur Service-Orientierte Architektur (SOA) Was ist SOA? So funktionieren Services Was gehört (noch) zu SOA? SOA und Software-Architektur Weiterführende Literatur Bewertung von Software-Architekturen Was Sie an Architekturen bewerten können Vorgehen bei der Bewertung Weiterführende Literatur Enterprise-IT-Architektur Wozu Architekturebenen? Aufgaben von Enterprise-Architekten Management der Infrastrukturkosten Management des IS-Portfolios Definition von Referenzarchitekturen Weitere Aufgaben Weiterführende Literatur IX

7 Inhalt 12 Beispiel einer Architekturdokumentation Einführung Architekturtreiber Architekturziele Geschäftskontext Stakeholder Einflussfaktoren Technische Einflussfaktoren Organisatorische Einflussfaktoren Kontextsicht Bausteinsicht M&M Bausteinsicht Level Migration Controller VSAM Reader Segmentizer Migrationsdatenbank Packager Rule Processor (und Packager) Target System-Adapter Migrierte Kontodaten in Zieldatenbank M&M Bausteinsicht Level VSAM-Reader Whitebox Rule Processor Whitebox Laufzeitsicht Verteilungssicht Entwurfsentscheidungen Szenarien zur Architekturbewertung Architekturaspekte Persistenz Ablaufsteuerung Ausnahme- und Fehlerbehandlung Transaktionsbehandlung Projektaspekte Glossar und Referenzen Nachwort: Architektonien Literatur Register X

8 2 2 Architektur und Architekten Architecture is about People. Norman Foster Fragen, die dieses Kapitel beantwortet: Was ist Software-Architektur? Welche Aufgaben erfüllen Software-Architekten? Warum ist Architektur für Software-Systeme wichtig? In welchem Kontext steht Architektur? Wie entstehen Architekturen? Dieses Kapitel beantwortet die Frage Was ist Software-Architektur?. Es beschreibt Architekturen im Kontext der gesamten Softwareentwicklung. Eine zentrale Stellung kommt der vielseitigen Rolle von Architekten zu. Softwaresysteme werden zunehmend komplexer und umfangreicher. Damit nimmt die Bedeutung von Entwurf und Beschreibung grundlegender Systemstrukturen zu, während die Bedeutung der Auswahl von Programmiersprachen, Algorithmen und Datenstrukturen zurückgeht. 15

9 2 Architektur und Architekten 2.1 Was ist Architektur? Software-Architektur beschäftigt sich mit Abstraktion, mit Zerlegung und Zusammenbau,mit Stil und Ästhetik. [Kruchten95] Das renommierte Software Engineering Institute (SEI) der US-amerikanischen Carnegie-Mellon Universität hat vor einiger Zeit den Versuch gestartet, den Begriff Software-Architektur exakt zu definieren. Die entsprechende Webseite 1 wartet mit mehr als 50 unterschiedlichen Lesarten des Begriffes auf. Die einschlägige Fachliteratur kann hier mithalten mehrere Dutzend unterschiedlicher Definitionen werben um die Gunst des Fachpublikums. Statt zu dieser verwirrenden Vielfalt beizutragen, möchte ich Ihnen den Begriff Software-Architektur in einigen Absätzen erläutern. Architektur ist Struktur Strukturen, Zerlegung, Schnittstellen, Beziehungen Die Architektur eines Softwaresystems besteht nach [Bass03] aus seinen Strukturen 2, der Zerlegung in Komponenten, deren Schnittstellen und Beziehungen untereinander. Architektur muss demnach die Komponenten eines Systems definieren, deren wesentliche (extern sichtbaren) Merkmale beschreiben sowie die Beziehungen zwischen diesen Komponenten charakterisieren. Damit beschreibt Architektur sowohl statische als auch dynamische Aspekte. Sie erfüllt sowohl die Aufgabe eines Bauplans als auch die eines Ablaufplans für Software. Architektur bildet den Übergang von der Analyse zur Realisierung Software-Architektur bildet den schwierigen Übergang von der Analysephase zur konkreten technischen Realisierung. Sie schlägt die Brücke zwischen der Fachdomäne und deren Umsetzung in Software, indem sie die geforderte Funktionalität auf eine Struktur von Softwarekomponenten und deren Beziehungen untereinander abbildet. Dabei gibt es Unterschiede, ob Sie: auf der grünen Wiese entwickeln dann sind Sie relativ frei in der Wahl von Komponenten und der Abbildung der Fachdomäne auf Komponenten; ein Teilsystem innerhalb einer existierenden Systemlandschaft entwickeln dann unterliegen Sie starken Restriktionen (die Sie ermitteln müssen); Sie lesen richtig: Es sind mehrere unterschiedliche. Die weiter unten beschriebenen Sichten beschreiben dasselbe System, aber unterschiedliche Strukturen. Im weiteren Verlauf des Buches benutze ich aus Gründen der Lesbarkeit trotzdem meistens den Singular. 16

10 2.1 Was ist Architektur? nach einer vorgegebenen domänen-spezifischen Software-Architektur eines von vielen ähnlichen Systemen entwickeln. Dann reduziert sich die Architektur darauf, Fachlichkeit in eine bestehende Architektur zu gießen. Architektur besteht aus verschiedenen Sichten Gebäudearchitekten erstellen eine Vielzahl unterschiedlicher Pläne und Sichten für Gebäude. Einige Beispiele dafür sind Grundriss, Statik, Elektro- und Heizungsplan, 3D-Sicht. Jede dieser einzelnen Sichten dokumentiert einzelne Aspekte des Gesamtsystems. Den verschiedenen Projektbeteiligten wird damit eine spezifische und für deren Belange angemessene Sicht vermittelt. Jede Sicht ist für bestimmte Stakeholder nützlich. Für Software-Architekturen gilt das völlig analog: Sie sollten Architekturen in unterschiedlichen Sichten beschreiben. Die wichtigsten Sichten für Software- Architekturen sind die Bausteinsicht, die Laufzeitsicht sowie die Verteilungssicht, die eine Abbildung von Laufzeitbausteinen auf technische Infrastruktur (Hardware) beschreibt. Kapitel 4 beschäftigt sich ausführlich mit den Sichten, ihrer Notation und Entwicklung. In Abbildung 2.1 sehen Sie die Sichten im Überblick. Kontextsicht Vogelperspektive & Nachbarsysteme Unterschiedliche Sichten Laufzeitsicht Wie arbeiten Bausteine zusammen? o o o Bausteinsicht Statische Struktur: Bausteine und Beziehungen Verteilungssicht In welcher Umgebung läuft das System ab? Abbildung 2.1 Vier Sichten auf Architektur Architektur schafft Verständlichkeit Software-Architekturen machen Komplexität von Systemen beherrschbar und verständlich, indem sie (komplexe) Anforderungen in (geordnete) Strukturen übersetzen und diese Strukturen übersichtlich dokumentieren. Architektur schafft Ordnung 17

11 2 Architektur und Architekten Architektur ermöglicht Überblick Architektur stellt Erweiterbarkeit sicher Architektur lässt nicht benötigte Informationen gezielt weg Für alle Projektbeteiligten dokumentieren sie angemessen und problembezogen die Struktur und das Zusammenwirken der einzelnen Komponenten. Architekturen stellen damit das Verständnis von Systemen für alle Projektbeteiligten sicher: Für das Management bilden sie die erste Möglichkeit der Verifikation, ob die Anforderungen erfüllbar sind und erfüllt werden. Für neue Projektmitarbeiter sind Architekturen der erste Schritt, sich mit der Struktur des Systems, seinem Entwurf und seinen Bestandteilen vertraut zu machen. Architekturen ermöglichen Wartungsteams, die betroffenen Bestandteile leichter zu finden und die Folgen von Änderungen abzuschätzen (impact analysis). Für Betreiber von Software-Systemen dokumentieren Software-Architekturen, welche Software-Komponenten auf welchen physischen Systemteilen ablaufen. Sie stellen damit die Basis integrierter System-Architekturen dar, die neben Software auch noch Hardware und Organisationsstrukturen umfassen. Architektur ist der Rahmen für flexible Systeme Software-Architektur ist nach Tom DeMarco ein framework for change. Sie bildet also den Rahmen, der Flexibilität und Erweiterbarkeit von Software sicherstellt. Software-Architekturen berücksichtigen dabei die Auswirkungen externer Einflussfaktoren organisatorischer und technischer Art auf das System. Diese Faktoren sind häufig Auslöser neuer Anforderungen an das System. Sie bestimmen, in welcher Hinsicht das System Flexibilität besitzen muss. Architektur ist Abstraktion Im ersten Moment mag es Ihnen unglaublich vorkommen: Eine essenzielle Aufgabe von Architekten besteht darin, die für eine bestimmte Aufgabe nicht benötigten Informationen gezielt wegzulassen, zu abstrahieren. Diese Abstraktion besitzt eine Analogie in der Gebäudearchitektur: Eine Grundrisszeichnung enthält beispielsweise keine Informationen über Elektro- und Wasserleitungen. Hier wird bewusst Information gefiltert, um eine spezifische Darstellung der Architektur lesbar und verständlich zu halten. Architektur schafft Qualität Die Qualität eines Systems bezeichnet die Summe seiner nichtfunktionalen Eigenschaften. Hierzu zählen Aspekte wie Performance, Verständlichkeit, Flexibilität und eine Reihe weiterer wichtiger Eigenschaften, die samt und sonders unabhängig von der eigentlichen Funktionalität eines Systems sind. 18

12 2.1 Was ist Architektur? Anforderungen an Qualitätseigenschaften, so genannte nichtfunktionale Anforderungen (NF-Anforderungen), stellen häufig die wirklich schwierigen Aufgaben für Software-Architekten dar. Einen bestimmten Algorithmus ohne jegliche NF- Anforderungen zu programmieren, ist erheblich leichter, als dieses Programm gleichzeitig auch noch verständlich, erweiterbar und performant für viele parallele Benutzer zu entwickeln 3. Die Architektur eines Systems bildet die Basis für dessen Qualität. Sie ist auch die Grundlage, um spezifische Qualitätseigenschaften bewerten zu können (Kapitel 10 erklärt Ihnen die Bewertung von Software-Architekturen). In Abschnitt 3.7 (Lösungsstrategien entwickeln) finden Sie Tipps zur Erfüllung typischer Qualitätsanforderungen. Architektur und Design Architektur und Design beschäftigen sich mit dem Entwurf von Systemen. Ich vertrete die Auffassung, dass die Grenze zwischen Software-Architektur und Software-Design fließend ist. Damit rücken die Begriffe Design und Architektur sehr eng zusammen. Design oder Entwurf bezeichnen den Prozess der Erstellung der Architektur. Die Entwurfsphase konstruiert oder erschafft in diesem Sinne die Architektur. Manchmal gehört der Entwurf einer konkreten Klassenstruktur zur Aufgabe von Architekten, in anderen Fällen werden zusätzliche Designer diese Aufgabe lösen. Gehen Sie mit diesen Begriffen pragmatisch um und suchen Sie nicht nach einer formalen Definition. Was NICHT Architektur ist... Betrachten Sie Abbildung 2.2. Diagramme dieser Art tauchen sehr häufig unter dem Titel Architekturdiagramm auf (nach [Bass98]). Client Controller (CC) Transaction Model Mailsystem Reporting Abbildung 2.2 Typische, aber wenig informative Sicht einer Architektur Welche Informationen können Sie dieser Darstellung entnehmen? 3 Das ist auch ein Grund, wieso sich Übungsbeispiele aus Programmierkursen fast nie in die Wirklichkeit übertragen lassen: Die (hohe) Komplexität nichtfunktionaler Anforderungen bleibt in solchen Beispielen in der Regel außen vor genau die jedoch erschwert in der Praxis die Softwareentwicklung! 19

13 Register..NET-Remoting 217 A Abhängigkeiten 157 Ablaufsteuerung 237, 269 Active Data Objects 189 Adapter 170 Agilität 6, 82 Änderbarkeit 61 Anforderungsanalyse 30 Anwendungen in SOA 312 Anwendungslandschaft 336 Management der 338 Applikationsmonolithen 310 Arbeitsmetapher 248 Architecture Business Cycle 27 Architekten Aufgaben von 25 Werkzeuge von 25 Architektur siehe Software-Architektur Architekturbeschreibung, zentrale 105 Architekturbewertung 321 als Teil der Architekturentwicklung 325 Auswirkung von 333 Vorgehen 327 Architekturdokumentation 77, 105 Anforderungen 111 Beispiel 345 Grundannahmen 81 Architekturebenen 335 Architekturmuster 145 Pipes & Filter 149 Schichten 145 Architektursichten 79 Architekturüberblick 105 ATAM siehe Architekturbewertung Ausnahmenbehandlung 292 Authentisierung 281 Autorisierung 281 B Bausteinsicht 89 hierarchische Verfeinerung 90 UML Beam me up, Scotty 236 Beispiel Architekturdokumentation 345 Benutzbarkeit 60 Beschreibung von Schnittstellen 100 Bewertung qualitativ 322 von Architekturen 321 von Artefakten 322 von Prozessen 322 Blackbox 89 BSOD 292 Business-Architektur 335 Business-IT-Alignment 343 C Caching 204 Choreographie 318 Ciphertext

14 Register Conflict-Set 208 CORBA 217, 228 IDL 101 cyclomatic complexity 323 D DAO 193 Data Access Object 193 Dateitransfer 216 Daten, Arten der ~verwaltung 42 Datenbanksystem 186 Datenklassen 189 Datensicht 103 Dekorierer 173 denial-of-service 282 Diagnose von Fehlern 298 DIN/ISO Dokumentation Grundprinzipien 114 Qualitätsanforderungen 113 Dokumente selbstbeschreibend 315 zur Beschreibung von Architekturen 105 DRY-Prinzip 115 E Effektiv 8 Effizienz 8, 61 Einflussfaktoren 45 architekturrelevante 47 finden 49 organisatorische 50 Systemfaktoren 55 technische 53 Enterprise-IT Architektur 335 Enterprise-Service-Bus 319 Entwurfsmuster Adapter 170 Dekorierer 173 Fassade 174 MVC 241 Observer 171 Proxy 173 State (Zustand) 175 zur Integration 220 Entwurfsprinzipien 153 abhängig nur von Abstraktionen 162 Abhängigkeit minimieren 157 Dependency Injection 168 Fachlichkeit und Technik trennen 155 hohe Kohäsion 160 Liskov 166 lose Kopplung 160 Modularität 155 nach Verantwortlichkeiten entwerfen 154 Offen-Geschlossen 160 Schnittstellen abtrennen 163 So-einfach-wie-möglich 153 Substitutionsprinzip 166 ESB 319 Evaluierung von Architekturen siehe Bewertung F Fabrik-Metapher 249 Fassade 174 Fehler 294 Format- 296 Protokoll- 296 syntaktische 296 Fehlerbehandlung 292 Fehlerdiagnose 298 Firewall 279 Flexibilität, unternehmerische 310 Folgefehler 299 Formatfehler 296 Formular-Metapher 250 Fragen an Architekturdokumentation 111 Funktionalität 60 G Gateway 221 Geschäftsfunktionen als Services in SOA

15 Register Geschäftsprozesse 270, 309 Informationsbedarf 336 Geschäftsregeln 205 Geschäftsziele bei Architekturbewertung 328 Gesetz von Hofstadter 308 Governance 320 Grafische Benutzeroberfläche, Ergonomie 248 GRASP 177 Grundprinzipien von Dokumentation 114 H Heuristiken 138 zum Entwurf 153 Hofstadtersches Gesetz 308 I IDL 101 impedance mismatch 188 Informationsarchitektur 336 Infrastruktursichten 98 Integration 212 Entwurfsmuster 220 Integrität 281 Interaktionsstile 250 Internationalisierung 260 Iterationen 27 beim Entwurf 37 IT-Infrastruktur 336 J Java-RMI 217 K Kategorien von Systemen 40 Klartext 282 Klassen, UML Knoten 98 UML Kohäsion 160 Kommunikation 230 (a)synchron 231 Protokolle 234 von Architekturen 78 Kommunikationsaufgabe 78 Komplexität 139 Komponenten, UML Kontextsichten 87 Kopplung 160 lose 313 L Laufzeitsicht 94 UML Layer 145 Logging 289 Lösungsstrategien 67 M Match-Select-Act 208 MDA 301 Mehrsprachigkeit 262 Messaging 215, 218, 215, 218 Messgröße für Software-Architekturen 326 Metadaten 314 Metriken 322 für Quellcode 322 Mindmaps als Hilfsmittel für Qualitätsbäume 330 Model-Driven-Architecture 301 Model-View-Controller 241 Modularität 155 Murphy s Regel 292 N n-tier 148 O OAW 305 Object Request Broker 218 Observer 171 Offen-Geschlossen-Prinzip 160 openarchitectureware 305 OpenSource

16 Register Orchestrierung 318 OSI-7-Schichten 235 P Pakete, UML Peer-to-Peer 152 Persistenz 185 Persistenzschicht 188 Aufbau 191 DAO 194 Entwurf 192 PIM 302 Pipes & Filter 149 POLA-Prinzip 115 Projektplanung 31 Projektrisiken 56 Protokollfehler 296 Proxy 173 PSM 302 Public Key Infrastructure 279 Publish Subscribe 233 Q Qualität 58 Qualitätsbaum 329 Szenarien konkretisieren 330 Qualitätskriterien als Bewertungsziel 326 Qualitätsmerkmale 59, 326, 59 Qualitätssicherung 32, 176, 32, 176 R Randbedingungen 45 Referenzarchitekturen 340 Regelinterpreter 207 Regeln 205 Regelsystem 205 Registry für Services 318 Remote Procedure Call 217, 233, 217, 233 Risiken 56 Risikoanalyse 31 Risikomanagement 31 rule-engine 207 S Schicht 145 Nachteile 146 Vorteile 146 Schnittstellen 42, 100, 156, CORBA IDL 101 UML von Service 314 Sequenzdiagramm 132 Service Funktionsweise 316 in Rolle von "Anwendungen" 312 -Registry 318 -Vertrag 314 Sicherheit 279 Sichten 79 4 Arten 82 Baustein- 89 Datensicht 103 -Kontext 87 -Laufzeit 94 neue Arten 84 -Verteilung 98 Signaturgesetz 280 So einfach wie möglich 153 SOA 309, 310 und Software-Architektur 320 SOAP 217 Software-Architekten 21 Aufgaben von 25 Werkzeuge von 25 Software-Architektur 16 Bewertung 321 Dokumentation und Kommunikation 78 Iterationen 27 Sichten 17, 79, 17, 79, 17, 79 und Qualitat 58 Speicher 185 SPOT-Prinzip 115 SQL 185 Stakeholder bei Architekturbewertung

17 Register maßgebliche 328 Starrheit 158 Steuerung, Arten 44 Strategie 335 Substitutionsprinzip 166 Systemidee 39 Szenarien für Bewertung priorisieren 331 konkretisieren Qualität 61 und Qualitatsmerkmale 63 zur Bewertung 330 T Template 303 Test 176 Testen 179 Tiers 148 Tracing 289 Transaktionen 203 U Übersichtspräsentation 105 Übertragbarkeit 61 UML 119 UML Aktivitäten 127 Diagrammarten 121 Interaktionsübersicht 134 Klassen und Objekte 123 Knoten 129 Kommunikationsdiagramm 133 Laufzeitsicht 130 Schnittstellen 124 statische vs. dynamische Modelle 135 Verteilung 128 Zustände 127 V Verschlüsselung 282 Verfahren 283 Verteilung 226 Verteilungssichten 98 UML Vertraulichkeit 280 Vorgehen zur Architekturbewertung 327 W Walkthrough von Szenarien 332 Website, 12 Wegweiser durch das Buch 10 Werkzeug-Material-Metapher 250 Whitebox 90 WMS 272 Workflow-Management 269 Wrapper 221 Z Zerbrechlichkeit 158 Zerlegung Fachdomäne 144 Tipps zur 140 von Systemen 140 Zertifikate