arc42 in Aktion

Praktische Tipps zur Architekturdokumentation
 
 
Hanser (Verlag)
  • 1. Auflage
  • |
  • erschienen am 11. Juli 2016
  • |
  • 198 Seiten
 
E-Book | PDF mit Wasserzeichen-DRM | Systemvoraussetzungen
978-3-446-44938-1 (ISBN)
 
Der Praxiseinsatz von arc42 - dem Template für Softwarearchitekturen

Sie finden konkrete Maßnahmen und Praktiken, um arc42 sowohl zur effektiven Kommunikation und Dokumentation wie auch zur Konstruktion und Entwicklung von Systemen anzuwenden.

Unmittelbarer Nutzen für die tägliche Arbeit

Softwarearchitekten und -entwickler ziehen daraus unmittelbaren Nutzen für ihre tägliche Arbeit.
  • Deutsch
  • München
  • |
  • Deutschland
  • 6,30 MB
978-3-446-44938-1 (9783446449381)
http://dx.doi.org/10.3139/9783446449381
weitere Ausgaben werden ermittelt
Dr. Gernot Starke stellt sich seit 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 Finanzdienstleistung, Logistik, Handel, Telekommunikation und dem öffentlichen Bereich. Er ist Mitinitiator und -betreiber von arc42, Mitgründer des iSAQB e.V. sowie Fellow der innoQ.

