arc42 Der pragmatische Leitfaden zur Architekturdokumentation

Transkript

1 arc42 Der pragmatische Leitfaden zur Architekturdokumentation STEFAN ZÖRNER.NET Developer Conference kompakt Köln, arc 42 Der pragmatische Leitfaden zur Architekturdokumentation Sie: Ein Entwickler(-Team), das die konzeptionellen Ideen und technischen Eckpfeiler seiner Lösung festhalten möchte. arc42: Eine etablierte Gliederungsstruktur für Architekturbeschreibungen. Klingt nach "passt prima", und ist es im Grunde auch. Wenn man nur weiss wie. In dieser Session erfahren Sie, wann und warum Sie Softwarearchitektur überhaupt dokumentieren sollten (denn Hand aufs Herz: wer dokumentiert schon gern? ;-). Sie bekommen Orientierung, wie Sie Softwarearchitektur mit Hilfe von arc42 festhalten. Und Sie gewinnen ein Bild wie arc42-elemente Sie gleichzeitig beim Entwerfen und Reflektieren von Softwarearchitektur unterstützen können. Denn Dokumentation ist kein Selbstzweck. Gut gemachte Architekturdokumentation macht Ihre Lösungen nachvollziehbar, und damit überhaupt erst bewertbar. Wider das Vergessen -- "Historisch gewachsen" kann jeder. 2 1

2 Agenda 1 Intro 2 Architekturrelevante Anforderungen 3 Die Lösung festhalten 4 Reflektieren und bewerten 5 Fazit und weitere Informationen. 3 Stefan Zörner n Softwareentwickler + -architekt bei embarc in Hamburg n Vorher oose, IBM, Mummert + Partner, Bayer AG, Schwerpunkte: n Softwarearchitektur (Entwurf, Bewertung, Dokumentation) n Java Technologien xing.to/szr 4 2

3 Agenda 1 Intro 2 Architekturrelevante Anforderungen 3 Die Lösung festhalten 1 4 Reflektieren und bewerten 5 Fazit und weitere Informationen. 5 Was ist arc42? (für die ganz ungeduldigen...) Vorschlag zur Gliederung von (Software-)Architekturbeschreibungen Initiiert von Peter Hruschka und Gernot Starke, zuerst vorgelegt 2005 Frei verfügbar (Create Commons), De-facto-Standard in D-A-CH è 6 3

4 Struktur arc42 (Version 6.0) 7 Lageplan arc42. Einführung und Ziele Randbedingungen Kontextabgrenzung Unsere Tour startet hier. Lösungsstrategie Überblick über die Sammlungen: Sichten Konzepte Entscheidungen Architekturrelevante Anforderungen Entwurf der Lösung Qualitätsszenarien Risiken Bewertung der Lösung Glossar Glossar 8 4

5 Auf den Punkt gebracht Softwarearchitektur := wichtige Entscheidungen wichtige Entscheidungen := n fundamental n im weiteren Verlauf nur schwer zu ändern n entscheidend für den Projekterfolg. Software architecture is about the important stuff, whatever that is. (Martin Fowler) 9 Dokumentation als Fremdwort Do ku men ta ti on [ zion] [lat.] die; -, -en: 1. a) Zusammenstellung u. Ordnung von Dokumenten und Materialien jeder Art, durch die das Benutzen und Auswerten ermöglicht oder erleichtert wird 10 5

6 Die halbe Wahrheit The code doesn t tell the whole story.. (Simon Brown) Simon Brown: Software Architecture for Developers Technical leadership by coding, coaching, collaboration, architecture sketching and just enough up front design è 11 Architekturdokumentation: Ziele. n Beim Entwurf der Architektur unterstützen n Die Umsetzung und Weiterentwicklung des Systems leiten n Die Architektur nachvollziehbar und bewertbar machen 12 6

