Steht alles im Wiki? Das kleine 1x1 der Architekturdokumentation
•
7 gefällt mir•5,925 views
Folien zum Vortrag bei der GI Regionalgruppe Dortmund am 04.10.2010. Thema: Dokumentieren von Softwarearchitekturen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Steht alles im Wiki? Das kleine 1x1 der Architekturdokumentation
Ähnlich wie Steht alles im Wiki? Das kleine 1x1 der Architekturdokumentation (20)
Mehr von oose
Mehr von oose (20)
Steht alles im Wiki? Das kleine 1x1 der Architekturdokumentation
- 1. Impulsvortrag: Steht alles im Wiki? Das kleine 1x1 der Architekturdokumentation Stefan Zörner, oose Innovative Informatik GmbH, Hamburg Gesellschaft für Informatik e.V., Regionalgruppe Dortmund, 04.10.2010
- 2. Zusammenfassung Steht alles im Wiki? Das kleine 1x1 der Architekturdokumentation Architekturdokumentation wird oft als lästige Pflicht angesehen. Dabei ermöglicht das angemessene Festhalten die Kommunikation Ihrer Konzepte im Team und dem Auftraggeber gegenüber überhaupt erst. Der Vortrag stellt anhand konkreter Beispiele bewährte Arbeitsergebnisse und mögliche Strukturierungen vor. Häufige Herausforderungen werden ebenso diskutiert wie typische Werkzeugketten. Wiki oder UML-Tool? Oder was dazwischen? Welche Notationen haben sich in der Praxis bewähren? Und wie kommt man falls verlangt jederzeit zu einer druckbaren Dokumentation?
- 4. Agenda 1 Montag Morgen 2 Entscheidungen 3 Sichten 4 Bewerten 5 Strukturieren 6 Schluss und Aus(-blick)
- 5. Agenda 1 Montag Morgen 2 Entscheidungen 3 Sichten 4 Bewerten 5 Strukturieren 6 Schluss und Aus(-blick)
- 11. Agenda 1 Montag Morgen 2 Entscheidungen 3 Sichten 4 Bewerten 5 Strukturieren 6 Schluss und Aus(-blick)
- 13. Entscheidungen treffen und festhalten. Ein Werkzeug
- 17. Gesamtbild.
- 18. Agenda 1 Montag Morgen 2 Entscheidungen 3 Sichten 4 Bewerten 5 Strukturieren 6 Schluss und Aus(-blick)
- 24. Fallbeispiel: Apache Tomcat Apache Tomcat ist ein in Java geschriebener Webapplikationsserver zum Betreiben Java EE-konformer Webapplikationen. http://tomcat.apache.org
- 25. Eine Kontextsicht für Apache Tomcat in UML.
- 27. Was ist was?
- 28. Die Bausteinsicht „ Die Bausteinsicht bildet die Funktionalität des Systems auf Software- oder Implementierungsbausteine ab. Die Sicht macht Struktur und Zusammenhänge zwischen den Bausteinen der Struktur explizit “ (G. Starke) Beispiel (UML, Kompositionsstrukturdiagramm)
- 32. Nächste Ebene.
- 36. Statische Sicht.
- 41. UML Deployment Diagram Beispiel 2: Szenario: Tomcat + Apache HTTP Server
- 42. Agenda 1 Montag Morgen 2 Entscheidungen 3 Sichten 4 Bewerten 5 Strukturieren 6 Schluss und Aus(-blick)
- 45. Entscheidungen vor / im / nach dem Workshop festhalten
- 47. Möglichkeiten Qualitätsanforderungen zu beschreiben © by oose innovative Informatik GmbH
- 52. Agenda 1 Montag Morgen 2 Entscheidungen 3 Sichten 4 Bewerten 5 Strukturieren 6 Schluss und Aus(-blick)
- 54. Struktur des Templates
- 55. Es muss nicht immer ein digitales Tool sein ...
- 56. Übungsergebnisse aus einem oose-Seminar zu Softwarearchitektur
- 58. Diagramme == Sichten auf ein Modell
- 60. arc42 in einem Wiki?
- 63. Agenda 1 Montag Morgen 2 Entscheidungen 3 Sichten 4 Bewerten 5 Strukturieren 6 Schluss und Aus(-blick)
- 64. Früher kaufte man Software im Laden in einem Karton …
- 68. Machen Sie die Systemidee explizit! Machen Sie die Systemidee explizit!
- 69. Systemidee auf der Startseite des Projekt- Wikis …
- 70. Virtuellen Produktkarton erstellen z.B. http://www.wikihow.com/Create-a-Product-Box-in-Photoshop
- 71. Systemkontext und Systemidee Was steckt drin? Was ist drum herum?
- 74. Vielen Dank! Ich freue mich auf Ihre Fragen … ? ? ? Stefan Zörner :: Stefan.Zoerner@oose.de
Hinweis der Redaktion
- Eine Tanznotation ist die symbolische Repräsentation von Tanzbewegungen.
- Statische Sicht. Das Dillema: In welcher Reihenfolge werden die Lifecycle-Methoden von Lifecycle und Valve aufgerufen?
- Spring-/Hibernate-Benutzer kennen das Problem vielleicht auch: Bergeweise jar-Files, und man hat keine Ahnung, wofür das alles gut ist, und ob man das braucht (OSGi und Maven gibt es ja nicht von ungefähr)
- Solche Diagramme können erhellen. Ein Artefakt repräsentiert eine physikalische Informationseinheit, die während der Softwareentwicklung benötigt bzw. erstellt wird. Eine Manifestation verbindet ein Modellelement mit einem Artefakt. Das Artefakt ist die physikalische Manifestation des Modellelementes.
- Man sieht, es sind teilweise ähnliche Ziele wie bei Dokumentation auch: Kommunikation, Transparenz. Architekturbewertung fördert Dokumentation im Vorfeld (Man braucht Artefakte um Entscheidungen und Anforderungen zu vermitteln) Architekturbewertung sorgt dafür dass wichtige, dokumentierte Dinge auch reflektiert wurden bevor sie dokumentiert werden und damit in Stein gemeißelt sind (ansonsten: Buße tun, abschließen) Architekturbewertung nimmt Dokumentation die alleinige Last der Kommunikation von Entscheidungen
- Szenarien: gute Anforderungen wo sie oft nicht sind: bei Qualitätsmerkmalen Bewertungs-Workshop: Erfahrung und Know-How teilen und multiplizieren, Anforderungen nochmals schärfen und sofortiges Feedback von ALLEN Stakeholdern Feedback von Ergebnissen: nicht nur in Software-Architektur, sondern auch in Anforderungs- und Kundenprozess Outputs müssen natürlich auch wieder dokumentiert werden und vervollständigen meist die Dokumentation von Entscheidungen…
- Zweierlei Werkzeug: Methodik zum Treffen von Entscheidungen Struktur zum Festhalten von Entscheidungen – Formatvorlage für Word, Wiki etc.
- Auf einer Vielzahl von Webseiten finden sich virtuelle Produktkartons. Beispiel : Homepage von Apache ActiveMQ Als Open Source Middleware ist es ein besonders interessanter Vertreter, da man diese Software gar nicht käuflich erwerben kann, und sie als Software-Infrastruktur-Komponente für Außenstehende auch schwer zu begreifen ist (es gibt nichts zu klicken). Durch den Karton bekommt die Lösung trotzdem etwas Gegenständliches, sie erscheint fassbarer.