Peter Hruschka ist Partner der Atlantic Systems Guild (www.systemsguild.com), einer international renommierten Gruppe von Methodenberatern, Trainern und Buchautoren. Er ist auch Gründer des Netzwerks b-agile (www.b-agile.de). Seine Mission ist seit mehr als 35 Jahren der pragmatische Wissenstransfer von effektiveren und produktiveren Methoden zur Projektabwicklung. Er ist Gründungs- und Board-Mitglied der Vereine zur Zertifizierung von Requirements Engineers (IREB e.V.) und Softwarearchitekten (ISAQB e.V.).
1 - Inhalt [Seite 6]
2 - IÜberblick [Seite 10]
2.1 - I.1?Grundprinzipien von arc42 [Seite 11]
2.2 - I.2?Warum dieses Buch? [Seite 13]
2.3 - I.3?Was dieses Buch nicht ist [Seite 14]
2.4 - I.4?Unsere Annahmen über Sie . [Seite 15]
2.5 - I.5?Navigationshilfe für Eilige [Seite 15]
2.6 - I.6?Konventionen [Seite 16]
2.7 - I.7?Danke [Seite 17]
3 - IIarc42 am Beispiel [Seite 18]
3.1 - 1?Einführung und Ziele [Seite 18]
3.1.1 - 1.1?Aufgabenstellung [Seite 18]
3.1.2 - 1.2?Qualitätsanforderungen [Seite 21]
3.1.3 - 1.3?Stakeholder [Seite 21]
3.2 - 2?Randbedingungen [Seite 22]
3.3 - 3?Kontext [Seite 22]
3.3.1 - 3.1?Fachlicher Kontext [Seite 23]
3.3.2 - 3.2?Technischer Kontext/Verteilungskontext [Seite 24]
3.4 - 4?Lösungsstrategie [Seite 25]
3.5 - 5?Bausteinsicht [Seite 26]
3.5.1 - 5.1Whitebox Gesamtsystem (Level?1) [Seite 26]
3.5.1.1 - 5.1.1?Blackbox "HSC Core" [Seite 27]
3.5.1.2 - 5.1.2?Blackbox "HSC Gradle Plugin" [Seite 27]
3.5.2 - 5.2?Bausteinsicht Level?2 [Seite 28]
3.5.2.1 - 5.2.1?Whitebox HSC Core [Seite 28]
3.5.3 - 5.3?Bausteinsicht Level?3 [Seite 29]
3.5.3.1 - 5.3.1?Whitebox Results Collector [Seite 29]
3.5.3.2 - 5.3.2?Suggester [Seite 30]
3.6 - 6?Laufzeitsicht [Seite 31]
3.6.1 - 6.1?Ausführen aller Prüfalgorithmen ("perform all checks") [Seite 31]
3.6.2 - 6.2?Reporting von Prüfergebnissen [Seite 32]
3.7 - 7?Verteilungssicht [Seite 33]
3.8 - 8?Querschnittliche Konzepte [Seite 35]
3.8.1 - 8.1?Fachliches Modell [Seite 35]
3.8.2 - 8.2?Aufbau von UR (HTML-Verweise) [Seite 36]
3.8.3 - 8.3?Entwicklung des Gradle-Plug-ins [Seite 37]
3.8.4 - 8.4?Erweiterbarkeit um neue Prüf- oder Reporting-Verfahren [Seite 38]
3.9 - 9?Entwurfsentscheidungen [Seite 39]
3.9.1 - 9.1?Prüfung externer Links verschoben [Seite 39]
3.9.2 - 9.2?JSOUP als HTML-Parser [Seite 39]
3.9.2.1 - 9.2.1?Entscheidungskriterien [Seite 39]
3.9.2.2 - 9.2.2?Alternativen [Seite 39]
3.10 - 10?Qualitätsszenarien [Seite 40]
3.10.1 - 10.1?Qualitätsbaum [Seite 40]
3.10.2 - 10.2?Qualitätsszenarien [Seite 40]
3.11 - 11?Risiken & technische Schulden [Seite 41]
3.11.1 - 11.1?Betriebs-/Deployment-Risiken [Seite 41]
3.11.2 - 11.2?Fachliche Risiken [Seite 41]
3.12 - 12?Glossar [Seite 42]
4 - IIIGrundregeln effektiver Dokumentation [Seite 44]
4.1 - III.1?Anforderungen an die Dokumentation [Seite 44]
4.2 - III.2?Zentrale Tipps für eine effektive Dokumentation [Seite 46]
5 - IVarc42 effektiv einsetzen [Seite 52]
5.1 - 1?Einführung und Ziele [Seite 53]
5.1.1 - 1.1?Aufgabenstellung [Seite 53]
5.1.2 - 1.2?Qualitätsziele [Seite 57]
5.1.3 - 1.3?Stakeholder [Seite 61]
5.2 - 2?Randbedingungen [Seite 64]
5.3 - 3?Kontextabgrenzung [Seite 65]
5.3.1 - 3.1?Fachlicher Kontext [Seite 72]
5.3.2 - 3.2?Technischer Kontext [Seite 74]
5.4 - 4?Lösungsstrategie [Seite 76]
5.5 - 5?Bausteinsicht [Seite 79]
5.6 - 6?Laufzeitsicht [Seite 94]
5.7 - 7?Verteilungssicht [Seite 101]
5.8 - 8?Querschnittliche Konzepte [Seite 107]
5.9 - 9?Entwurfsentscheidungen [Seite 113]
5.10 - 10?Qualitätsszenarien [Seite 116]
5.11 - 11?Risiken und technische Schulden [Seite 120]
5.12 - 12?Glossar [Seite 121]
6 - Varc42 im Alltag [Seite 124]
6.1 - V.1?Guter Start mit arc42 [Seite 125]
6.2 - V.2?arc42 für bestehende Systeme [Seite 129]
6.3 - V.3?Mit arc42 auf der grünen Wiese [Seite 133]
6.4 - V.4?arc42 für agile Projekte [Seite 135]
6.5 - V.5?arc42 für sehr große Systeme [Seite 136]
7 - VIWerkzeuge für arc42 [Seite 140]
7.1 - VI.1?Anforderungen an Werkzeuge [Seite 140]
7.2 - VI.2?Modellierungswerkzeuge [Seite 143]
7.2.1 - VI.2.1?Grafische Modellierungswerkzeuge [Seite 145]
7.2.2 - VI.2.2?Enterprise-ArchitectT (Sparx Systems) [Seite 146]
7.2.3 - VI.2.3?Visual ParadigmT [Seite 150]
7.2.4 - VI.2.4?PlantUML [Seite 151]
7.2.5 - VI.2.5?Weitere Modellierungswerkzeuge [Seite 152]
7.3 - VI.3?Zeichenwerkzeuge [Seite 153]
7.3.1 - VI.3.1?Online-/Browser-Werkzeuge [Seite 153]
7.4 - VI.4?Wikis [Seite 155]
7.4.1 - VI.4.1?ConfluenceT [Seite 156]
7.4.2 - VI.4.2?Sonstige Wikis [Seite 157]
7.5 - VI.5?Markup- oder Makrosprachen [Seite 157]
7.5.1 - VI.5.1?AsciiDoc/AsciiDoctor [Seite 158]
7.5.2 - VI.5.2?Andere Markup-Sprachen [Seite 163]
7.5.3 - VI.5.3?DITA [Seite 163]
7.6 - VI.6?Textverarbeitung [Seite 164]
7.7 - VI.7?Mindmapping-Werkzeuge [Seite 165]
7.8 - VI.8?Empfehlungen [Seite 167]
8 - VIIFAQ: Häufige Fragen zu arc42 [Seite 168]
8.1 - VII.1?Allgemeines zu arc42 [Seite 169]
8.2 - VII.2?Fragen zu arc42-Methodik [Seite 171]
8.3 - VII.3?Fragen zu arc42-Abschnitten [Seite 173]
8.3.1 - VII.3.1?Ad?1: Aufgabenstellung, Qualitätsziele, Stakeholder [Seite 173]
8.3.2 - VII.3.2?Ad?2: Randbedingungen [Seite 175]
8.3.3 - VII.3.3?Ad?3: Kontextabgrenzung [Seite 175]
8.3.4 - VII.3.4?Ad?4: Lösungsstrategie [Seite 176]
8.3.5 - VII.3.5?Ad?5: Bausteinsicht [Seite 177]
8.3.6 - VII.3.6?Ad?6: Laufzeitsicht [Seite 180]
8.3.7 - VII.3.7?Ad?7: Verteilungssicht [Seite 181]
8.3.8 - VII.3.8?Ad?8: Konzepte [Seite 182]
8.3.9 - VII.3.9?Ad?9: Entscheidungen [Seite 182]
8.4 - VII.4?Fragen zur Modellierung [Seite 183]
8.4.1 - VII.4.1?Nutzung von UML [Seite 183]
8.4.2 - VII.4.2?Alternativen zu UML [Seite 185]
8.4.3 - VII.4.3?Hardwaremodellierung [Seite 186]
8.4.4 - VII.4.4?Verständliche und konsistente Modelle [Seite 186]
8.5 - VII.5?arc42 und agiles Vorgehen [Seite 187]
8.6 - VII.6?Fragen zu Werkzeugen [Seite 188]
8.7 - VII.7?Fragen zu Versionen & Varianten [Seite 190]
8.8 - VII.8?Fragen zu Traceability [Seite 191]
8.9 - VII.9?Fragen zu Projekten und Projektmanagement [Seite 192]
8.10 - VII.10?Fragen zu spezifischen Anpassungen (Customizing) von arc42 [Seite 194]
9 - Literatur und Quellen [Seite 196]
10 - Stichwortverzeichnis [Seite 198]

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)

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