7 Was ist arc42? (für die ganz ungeduldigen...) Vorschlag zur Gliederung von (Software-)Architekturbeschreibungen Initiiert von Peter Hruschka und Gernot Starke, zuerst vorgelegt 2005 Frei verfügbar (Create Commons), De-facto-Standard in D-A-CH è 13 Agenda 1 Intro 2 Architekturrelevante Anforderungen 3 Die Lösung festhalten 2 4 Reflektieren und bewerten 5 Fazit und weitere Informationen. 14 7

8 Lageplan arc42. Einführung und Ziele Randbedingungen Kontextabgrenzung Architekturrelevante Anforderungen

9 Systemkontext Der Systemkontext (alternativ: Kontextsicht, Kontextabgrenzung) zeigt das Umfeld, d.h. alle außerhalb des eigenen Systems liegenden Benutzer und Fremdsysteme, mit denen direkt kommuniziert wird. 17 Ein Bild ist nicht genug... Einleitender Text Diagramm mit Legende Erläuterungen zu den Akteuren (z.b. tabellarisch) 18 9

10 Zutat Systemkontext! n Ein guter Einstieg in ein System grenzt es zunächst von der Umgebung ab. Mit wem interagieren wir, und warum? 19 Lageplan arc42. Abschnitt Kontextabgrenzung Einführung und Ziele Randbedingungen Kontextabgrenzung Architekturrelevante Anforderungen 20 10

11 Beispiel: Matt-Ansage per UI 21 Eine Frage der Balance... Benutzbarkeit Effizienz 22 11

12 23 Wechselwirkungen Die Erreichung von Qualitätsmerkmalen ist oft nicht unabhängig voneinander. Typische Beeinflussungen: Effizienz çè Wartbarkeit Sicherheit çè Benutzbarkeit Portierbarkeit çè Effizienz Zuverlässigkeit çè Kosten 24 12

13 Qualitätsziele Die wichtigsten geforderten Qualitätsmerkmale für ein Softwaresystem heißen Qualitätsziele (oder Architekturziele). Typischerweise werden als Qualitätsziele im Rahmen eines Architekturüberblicks die Top-3 bis Top-5 genannt. 25 Qualitätsziele Beispiel: immer-nur-schach.de Qualitätsmerkmal Ziel Benutzbarkeit Zuverlässigkeit Wartbarkeit Unsere Mitglieder verbringen auf immer-nur-schach.de ihre Freizeit, und wollen dies mit Freude tun. Begeistert berichten sie in sozialen Medien über unsere attraktive Plattform. Frustrationen in diesem Bereich hingegen würden ihnen den Spaß am Schach verleiden, und sie schnell zur Konkurrenz treiben. immer-nur-schach.de lockt insbesondere auch Spitzen- und Vielspieler auf die Plattform. Diese spielen gerne rund um die Uhr, akzeptieren kaum, wenn unsere Seite "mal wieder nicht da" ist, oder eine hochklassige Partie, in die sie Stunden an Denkarbeit investiert haben, abschmiert. Benutzbarkeit: Unsere Mitglieder verbringen auf immer-nur-schach.de ihre Freizeit, und wollen dies mit Freude tun. Begeistert berichten sie in sozialen Medien über unsere attraktive Plattform. Frustrationen in diesem Bereich hingegen würden ihnen den Spaß am Schach verleiden, und sie schnell zur Konkurrenz treiben. immer-nur-schach.de ist auch langfristig eine attraktive Plattform. Technologische Trends und auch gute Anregungen und Wünsche unserer Mitglieder nehmen wir auf, und setzen sie zeitnah um

14 Lageplan arc42. Abschnitt 1.2.: 1. Einführung und Ziele 1.2 Qualitätsziele Einführung und Ziele Randbedingungen Kontextabgrenzung Architekturrelevante Anforderungen 27 Randbedingungen sind Vorgaben, die einzuhalten sind, und durch die Optionen für Entscheidungen wegfallen.... unterstützen beim Treffen von Entscheidungen, und dabei sie nachzuvollziehen. Organisatorische Randbedingungen Technologische Randbedingungen 28 14

