Softwarearchitekturen dokumentieren und kommunizieren

Entwürfe, Entscheidungen und Lösungen nachvollziehbar und wirkungsvoll festhalten
 
 
Hanser (Verlag)
  • erschienen am 12. Mai 2015
  • |
  • 291 Seiten
 
E-Book | PDF mit Wasserzeichen-DRM | Systemvoraussetzungen
978-3-446-44442-3 (ISBN)
 
SOFTWAREARCHITEKTUREN DOKUMENTIEREN UND KOMMUNIZIEREN //
- Sie erfahren, wie die Dokumentation der Architektur von einer lästigen Pflicht zum integralen Kommunikations- und Arbeitsmittel wird.
- Sie lernen, architekturrelevante Einflussfaktoren und zentrale Entscheidungen festzuhalten.
- Sie erleben am Beispiel einer Schach-Engine, wie eine nachvollziehbare Architektur entsteht.
- Auf der Buchwebsite finden Sie Vorlagen und weitere Informationen zum Thema und zu den Fallbeispielen.

Dokumentation wird oft als lästige Pflicht angesehen und in vielen Softwareprojekten stark vernachlässigt, die Architektur wird manchmal überhaupt nicht beschrieben. Damit das in Ihren Projekten nicht passiert, schlägt dieses Buch praxiserprobte und schlanke Bestandteile für eine wirkungsvolle Architekturdokumentation vor.
Anhand eines durchgängigen Beispiels erfahren Sie, wie Sie architekturrelevante Einflussfaktoren erfassen und Ihre Softwarelösung angemessen und ohne Ballast festhalten. Sie lernen nicht nur die Vorgehensweise für das Dokumentieren während des Entwickelns kennen, sondern auch, wie Sie bestehende Systeme im Nachhinein beschreiben. Neben der Methodik diskutiert das Buch auch typische Werkzeuge wie Wikis, UML-Werkzeuge u.a., mit denen Sie Architekturdokumentation erfassen, verwalten und verbreiten können.
Checklisten und Übungsaufgaben geben Ihnen die nötige Sicherheit, um die Architekturdokumentation zu einem integralen Bestandteil in Ihrem Softwarevorhaben zu machen.

// Mein Fazit: Es gibt viele Bücher über Softwarearchitektur. Und dieses gehört zu denen, die man gelesen haben sollte, wenn man Softwareprojekte macht. //
Phillip Ghadir zur ersten Auflage

AUS DEM INHALT //
Ziele und Zielgruppen // Einflussfaktoren // Entscheidungen festhalten // Strukturen und Sichten // Übergreifende Konzepte // Gliederung // arc42 und Alternativen // Werkzeuge // Wiki vs. UML // Dokumentieren im Nachhinein // Reviews
1., überarbeitete und erweiterte Auflage
  • Deutsch
  • München
  • |
  • Deutschland
  • 13,93 MB
