arc42 Reality Check: Praxiseinsatz, Beispiele, Werkzeuge

presented at #jaxcon 2015 in Mainz (Germany), slides in German
Keywords:

arc42, architecture documentation, template, pragmatic,
examples

Transcript

1. Reality  Check   Praxiseinsatz,  Werkzeuge,     Add-­‐Ons     Dr.  Gernot  Starke   April  2015  
2. Dr.  Gernot  Starke   innoQ  Fellow     Softwarearchitekturen Entwurf, Entwicklung, Management Evolution & Modernisierung Training   Mentoring und Coaching Analyse und Optimierung von Entwicklungsprozessen   Reviews, Audits, Retrospektiven +49 177 – 728 2570 gs@gernotstarke.de www.arc42.de
3. Was  ist  arc42?  
4. Behälter  für  Architektur-­‐Info   Anforderungen   Entscheidungen   Strukturen  von   Sourcecode  
5. Wie  sieht‘s  aus?  
6. AuMau  
8. AuMau  von   arc42, Version 6, Stand März 2012. © Dr. Peter Hruschka und Dr. Gernot Starke. Frei für kommerzielle und private Nutzung. 1. Einführung und Ziele 1.1 Aufgabenstellung 1.2 Qualitätsziele 1.3 Stakeholder 7.Verteilungssicht 7.1 Infrastruktur Ebene 1 7.2 Infrastruktur Ebene 2 …. 2. Randbedingungen 2.1 Technische Randbedingungen 2.2 Organisatorische Randbedingungen 2.3 Konventionen 3. Kontextabgrenzung 3.1 Fachlicher Kontext 3.2 Technischer- oder Verteilungskontext 4. Lösungsstrategie 5. Bausteinsicht 5.1 Ebene 1 5.2 Ebene 2 …. 6. Laufzeitsicht 6.1 Laufzeitszenario 1 6.2 Laufzeitszenario 2 …. 8. Konzepte 8.1 Fachliche Struktur und Modelle 8.2 Typische Muster und Strukturen 8.3 Persistenz 8.4 Benutzeroberfläche …. 9. Entwurfsentscheidungen 9.1 Entwurfsentscheidung 1 9.2 Entwurfsentscheidung 2 …. 10. Qualitätsszenarien 10.1 Qualitätsbaum 10.2 Qualitäts-/Bewertungsszenarien 11. Risiken 12. Glossar
9. 2006...   delta  
10. Beispiel  (DatenmigraRon,  4000+  PT)  
11. Beispiel  (CRM-­‐System,  2000+  PT)  
12. Beispiel  „htmlSanityCheck“   h\ps://github.com/aim42/htmlsanitycheck  
13. Beispiel  „htmlSanityCheck“  (2)  
14. Mit  arc42  starten?  
15. Mit  arc42  starten  (Tag  1)   Beispiele!   Pragmatische Hilfe für Softwarearchitekten gernot STARKE peter HRUSCHKA h\p://aim42.github.io/htmlSanityCheck/  
16. -Stand Pragmatische Hilfe für Softwarearchitekten gernot STARKE peter HRUSCHKA *   gerne  im  Tausch  gegen  vcard     *  
17. Mit  arc42  starten  (Tag  1)  
18. Mit  arc42  starten  (Tag  1)   Idee  +  Ausführung:  Stefan  Zörner  (h\p://embarc.de)  
19. Mit  arc42  starten  (Tag  1)   Mehr  Beispiele!   h\p://confluence.arc42.org:     •  CRM-­‐System  (2000+  PT)   •  DatenmigraRon  (4000+  PT)  
20. Mit  arc42  starten  (Tag  1,  13:30h)...   neue  Systeme     1.  Kontext   2.  Qualitätsziele   3.  Lösungsstrategie   4.  Konzepte   1.  Domäne   2.  Persistenz,  UI  etc.   bestehende  Systeme     1.  Bausteine  (Code-­‐Struktur)   Level  1   2.  Konzepte  +  typische   Lösungsmuster   3.  Externe  Schni\stellen   (=  Kontext)  
21. Mit  arc42     im  Projekt?  
22. Mit  arc42  im  Projekt...   ProjektdokumentaRon     SystemdokumentaRon               Team   „Gärtner“  
23. Mit  arc42  im  Projekt...   ProjektdokumentaRon     ~arc42  „locker“     Diskussionen     ImplementaRon-­‐Guide,     Tasks  /  Issues   SystemdokumentaRon               Weitere  relevante  Infos...   (Betrieb/Admin,  Test,  Release...)   11. Risiken ARC42 Architektur-Dokumentation 1. Einführung und Ziele 2. Randbedingungen 3. Kontextabgrenzung 5. Bausteinsicht 6. Laufzeitsicht 7. Verteilungssicht 8. Konzepte 10. Qualitätsszenarien 9. Entwurfsentscheidungen 4. Lösungsstrategie 12. Glossar Team   „Gärtner“  
24. Große  Systeme     mit  arc42?  
25. arc42  und  größere  Systeme   Gesamtsystem     Kontextabgrenzung   (externe  Schni\stellen)     Bausteinsicht  L1   Ablauf  System-­‐UseCases   Zentrale  Entscheidungen   Zentrale  Konzepte   Subsystem  #1     Bausteinsicht   Lokale  Abläufe   Subsystem  #2     Bausteinsicht     Lokale  Abläufe   Subsystem  #3     Bausteinsicht     Lokale  Abläufe   11. Risiken ARC42 Architektur-Dokumentation 1. Einführung und Ziele 2. Randbedingungen 3. Kontextabgrenzung 5. Bausteinsicht 6. Laufzeitsicht 7. Verteilungssicht 8. Konzepte 10. Qualitätsszenarien 9. Entwurfsentscheidungen 4. Lösungsstrategie 12. Glossar 11. Risiken ARC42 Architektur-Dokumentation 1. Einführung und Ziele 2. Randbedingungen 3. Kontextabgrenzung 5. Bausteinsicht 6. Laufzeitsicht 7. Verteilungssicht 8. Konzepte 10. Qualitätsszenarien 9. Entwurfsentscheidungen 4. Lösungsstrategie 12. Glossar 11. Risiken ARC42 Architektur-Dokumentation 1. Einführung und Ziele 2. Randbedingungen 3. Kontextabgrenzung 5. Bausteinsicht 6. Laufzeitsicht 7. Verteilungssicht 8. Konzepte 10. Qualitätsszenarien 9. Entwurfsentscheidungen 4. Lösungsstrategie 12. Glossar 11. Risiken ARC42 Architektur-Dokumentation 1. Einführung und Ziele 2. Randbedingungen 3. Kontextabgrenzung 5. Bausteinsicht 6. Laufzeitsicht 7. Verteilungssicht 8. Konzepte 10. Qualitätsszenarien 9. Entwurfsentscheidungen 4. Lösungsstrategie 12. Glossar Link   Link   Link  
26. Kleine  Systeme     mit  arc42?  
27. Kleine  Systeme...   Leeres  Template  ==  26  Seiten   Übertrieben  für  kleine  Projekte,  oder?  
28. Kleine  Systeme...   Leeres  Template  ==  26  Seiten   Übertrieben  für  kleine  Projekte,  oder?   arc42  ==  Schrank,  nicht  Formular     SUPER  für  kleine  Projekte:   •  !meboxed  verwenden   •  essenRelle  Dinge  einbringen  
29. Code  und   Bausteinsicht?  
30. Building  Blocks     Hierarchy   Kontext Level 1 Level 2 Level 3 H t ml S a n it y Check use r Bu ild sy st em (e.g . G r adle, m ake) loc al ht ml file(s) loc al i m ages exter n al websites & resources * Risk * references « p ost po n ed » checks checks checks references H t ml S a n it y Check loc al - ht ml loc al -i m ages user build - syste m exter n al websites local - resources HS C Co re AllChecksRun ner local file syste m Results ht t p (exter n al) HS C G r a d le Plu gin HSC Com m a n d Lin e In t erfa ce HS C G r a phic al In t erfac e done pla n n ed L egend via shell HS C Co re AllChecksRun ner local file syste m Results ht t p (exter n al) «li br a r y » H t ml P a rser Results Collect o r Fin d in g s A ll Checks R un n e r done pla n n ed L egend Ch ecker Su ggest er Re po r t e r fin d suggestions crea te / execu te 1.. a d d Fin d in g pa rse Results Results Collect o r Results Re po r t e r Pe r - Ru n Results Sin gle C heck Resu lts w h a tIsC heck ed : St rin g sourceIte m :St ring t a r getIt em :St ri n g n r OfIte msChecked :in t Sin gle P age Resu lts pageN a m e :St ring pa geTit le :S t rin g m et aInfo :PageMet aInfo Fin d in g it e m :S t rin g sug gest ion :St rin g Fin d in g s a d d - Fin d in g 1.. * 0.. * 1 unused i m ages 1 Gradle  sub-­‐projects:   •  core: org.aim42.htmlsanitycheck •  gradle-plugin: org.aim42.htmlsanitycheck  
31. Building  Blocks     Hierarchy   Kontext Level 1 Level 2 Level 3 H t ml S a n it y Check use r Bu ild sy st em (e.g . G r adle, m ake) loc al ht ml file(s) loc al i m ages exter n al websites & resources * Risk * references « p ost po n ed » checks checks checks references H t ml S a n it y Check loc al - ht ml loc al -i m ages user build - syste m exter n al websites local - resources HS C Co re AllChecksRun ner local file syste m Results ht t p (exter n al) HS C G r a d le Plu gin HSC Com m a n d Lin e In t erfa ce HS C G r a phic al In t erfac e done pla n n ed L egend via shell HS C Co re AllChecksRun ner local file syste m Results ht t p (exter n al) «li br a r y » H t ml P a rser Results Collect o r Fin d in g s A ll Checks R un n e r done pla n n ed L egend Ch ecker Su ggest er Re po r t e r fin d suggestions crea te / execu te 1.. a d d Fin d in g pa rse Results Results Collect o r Results Re po r t e r Pe r - Ru n Results Sin gle C heck Resu lts w h a tIsC heck ed : St rin g sourceIte m :St ring t a r getIt em :St ri n g n r OfIte msChecked :in t Sin gle P age Resu lts pageN a m e :St ring pa geTit le :S t rin g m et aInfo :PageMet aInfo Fin d in g it e m :S t rin g sug gest ion :St rin g Fin d in g s a d d - Fin d in g 1.. * 0.. * 1 unused i m ages 1 Gradle  sub-­‐projects:   •  core: org.aim42.htmlsanitycheck •  gradle-plugin: org.aim42.htmlsanitycheck   Classes:   AllChecksRunner MissingConfigException   Packages:   o.a.h.check o.a.h.collect o.a.h.html o.a.h.report   Classes:   Checker.groovy ImageMapChecker   MissingImageFilesChecker
32. Level-­‐1:  Codestruktur  im  Großen  
33. Code  in  der   DokumentaRon?  
34. Code  in  Doku:  Beispiel...   WichRg:   NCP     (never  copy-­‐paste)  
35. Code  in  Doku:  Beispiel...     [source, groovy] .Interface RunResults ---- include::{coresourcepath}/htmlsanitycheck/collect/ RunResults.groovy[tags=RunResultInterface] ----   asciidoc-­‐Source  
36. Werkzeuge!  
37. Anforderungen  an  Tools   •  Text  +  Tabellen   •  Diagramme   •  Verweise   •  MulR-­‐User   •  Änderungshistorie   •  Versioniert  
38. Variante  1:    plain-­‐Wiki   •  Text  +  Tabellen   •  Diagramme   •  Verweise   •  MulR-­‐User   •  Änderungshistorie   •  Versioniert  
39. Variante  1b:    plain-­‐Wiki++   •  Text  +  Tabellen   •  Diagramme   •  Verweise   •  MulR-­‐User   •  Änderungshistorie   •  Versioniert   Zeichen-­‐Tool  (Visio,   Graffle  &  Co)  
40. Variante  1c:    Wiki  +  Grafik-­‐Plugin   •  Text  +  Tabellen   •  Diagramme   •  Verweise   •  MulR-­‐User   •  Änderungshistorie   •  Versioniert   Etwa:  Gliffy     (für  Confluence)  
41. Variante  2:    Wiki  +  UML-­‐Tool   •  Text  +  Tabellen   •  Diagramme   •  Verweise   •  MulR-­‐User   •  Änderungshistorie   •  Versioniert   UML-­‐Tool   (Enterprise-­‐Architect,    MagicDraw,    Visual-­‐Paradigm  &  Co)   •  Usability   •  Akzeptanz  
42. Variante  2:    Plaintext  +  UML-­‐Tool   •  Text  +  Tabellen   •  Diagramme   •  Verweise   •  MulR-­‐User   •  Änderungshistorie   •  Versioniert   AsciiDoc,  Markdown     •  Geek-­‐Faktor  
43. AsciiDoc...   •  Plaintext  (git,  diff)   •  Build  z.B.  mit  Gradle   •  Zielformate:  html,  epub,  pdf  
44. Confluence  +  ProjectDoc  (kommerziell)   •  Idee:  flüssigeres  Arbeiten  dank  Wizards   h\ps://www.smarRcs.de/go/arc42  
45. arc42  mit  projectdoc-­‐Blueprints   •  Vorlagen  als  Schreibhilfen  
46. HTML  Sanity  Checker  mit  projectdoc  
47. Variante  3:    UML-­‐Tool   •  Text  +  Tabellen   •  Diagramme   •  Verweise   •  MulR-­‐User   •  Änderungshistorie   •  Versioniert   Enterprise-­‐Architect,   Visual  Paradigm  etc.   •  Geek-­‐Faktor   Modelle!
48. Beispiel:  arc42  mit  EA  
49. UML-­‐Tool  +  Export-­‐AutomaRsierung   •  Export  aus  Enterprise-­‐Architect™     – Skript  in  github.com/arc42  vorhanden   •  Export  aus  VisualParadigm™   – Export  möglich     •  bislang  kein  OpenSource  Skript  verfügbar  
50. Wohin  damit?  
51. Wohin  mit  Domain-­‐Model?   1.  (gut)  Querschni\liche  Konzepte       2.  (ok)  Bausteinsicht  („Domain-­‐Component“)       3.  (hhm)  Eigenes  (neues)  Kapitel  
52. Wohin  mit  UI/Layout,  Masken     oder  Screenflow?   1.  Querschni\liche  Konzepte     2.  Eigene  Sicht     •  (==  neues  Kapitel)  
53. Kata  mit  arc42   („Hands-­‐on  Workshop“)    
54. Ziele  einer  Architektur-­‐Kata   •  Gemeinsames  Verständnis   •  Aufgaben  „erproben“   •  Aspekte  von  „Architektur“  erarbeiten  
55. Kata  mit  arc42   Aufgabe! Anforderungen! Qualitätsziele! ! ! Kontext! ! ! Lösungsidee! Bausteine! ! ! ! ! Konzepte!
56. Subprojekte!   Qualitätsanforderungen   wesentliche   Architekturaufgaben  
57. Beispiele  für  Q-­‐Anforderungen   •  Q-­‐Szenarien   – Etwa  60  praxisnahe  Qualitätsziele     (aus  konkreten  Projekten/Systemen  abstrahiert)   •  DefiniRonen  für  typische  Q-­‐Anforderungen   – 70+  häufig  vorkommende  Begriffe  rund  um   Qualität  –  pragmaRsch  definiert  
58. Beispiele  für  Q-­‐Anforderungen  
59. Architektur-­‐   Aufgaben...   h\ps://github.com/arc42/arc-­‐process   Architektur bewerten Anforderungen und Randbedingungen klären Technische Konzepte entwerfen Umsetzung begleiten Architektur kommunizieren Strukturen entwerfen
60. Dr.  Gernot  Starke     gs@gernotstarke.de     h\p://gernotstarke.de   h\p://innoq.com     h\ps://www.flickr.com/photos/foto_db/16000636092