15 Wir sind hier Architekturrelevante Anforderungen Einführung und Ziele Randbedingungen Kontextabgrenzung Was haben wir erlebt? 1.2 Qualitätsziele 3. Kontextabgrenzung 29 Wohin noch? Architekturrelevante Anforderungen Einführung und Ziele Randbedingungen Kontextabgrenzung Weiteres Highlight der Sammlung Aufgabenstellung? (später noch Informationen dazu...) 30 15

16 Agenda 1 Intro 2 Architekturrelevante Anforderungen 3 Die Lösung festhalten 3 4 Reflektieren und bewerten 5 Fazit und weitere Informationen. 31 Lageplan arc42. Entwurf der Lösung Einführung und Ziele Randbedingungen Kontextabgrenzung Lösungsstrategie Sichten Konzepte Entscheidungen 32 16

17 Lösungsstrategie Lösungsstrategie Sichten Konzepte Entscheidungen Schnellen Einstieg und Überblick in die Lösung geben Brücke schlagen zwischen Anforderungen und Lösung Wege Aufzeigen in Details der Lösung 33 Kompakte Darstellung Lösungsstrategie Qualitätsziel Architekturansatz QZ 1 Ansatz a) Ansatz b) QZ 2 Ansatz c) QZ 3 Ansatz d) QZ 4 Ansatz a) Ansatz e)

18 Typische Architekturansätze Technologieentscheidungen Programmiersprachen Bibliotheken und Frameworks Applikationsserver und andere Middleware Generierung (MDx) AOP... Gesetzte Rahmenbedingungen (wenn sie gut passen) Architekturmuster Architekturprinzipien Präferenzen Zerlegungsstrategien Konzepte für übergreifende Themen Best Practices (z.b. Caching) Kompakte Darstellung Lösungsstrategie Qualitätsziel Architekturansatz QZ 1 Ansatz a) Ansatz b) QZ 2 Ansatz c) QZ 3 Ansatz d) QZ 4 Ansatz a) Ansatz e)... Ziele aus arc42, Abschitt 1.2 Mit Verweisen auf Entscheidungen, Konzepte, Sichten

19 Lageplan arc42. Abschnitt 4.: 4. Lösungsstrategie Einführung und Ziele Randbedingungen Kontextabgrenzung Entwurf der Lösung Lösungsstrategie Sichten Konzepte Entscheidungen 37 Softwarearchitektur eine (!) Definition Softwarearchitektur ist die Menge der Entwurfsentscheidungen, die, wenn falsch getroffen, Dein Projekt zum Scheitern bringen kann. * (Eoin Woods) * Wörtlich: Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled

20 Gebrauchstauglichkeit 7 Regeln für gute Dokumentation 1. Schreibe aus Sicht des Lesers 2. Vermeide unnötige Wiederholungen 3. Vermeide Mehrdeutigkeiten 3. a) Erkläre Deine Notation 4. Verwende eine Standardstrukturierung 5. Halte Begründungen für Entscheidungen fest 6. Halte Dokumentation aktuell, aber auch nicht zu aktuell Documenting Software Architectures: Views and Beyond Clements, et.al, 2. Auflage Überprüfe Dokumentation auf ihre 39 Gebrauchstauglichkeit 7 Regeln für gute Dokumentation 1. Schreibe aus Sicht des Lesers 2. Vermeide unnötige Wiederholungen 3. Vermeide Mehrdeutigkeiten 3. a) Erkläre Deine Notation 4. Verwende eine Standardstrukturierung 5. Halte Begründungen für Entscheidungen fest 6. Halte Dokumentation aktuell, aber auch nicht zu aktuell Documenting Software Architectures: Views and Beyond Clements, et.al, 2. Auflage Überprüfe Dokumentation auf ihre 40 20