978-3-446-44442-3 (9783446444423)
http://dx.doi.org/10.3139/9783446444423
weitere Ausgaben werden ermittelt
Von der Bayer AG über IBM und oose zu embarc: Stefan Zörner blickt auf 20 Jahre IT-Erfahrung zurück und stets gespannt nach vorn. Er unterstützt in Architektur- und Umsetzungsfragen mit dem Ziel, gute Architekturansätze wirksam in der Implementierung zu verankern. Sein Wissen und seine Erfahrung teilt er regelmäßig in Vorträgen, Artikeln und Workshops mit.
1 - Inhalt [Seite 6]
2 - Geleitwort zur.1..Auflage [Seite 12]
3 - Überblick: Dokumentationsmittel im Buch [Seite 14]
4 - 1Warum Software­architekturen dokumentieren? [Seite 16]
4.1 - 1.1 Montagmorgen [Seite 16]
4.1.1 - 1.1.1 Fragen über Fragen [Seite 16]
4.1.2 - 1.1.2 Wer fragt, bekommt Antworten . [Seite 17]
4.2 - 1.2 Voll unagil? [Seite 19]
4.2.1 - 1.2.1 Agil vorgehen [Seite 20]
4.2.2 - 1.2.2 Funktionierende Software vor umfassender Dokumentation [Seite 21]
4.2.3 - 1.2.3 Dokumentation unterstützt Kommunikation [Seite 22]
4.3 - 1.3 Wirkungsvolle Architektur­dokumentation [Seite 22]
4.3.1 - 1.3.1 Ziel.1: Architekturarbeit unterstützen [Seite 23]
4.3.2 - 1.3.2 Ziel.2: Architektur nachvollziehbar und bewertbar machen [Seite 23]
4.3.3 - 1.3.3 Ziel.3: Umsetzung und Weiterentwicklung leiten [Seite 24]
4.3.4 - 1.3.4 Fremdwort Do|ku|men|ta|tion [.zion] [lat.] [Seite 24]
4.4 - 1.4 Mission Statement für dieses Buch [Seite 25]
4.5 - 1.5 Über dieses Buch [Seite 26]
4.5.1 - 1.5.1 Für wen ich dieses Buch geschrieben habe [Seite 26]
4.5.2 - 1.5.2 Wie dieses Buch aufgebaut ist [Seite 27]
4.5.3 - 1.5.3 Wem ich Dankeschön sagen möchte [Seite 31]
5 - 2Was Software­architektur ist und worauf sie aufbaut [Seite 32]
5.1 - 2.1 Softwarearchitektur-Freischwimmer [Seite 32]
5.1.1 - 2.1.1 Was ist Softwarearchitektur? [Seite 32]
5.1.2 - 2.1.2 Wie entsteht Softwarearchitektur? [Seite 33]
5.1.3 - 2.1.3 Wer oder was ist ein Softwarearchitekt? [Seite 36]
5.1.4 - 2.1.4 Ein Architekturüberblick auf n Seiten, n < 30 [Seite 38]
5.2 - 2.2 Die Zielsetzung vermitteln [Seite 38]
5.2.1 - 2.2.1 Jetzt kommt ein Karton! [Seite 38]
5.2.2 - 2.2.2 Virtueller Produktkarton (Dokumentationsmittel) [Seite 39]
5.2.3 - 2.2.3 Fallbeispiel: Schach-Engine "DokChess" [Seite 40]
5.2.4 - 2.2.4 Tipps zum Erstellen von Produktkartons [Seite 41]
5.2.5 - 2.2.5 Fallbeispiel: Schachplattform "immer-nur-schach.de" [Seite 42]
5.3 - 2.3 Den Kontext abgrenzen [Seite 43]
5.3.1 - 2.3.1 Systemkontext (Dokumentationsmittel) [Seite 44]
5.3.2 - 2.3.2 Fallbeispiel: Systemkontext "immer-nur-schach.de" [Seite 45]
5.3.3 - 2.3.3 Tipps zur Erstellung des Systemkontextes [Seite 46]
5.4 - 2.4 Im Rahmen bleiben [Seite 51]
5.4.1 - 2.4.1 Warum Randbedingungen festhalten? [Seite 51]
5.4.2 - 2.4.2 Randbedingungen (Dokumentationsmittel) [Seite 53]
5.4.3 - 2.4.3 Fallbeispiel: Randbedingungen "immer-nur-schach.de" [Seite 53]
5.4.4 - 2.4.4 Tipps zum Festhalten von Randbedingungen [Seite 54]
5.5 - 2.5 Geforderte Qualitätsmerkmale [Seite 56]
5.5.1 - 2.5.1 Was sind Qualitätsmerkmale? [Seite 57]
5.5.2 - 2.5.2 Qualitätsziele (Dokumentationsmittel) [Seite 58]
5.5.3 - 2.5.3 Fallbeispiel: Qualitätsziele "immer-nur-schach.de" [Seite 59]
5.5.4 - 2.5.4 Fallbeispiel: Qualitätsziele "DokChess" [Seite 59]
5.5.5 - 2.5.5 Qualitätsmerkmale genauer beschreiben [Seite 61]
5.5.6 - 2.5.6 Qualitätsszenarien (Dokumentationsmittel) [Seite 62]
5.5.7 - 2.5.7 Fallbeispiel: Qualitätsszenarien "immer-nur-schach.de" [Seite 63]
5.5.8 - 2.5.8 Tipps zum Festhalten von Qualitätsszenarien [Seite 65]
5.6 - 2.6 Weitere Einflüsse und Hilfsmittel [Seite 68]
5.6.1 - 2.6.1 Stakeholder [Seite 68]
5.6.2 - 2.6.2 Persona (Dokumentationsmittel) [Seite 69]
5.6.3 - 2.6.3 Fallbeispiel: Persona "immer-nur-schach.de" [Seite 70]
5.6.4 - 2.6.4 Risiken [Seite 72]
5.6.5 - 2.6.5 Technische Risiken (Dokumentationsmittel) [Seite 73]
5.6.6 - 2.6.6 Fallbeispiel: Technische Risiken "DokChess" [Seite 73]
5.6.7 - 2.6.7 Glossar (Dokumentationsmittel) [Seite 74]
6 - 3Entscheidungen treffen und festhalten [Seite 76]
6.1 - 3.1 Historisch gewachsen? [Seite 76]
6.2 - 3.2 Architekturentscheidungen [Seite 77]
6.2.1 - 3.2.1 Architekturentscheidung (Dokumentationsmittel) [Seite 77]
6.2.2 - 3.2.2 Fallbeispiel: Spannende Fragen "DokChess" [Seite 79]
6.2.3 - 3.2.3 Tipps zur Formulierung von Fragestellungen [Seite 79]
6.2.4 - 3.2.4 Fallbeispiel: Fragestellungen "immer-nur-schach.de" [Seite 81]
6.3 - 3.3 Einflussfaktoren auf Entscheidungen [Seite 85]
6.3.1 - 3.3.1 Den Überblick behalten [Seite 85]
6.3.2 - 3.3.2 Kreuztabellen [Seite 86]
6.3.3 - 3.3.3 Fallbeispiel: Einflüsse "immer-nur-schach.de" [Seite 87]
6.3.4 - 3.3.4 Tipps zur Anfertigung von Kreuztabellen [Seite 88]
6.4 - 3.4 Kompakte Darstellung der.Lösungsstrategie [Seite 89]
6.4.1 - 3.4.1 Softwarearchitektur auf einem Bierdeckel? [Seite 90]
6.4.2 - 3.4.2 Lösungsstrategie (Dokumentationsmittel) [Seite 90]
6.4.3 - 3.4.3 Fallbeispiel: Lösungsstrategie "DokChess" [Seite 92]
6.4.4 - 3.4.4 Als Ergänzung: ein Überblicksbild [Seite 93]
6.4.5 - 3.4.5 Eine Architekturbewertung auf dem Bierdeckel [Seite 93]
7 - 4Plädoyer für eine feste Gliederung [Seite 94]
7.1 - 4.1 Der jüngste Spieler fängt an! [Seite 94]
7.2 - 4.2 Vorteile einer festen Struktur [Seite 95]
7.3 - 4.3 arc42 - Vorschlag für eine Gliederung [Seite 97]
7.3.1 - 4.3.1 Was ist arc42? [Seite 97]
7.3.2 - 4.3.2 Die Struktur der arc42-Vorlage [Seite 98]
7.3.3 - 4.3.3 Wo funktioniert arc42 besonders gut? [Seite 100]
7.3.4 - 4.3.4 arc42 in diesem Buch [Seite 101]
7.4 - 4.4 Alternativen zu arc42 [Seite 102]
7.4.1 - 4.4.1 Standards zur Architekturbeschreibung [Seite 102]
7.4.2 - 4.4.2 Vorgehensmodelle [Seite 103]
7.4.3 - 4.4.3 Architektur-Frameworks [Seite 105]
7.4.4 - 4.4.4 Fachliteratur als Inspiration? [Seite 106]
8 - 5Sichten auf Softwarearchitektur [Seite 110]
8.1 - 5.1 Strukturen entwerfen und festhalten [Seite 110]
8.1.1 - 5.1.1 Was ist was? Band.127: Unser Softwaresystem [Seite 110]
8.1.2 - 5.1.2 Schritte der Zerlegung dokumentieren [Seite 111]
8.1.3 - 5.1.3 Bausteinsicht (Dokumentationsmittel) [Seite 112]
8.1.4 - 5.1.4 Fallbeispiel: Bausteinsicht "DokChess" (Ausschnitt) [Seite 113]
8.1.5 - 5.1.5 Komponenten: Babylonische Sprachverwirrung 2.0 [Seite 114]
8.1.6 - 5.1.6 Tipps zur Erstellung der Bausteinsicht [Seite 115]
8.1.7 - 5.1.7 Interaktionspunkte beschreiben [Seite 120]
8.1.8 - 5.1.8 Schnittstellenbeschreibung (Dokumentationsmittel) [Seite 123]
8.1.9 - 5.1.9 Fallbeispiel: Schnittstellen der Eröffnung in "DokChess" [Seite 125]
8.2 - 5.2 Verschiedene Blickwinkel [Seite 128]
8.2.1 - 5.2.1 Hat Mozart modelliert? [Seite 128]
8.2.2 - 5.2.2 Fachliche Zerlegung vs. technische Zerlegung [Seite 130]
8.2.3 - 5.2.3 Fallbeispiel: Bausteinsicht "immer-nur-schach.de" [Seite 132]
8.3 - 5.3 Verhalten und Abläufe beschreiben [Seite 135]
8.3.1 - 5.3.1 Abläufe in Entwurf und Dokumentation [Seite 135]
8.3.2 - 5.3.2 Darstellungen für Abläufe [Seite 135]
8.3.3 - 5.3.3 Laufzeitsicht (Dokumentationsmittel) [Seite 138]
8.3.4 - 5.3.4 Fallbeispiel: Ablauf in DokChess [Seite 139]
8.3.5 - 5.3.5 Fallbeispiel: Zustandsautomat XBoard (DokChess) [Seite 139]
8.4 - 5.4 Die Dinge zum Einsatz bringen [Seite 140]
8.4.1 - 5.4.1 Betriebsaspekte in der Architekturdokumentation [Seite 141]
8.4.2 - 5.4.2 Darstellungen für Verteilung [Seite 142]
8.4.3 - 5.4.3 Verteilungssicht (Dokumentationsmittel) [Seite 144]
8.4.4 - 5.4.4 Fallbeispiel: "immer-nur-schach.de" [Seite 146]
8.5 - 5.5 Alternative Vorschläge für Sichten [Seite 147]
8.6 - 5.6 Muster kommunizieren [Seite 150]
8.6.1 - 5.6.1 Muster in der Softwareentwicklung [Seite 150]
8.6.2 - 5.6.2 Wann sollte man Muster dokumentieren (und wo)? [Seite 151]
8.6.3 - 5.6.3 Einsatz von Mustern dokumentieren [Seite 151]
8.6.4 - 5.6.4 Fallbeispiel: DokChess [Seite 153]
9 - 6Übergreifende Konzepte [Seite 154]
9.1 - 6.1 Warum übergreifende Themen? [Seite 154]
9.2 - 6.2 Themen und Lösungsoptionen [Seite 155]
9.2.1 - 6.2.1 Mögliche Themen für übergreifende Konzepte [Seite 155]
9.2.2 - 6.2.2 Typische Lösungsoptionen [Seite 157]
9.3 - 6.3 Themenauswahl [Seite 159]
9.3.1 - 6.3.1 Wie wählt man Themen für die Dokumentation aus? [Seite 160]
9.3.2 - 6.3.2 Fallbeispiel: Übergreifende Themen "DokChess" [Seite 161]
9.4 - 6.4 Eine Gliederungstechnik für Konzepte [Seite 163]
9.4.1 - 6.4.1 Werkzeug: Warum? Was? Wie? Wohin noch? [Seite 163]
9.4.2 - 6.4.2 Gliederung für ein Konzept [Seite 165]
9.4.3 - 6.4.3 Informeller Text für den Architekturüberblick [Seite 167]
9.5 - 6.5 Tipps zur Erstellung übergreifender Konzepte [Seite 168]
10 - 7Werkzeuge zur Dokumentation [Seite 172]
10.1 - 7.1 Notationen passgenau wählen [Seite 172]
10.2 - 7.2 Toolparade zur Architekturdokumentation [Seite 177]
10.2.1 - 7.2.1 Erstellung und Pflege [Seite 177]
10.2.2 - 7.2.2 Verwaltung von Inhalten [Seite 183]
10.2.3 - 7.2.3 Kommunikation von Lösungen [Seite 185]
10.3 - 7.3 Repository: UML vs. Wiki [Seite 187]
10.3.1 - 7.3.1 Steht alles im Wiki? [Seite 188]
10.3.2 - 7.3.2 Steht alles im UML-Tool? [Seite 191]
10.3.3 - 7.3.3 UML-Tool + Wiki == Traumpaar? [Seite 194]
10.4 - 7.4 Wie auswählen? [Seite 195]
11 - 8Lightfäden für das Vorgehen zur Dokumentation [Seite 198]
11.1 - 8.1 Während der Entwicklung dokumentieren [Seite 198]
11.1.1 - 8.1.1 Zielgruppen Ihrer Dokumentation [Seite 198]
11.1.2 - 8.1.2 Dokumentationsmittel und Dokumente [Seite 201]
11.1.3 - 8.1.3 Womit anfangen? [Seite 204]
11.1.4 - 8.1.4 Während der Arbeit: Kommunizieren und Pflegen [Seite 205]
11.2 - 8.2 Der Softwaredetektiv: Bestehendes Dokumentieren [Seite 207]
11.2.1 - 8.2.1 Auslöser für Dokumentationsbedarf [Seite 207]
11.2.2 - 8.2.2 Mögliche Szenarien und Ziele des Dokumentierens im Nachhinein [Seite 208]
11.2.3 - 8.2.3 Sherlock Holmes vs. Die drei ??? [Seite 209]
11.2.4 - 8.2.4 Informationsquellen identifizieren [Seite 210]
11.2.5 - 8.2.5 Dokumentationsmittel unter der Lupe [Seite 211]
11.2.6 - 8.2.6 Exkurs: Werkzeuge zur Rekonstruktion [Seite 216]
11.3 - 8.3 Variationen von "Ein System" [Seite 221]
11.3.1 - 8.3.1 Dokumentation von Systemlandschaften [Seite 221]
11.3.2 - 8.3.2 Dokumentation von Frameworks und Blue Prints [Seite 223]
12 - 9Architekturüberblick DokChess [Seite 226]
12.1 - 9.1 Einführung und Ziele [Seite 227]
12.1.1 - 9.1.1 Aufgabenstellung [Seite 227]
12.1.2 - 9.1.2 Qualitätsziele [Seite 227]
12.1.3 - 9.1.3 Stakeholder [Seite 228]
12.2 - 9.2 Randbedingungen [Seite 231]
12.2.1 - 9.2.1 Technische Randbedingungen [Seite 231]
12.2.2 - 9.2.2 Organisatorische Randbedingungen [Seite 231]
12.2.3 - 9.2.3 Konventionen [Seite 232]
12.3 - 9.3 Kontextabgrenzung [Seite 233]
12.3.1 - 9.3.1 Fachlicher Kontext [Seite 233]
12.3.2 - 9.3.2 Technischer- oder Verteilungskontext [Seite 234]
12.4 - 9.4 Lösungsstrategie [Seite 235]
12.4.1 - 9.4.1 Aufbau von DokChess [Seite 236]
12.4.2 - 9.4.2 Spielstrategie [Seite 237]
12.4.3 - 9.4.3 Die Anbindung [Seite 237]
12.5 - 9.5 Bausteinsicht [Seite 238]
12.5.1 - 9.5.1 Ebene.1 [Seite 238]
12.5.2 - 9.5.2 XBoard-Protokoll (Blackbox) [Seite 239]
12.5.3 - 9.5.3 Spielregeln (Blackbox) [Seite 240]
12.5.4 - 9.5.4 Engine (Blackbox) [Seite 241]
12.5.5 - 9.5.5 Eröffnung (Blackbox) [Seite 242]
12.5.6 - 9.5.6 Ebene.2: Engine (Whitebox) [Seite 244]
12.5.7 - 9.5.7 Zugsuche (Blackbox) [Seite 244]
12.5.8 - 9.5.8 Stellungsbewertung (Blackbox) [Seite 246]
12.6 - 9.6 Laufzeitsicht [Seite 247]
12.6.1 - 9.6.1 Zugermittlung Walkthrough [Seite 247]
12.7 - 9.7 Verteilungssicht [Seite 248]
12.7.1 - 9.7.1 Infrastruktur Windows [Seite 248]
12.8 - 9.8 Konzepte [Seite 250]
12.8.1 - 9.8.1 Abhängigkeiten zwischen Modulen [Seite 250]
12.8.2 - 9.8.2 Schach-Domänenmodell [Seite 250]
12.8.3 - 9.8.3 Benutzungsoberfläche [Seite 252]
12.8.4 - 9.8.4 Plausibilisierung und Validierung [Seite 253]
12.8.5 - 9.8.5 Ausnahme- und Fehlerbehandlung [Seite 254]
12.8.6 - 9.8.6 Logging, Protokollierung, Tracing [Seite 254]
12.8.7 - 9.8.7 Testbarkeit [Seite 255]
12.9 - 9.9 Entwurfsentscheidungen [Seite 257]
12.9.1 - 9.9.1 Wie kommuniziert die Engine mit der Außenwelt? [Seite 257]
12.9.2 - 9.9.2 Sind Stellungsobjekte veränderlich oder nicht? [Seite 259]
12.10 - 9.10 Qualitätsszenarien [Seite 262]
12.10.1 - 9.10.1 Qualitätsbaum [Seite 262]
12.10.2 - 9.10.2 Bewertungsszenarien [Seite 263]
12.11 - 9.11 Risiken [Seite 264]
12.11.1 - 9.11.1 Risiko: Anbindung an das Frontend [Seite 264]
12.11.2 - 9.11.2 Risiko: Aufwand der Implementierung [Seite 264]
12.11.3 - 9.11.3 Risiko: Erreichen der Spielstärke [Seite 265]
12.12 - 9.12 Glossar [Seite 266]
13 - 10Stolpersteine der Architektur­dokumentation [Seite 268]
13.1 - 10.1 Probleme [Seite 268]
13.2 - 10.2 Fiese Fallen . [Seite 270]
13.3 - 10.3 . und wie man sie umgeht oder entschärft [Seite 272]
13.4 - 10.4 Reviews von Architekturdokumentation [Seite 273]
14 - Glossar [Seite 280]
15 - Literaturverzeichnis [Seite 284]
16 - Stichwortverzeichnis [Seite 288]