21 Entscheidungen treffen und festhalten Ein Werkzeug. 41 Leitfragen pro Unterkapitel 42 21

22 Lageplan arc42. Abschnitt 9.: 9. Entwurfsentscheidungen Einführung und Ziele Randbedingungen Kontextabgrenzung Entwurf der Lösung Lösungsstrategie Sichten Konzepte Entscheidungen 43 Zutat Architekturentscheidung! Zentrale Entscheidungen nachvollziehbar festhalten ist der Schlüssel, um bessere Antworten zu haben als Historisch gewachsen. n Sich an der Entscheidungsmindmap entlang zu hangeln gibt Orientierung

23 "e2e4" "move b8c6" «subsystem» «subsystem» Spielregeln ziehen(e2-e4) ziehen(b8-c6) «subsystem» Engine lieferezug «subsystem» Eröffnung Systemkontext und Zerlegung Blackbox Whitebox 45 Sichten auf Softwarearchitektur XBoard Client XBoard-Protokoll ermittlegueltigezuege ermittledeinenzug ermittlegueltigezuege Zug b8 - c6 null 6. Laufzeitsicht 7. Verteilungssicht 46 23

24 Übergreifende Themen 8. Konzepte 47 Wir sind hier Entwurf der Lösung Einführung und Ziele Randbedingungen Kontextabgrenzung Was haben wir erlebt? Lösungsstrategie Sichten Konzepte Entscheidungen 4. Lösungsstrategie 9. Entwurfsentscheidungen 48 24

25 Agenda 1 Intro 2 Architekturrelevante Anforderungen 3 Die Lösung festhalten 4 4 Reflektieren und bewerten 5 Fazit und weitere Informationen. 49 Lageplan arc42. Bewertung der Lösung Qualitätsszenarien Risiken 50 25

26 Qualitätsziele Beispiel: immer-nur-schach.de Qualitätsmerkmal Ziel Benutzbarkeit Zuverlässigkeit Wartbarkeit Benutzbarkeit: Unsere Mitglieder verbringen auf immer-nur-schach.de ihre Freizeit, und wollen dies mit Freude tun. Begeistert berichten sie in sozialen Medien über unsere attraktive Plattform. Frustrationen in diesem Bereich hingegen würden ihnen den Spaß am Schach verleiden, und sie schnell zur Konkurrenz treiben. Unsere Mitglieder verbringen auf immer-nur-schach.de ihre Freizeit, und wollen dies mit Freude tun. Begeistert berichten sie in sozialen Medien über unsere attraktive Plattform. Frustrationen in diesem Bereich hingegen würden ihnen den Spaß am Schach verleiden, und sie schnell zur Konkurrenz treiben. Wartbarkeit: immer-nur-schach.de ist auch langfristig eine attraktive Plattform. Technologische Trends und auch gute Anregungen und Wünsche unserer Mitglieder nehmen wir auf, und setzen sie zeitnah um immer-nur-schach.de lockt insbesondere auch Spitzen- und Vielspieler auf die Plattform. Diese spielen gerne rund um die Uhr, akzeptieren kaum, wenn unsere Seite "mal wieder nicht da" ist, oder eine hochklassige Partie, in die sie Stunden an Denkarbeit investiert haben, abschmiert. immer-nur-schach.de ist auch langfristig eine attraktive Plattform. Technologische Trends und auch gute Anregungen und Wünsche unserer Mitglieder nehmen wir auf, und setzen sie zeitnah um. 51 Konkretisierung durch Szenarien Ein Szenario ist ein Beispiel für die Verwendung des Systems, bei dem ein Qualitätsmerkmal die Hauptrolle spielt. Ein Spieler schließt während einer laufenden Online- Partie seinen Webbrowser. Nach Neustart des Browsers und Anmeldung kann er das Spiel fortsetzen. Ein Spieler setzt seinen Gegner bei einer Online-Partie matt. Beide werden darüber maximal zwei Sekunden später informiert. Ein Entwickler will eine neue Sprache (z.b. Spanisch) für die Weboberfläche unterstützen. Sein Aufwand liegt (bei vorliegenden Übersetzungen) unter einem Personentag

27 Konkretisierung durch Szenarien Typische Bestandteile eines Qualitätsszenarios: Quelle Antwort-Maß Ein angemeldeter Schachpolizist ruft den Bericht zu verdächtigen Spielern auf, und erhält das Ergebnis innerhalb von 10 Sekunden. 53 Ausblick: Architekturbewertung ATAM Architecture tradeoff analysis method n verbreitetste Methode zur Bewertung von Softwarearchitektur n früh anwendbar n szenarienbasiert Ergebnisse und Ziele n Risiken n Kompromisse n Sicherheit und Transparanz 54 27

28 Lageplan arc42. Abschnitt 10.: 10.2 Qualitätsszenarien Einführung und Ziele Randbedingungen Kontextabgrenzung Bewertung derlösung Lösung Entwurf der Lösungsstrategie Sichten Qualitätsszenarien Konzepte Entscheidungen Risiken 55 Risikogetriebene Softwarearchitektur You should pay as much attention to software architecture as it contributes risk to the overall project, since if there is little architecture risk, then optimizing it only helps little. (George Fairbanks) Just enough Software Architecture A risk-driven approach 56 28

29 Agenda 1 Intro 2 Architekturrelevante Anforderungen 3 Die Lösung festhalten 5 4 Reflektieren und bewerten 5 Fazit und weitere Informationen. 57 tl;dr Softwarearchitektur beschäftigt sich mit grundlegenden, später schwer änderbaren Entscheidungen. Um diese nachvollziehbar festzuhalten müssen neben der Lösung auch die Einflussfaktoren festgehalten werden, welche die Architektur form(t)en. arc42 liefert Orientierung und einen guten Startpunkt dazu, und hilft Eure Ergebnisse in Ordnung zu halten

30 Einführung und Ziele Randbedingungen Kontextabgrenzung Lösungsstrategie Überblick über die Sammlungen: Sichten Konzepte Entscheidungen Architekturrelevante Anforderungen Entwurf der Lösung Qualitätsszenarien Risiken Bewertung der Lösung Glossar Glossar 59 Struktur arc42 (Version 6.0) 60 30

31 Softwarearchitekturen dokumentieren und kommunizieren Entwürfe, Entscheidungen und Lösungen nachvollziehbar und wirkungsvoll festhalten Autor: Stefan Zörner Umfang: ca. 280 Seiten Verlag: Carl Hanser Verlag, 2012 Sprache: Deutsch ISBN: Wohin noch? Architekturrelevante Anforderungen Einführung und Ziele Randbedingungen Kontextabgrenzung Weiteres Highlight der Sammlung Aufgabenstellung? (später noch Informationen dazu...) 62 31

32

33 Blog-Serie bei Hanser Update è update.hanser-fachbuch.de/tag/arc42-starschnitt/ 65 Schnipsel Nr. 1: Produktkarton Schnipsel Nr. 2: Systemkontext Einführung und Ziele Randbedingungen Kontextabgrenzung Schnipsel Nr. 8: Randbedingungen Schnipsel Nr. 3: Qualitätsziele Schnipsel Nr. 9: Lösungsstrategie Konzepte Schnipsel Nr. 4: Bausteinsicht Sichten Konzepte Entscheidungen Schnipsel Nr. 5: Entscheidungen Schnipsel Nr. 7: Qualitätsszenarien Qualitätsszenarien Glossar Risiken Schnipsel Nr. 6: Grafisches Glossar 66 33

34 Vielen Dank. Ich freue mich auf Eure xing.to/szr DOWNLOAD FOLIEN: 34