Dateiformat: PDF
Kopierschutz: Wasserzeichen-DRM (Digital Rights Management)

Systemvoraussetzungen:

Computer (Windows; MacOS X; Linux): Verwenden Sie zum Lesen die kostenlose Software Adobe Reader, Adobe Digital Editions oder einen anderen PDF-Viewer Ihrer Wahl (siehe E-Book Hilfe).

Tablet/Smartphone (Android; iOS): Installieren Sie die kostenlose App Adobe Digital Editions oder eine andere Lese-App für E-Books (siehe E-Book Hilfe).

E-Book-Reader: Bookeen, Kobo, Pocketbook, Sony, Tolino u.v.a.m. (nur bedingt: Kindle)

Das Dateiformat PDF zeigt auf jeder Hardware eine Buchseite stets identisch an. Daher ist eine PDF auch für ein komplexes Layout geeignet, wie es bei Lehr- und Fachbüchern verwendet wird (Bilder, Tabellen, Spalten, Fußnoten). Bei kleinen Displays von E-Readern oder Smartphones sind PDF leider eher nervig, weil zu viel Scrollen notwendig ist. Mit Wasserzeichen-DRM wird hier ein "weicher" Kopierschutz verwendet. Daher ist technisch zwar alles möglich - sogar eine unzulässige Weitergabe. Aber an sichtbaren und unsichtbaren Stellen wird der Käufer des E-Books als Wasserzeichen hinterlegt, sodass im Falle eines Missbrauchs die Spur zurückverfolgt werden kann.

Weitere Informationen finden Sie in unserer E-Book Hilfe.


Download (sofort verfügbar)

27,99 €
inkl. 7% MwSt.
Download / Einzel-Lizenz
PDF mit Wasserzeichen-DRM
siehe Systemvoraussetzungen
E-Book bestellen