SlideShare ist ein Scribd-Unternehmen logo
Stefan Zörner | embarc GmbH
Verunfallte Softwarearchitektur
Erfolgreiche Lösungen höchstens per Zufall?
sz@embarc.de
@StefanZoerner
xing.to/szr
Über mich (Stefan Zörner)
 Softwareentwickler, -architekt, Coach bei embarc in Hamburg
 Vorher oose, IBM, Mummert + Partner, Bayer AG, …
Schwerpunkte:
 Softwarearchitektur (Entwurf,
Bewertung, Dokumentation)
 Java-Technologien
1 Einstieg
2 (Gute) Softwarearchitektur
3 Qualitätsmerkmale meistern
4 Entscheidungen treffen und festhalten
5 Die Realität im Auge behalten
6 Ein Selbsttest
7 Fazit und Weitere Informationen1
???
Aufgabe (Teil 1)
Erstellt eine Karte für ein Architektur-Quartett!
 Wählt ein System aus, dass Ihr
gut kennt, z.B. Eurer aktuelles
Projekt!
 Füllt für dieses System die
Vorlage aus!
 Wenn Ihr Bezeichnungen und
Stärken erfasst habt: Visualisiert
das System:
 Architekturüberblick oder
 Avatar
 Zeit: 5 Minuten
Aufgabe (Teil 2)
Tauscht Euch mit Eurem Nachbarn / Rückbarn aus!
 Lasst die Karten gegeneinander
„antreten“
 Welches System hat gewonnen?
 Tauscht Euch über die
Architektur Eurer Systeme aus!
 Zeit: 5 Minuten
Äpfel mit Birnen vergleichen?
vs.

1 Einstieg
2 (Gute) Softwarearchitektur
3 Qualitätsmerkmale meistern
4 Entscheidungen treffen und festhalten
5 Die Realität im Auge behalten
6 Ein Selbsttest
7 Fazit und Weitere Informationen2
Was ist Softwarearchitektur?
Expertenmeinungen
“Softwarearchitecture is about the important stuff,
whatever that is.”
(Martin Fowler)
“… not all design is architecture. Architecture represents
the significant design decisions that shape a system,
where significant is measured by cost of change.”
(Grady Booch)
“Software architecture is the set of design decisions
which, if made incorrectly, may cause your project to be
cancelled.”
(Eoin Woods)
Auf den Punkt gebracht …
Softwarearchitektur :=
wichtige Entscheidungen
wichtige Entscheidungen :=
 fundamental
 im weiteren Verlauf nur schwer zu ändern
„Verunfallte“ Softwarearchitektur?
aus
Grady Booch:
„The Accidental Architecture“
IEEE Software 2006
„Every interesting software-intensive system has
an architecture. While some of these
architectures are intentional, most appear to be
accidental.“
„Every interesting software-intensive system has
an architecture. While some of these
architectures are intentional, most appear to be
accidental.“
Was ist gute Softwarearchitektur?
Gute Softwarearchitektur
==
Entscheidungen wurden explizit getroffen.
Nein. Zufällige Architektur muss nicht schlecht sein.
Aber:
- Sie lässt sich schwer vermitteln.
- Sie lässt sich schwer bewerten.
? ?
Was ist Architekturbewertung?
Architektur / Entwurf
(Modelle, Entscheidungen)
Architekturrelevante
Anforderungen
Umsetzungsüberprüfung
Architekturbewertung
Umsetzung
(Lauffähiger Code)
Architektur / Entwurf
(Modelle, Entscheidungen)
Architekturrelevante
Anforderungen
Umsetzungsüberprüfung
Architekturbewertung
Umsetzung
(Lauffähiger Code)
Was ist Architekturbewertung?

1 Einstieg
2 (Gute) Softwarearchitektur
3 Qualitätsmerkmale meistern
4 Entscheidungen treffen und festhalten
5 Die Realität im Auge behalten
6 Ein Selbsttest
7 Fazit und Weitere Informationen3
Beispiel: Ein Schach-Programm
Zentrale Features
 Vollständige Umsetzung der offiziellen
FIDE-Schachregeln
 Quelltext lädt zum Experimentieren und
zum Erweitern ein
 Spiel gegen menschliche und
Computergegner
 Beherrscht taktische Elemente wie
Gabel und Spieß
 Anbindung von Eröffnungsbibliotheken
Konkrete Fragestellung
Wie stellt man die Spielsituation als
Datenstruktur dar?
 Figuren auf dem Brett
 Spieler am Zug …
Option 1: 2-dimensionales Array
Option 2: Bitfelder
Wartbarkeit Effizienz
Qualitätsmerkmale ausbalancieren
Expertenmeinung
“Bei Shredder ist die Effizienz klar im Vordergrund, die
Wartbarkeit des Quelltextes muss da leider manchmal
hinten anstehen.”
Stefan Meyer-Kahlen (Autor von Shredder)
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.
Beispiel: Qualitätsziele DokChess
Qualitätsmerkmal Ziel
Analysierbarkeit Da DokChess in erster Linie als Anschauungsmaterial für
Architekten und Entwickler dient, erschließen sich Entwurf
und Implementierung schnell.
Änderbarkeit Alternative Algorithmen und Strategien, etwa zur
Bewertung einer Schachstellung, können leicht
implementiert und in die Lösung integriert werden.
Interoperabilität Die Engine kann mit angemessenem Aufwand in
bestehende grafische Schach-Frontends eingebunden
werden.
Attraktivität Die Engine spielt stark genug, um schwache Gegner sicher
zu schlagen und Gelegenheitsspieler zumindest zu fordern.
Effizienz Da die Engine in Seminaren und Vorträgen live
demonstriert wird, erfolgt die Berechnung der Spielzüge
rasch.
Konkretisierung durch Szenarien
Ein Szenario ist ein Beispiel für die Verwendung des
Systems, bei dem ein Qualitätsmerkmal die Hauptrolle
spielt.
Konkretisierung durch Szenarien
Antwort-Maß
Quelle
Typische Bestandteile eines Qualitätsszenarios:
Bezug zu Architekturbewertung
Qualitätsziele geben einen Hinweis, welche
Kriterien auf Euren Quartettkarten wichtig sind.
ATAM
Architecture tradeoff analysis method
 verbreitetste Methode zur
Bewertung von Softwarearchitektur
 früh anwendbar
 szenarienbasiert
Szenarien konkretisieren die Ziele und helfen
dabei zu bewerten, wie gut sie erreicht werden
(bzw. wurden).

1 Einstieg
2 (Gute) Softwarearchitektur
3 Qualitätsmerkmale meistern
4 Entscheidungen treffen und festhalten
5 Die Realität im Auge behalten
6 Ein Selbsttest
7 Fazit und Weitere Informationen4
Beispiel: Ein Schach-Programm
Zentrale Features
 Vollständige Umsetzung der offiziellen
FIDE-Schachregeln
 Quelltext lädt zum Experimentieren und
zum Erweitern ein
 Spiel gegen menschliche und
Computergegner
 Beherrscht taktische Elemente wie
Gabel und Spieß
 Anbindung von Eröffnungsbibliotheken
Systemkontext
?
Protokolle für Schachprogramme
 2 Lösungen etabliert/dokumentiert
 beide ASCII-basiert, beide via stdin/stdout
Universal Chess Interface (UCI)
http://wbec-ridderkerk.nl/html/UCIProtocol.html
Chess Engine Communication Protocol („Xboard/WinBoard“)
http://home.hccnet.nl/h.g.muller/engine-intf.html
stdin
stdout
Engine
Frontend
Wann eine Entscheidung treffen?
Ich habe eine Fragestellung, und 2 Optionen
Unterschiedlich,
z.B. unterschiedliche
Implementierungsdauer
Lösung muss
implementiert sein
LRM
Lernfenster
Frage identifiziert
t
Lese-Tipp
Vorgehensmuster für Softwarearchitektur.
Kombinierbare Praktiken in Zeiten von Agile und Lean
von Stefan Toth
Verlag: Hanser Fachbuch 2013
Sprache: Deutsch (240 Seiten)
ISBN-13: 978-3446436152  http://www.swamuster.de
„Wann sollte eine architekturelle Fragestellung
idealerweise entschieden werden, um (1) das
Risiko einer Fehlentscheidung zu minimieren
und (2) eine optimale Entscheidung für das
Projekt zu treffen?“
Vorgehensmuster „Der letzte vernünftige Moment“
Entscheidungen treffen (und festhalten)

1 Einstieg
2 (Gute) Softwarearchitektur
3 Qualitätsmerkmale meistern
4 Entscheidungen treffen und festhalten
5 Die Realität im Auge behalten
6 Ein Selbsttest
7 Fazit und Weitere Informationen
5
Was ist Architekturbewertung?
Architektur / Entwurf
(Modelle, Entscheidungen)
Architekturrelevante
Anforderungen
Umsetzungsüberprüfung
Architekturbewertung
Umsetzung
(Lauffähiger Code)
Architektur / Entwurf
(Modelle, Entscheidungen)
Architekturrelevante
Anforderungen
Umsetzungsüberprüfung
Architekturbewertung
Umsetzung
(Lauffähiger Code)
Umsetzungsüberprüfung
Beispiel: Ein Schach-Programm
Zentrale Features
 Vollständige Umsetzung der offiziellen
FIDE-Schachregeln
 Quelltext lädt zum Experimentieren und
zum Erweitern ein
 Spiel gegen menschliche und
Computergegner
 Beherrscht taktische Elemente wie
Gabel und Spieß
 Anbindung von Eröffnungsbibliotheken
Beispiel
Zerlegung von DokChess nach Verantwortlichkeiten:
Spannende Fragen …
Finde ich die Struktur so im Quelltext wieder?
Sind die Verantwortlichkeiten so wie gedacht?
Sind die Abhängigkeiten so, wie dargestellt?
?
Beispieltool: Sonargraph
Logische Architektur definieren
„Verstöße“ aufdecken
Expertenmeinungen
Je stärker die Wirklichkeit von unseren Wünschen
abweicht, desto identischer ist sie mit sich.
(Michael Rumpf)
Architekturkonzepte sind edle Wünsche, solange sie
nicht in harter Arbeit implementiert, getestet und
verändert wurden.
(Stefan Toth)

1 Einstieg
2 (Gute) Softwarearchitektur
3 Qualitätsmerkmale meistern
4 Entscheidungen treffen und festhalten
5 Die Realität im Auge behalten
6 Ein Selbsttest
7 Fazit und Weitere Informationen
6
Stufen der Softwarearchitektur
zufällig0
explizit1
nachvollziehbar2
wirkungsvoll3
Kommunikation
Wie werden Fragen nach Architekturentscheidungen,
-ansätzen, -konzepten beantwortet?
 „Historisch gewachsen …“
 Es findet ein Austausch über die Architektur über
Projekt-/Teamgrenzen hinweg statt.
 Architekturansätze sind im Team bekannt und können
neuen Mitarbeitern nachvollziehbar erklärt werden.
 „Da musst Du Rene fragen …“
Struktur
Wo finde ich die Struktur der Lösung?
 nur im Quelltext
 Teile/Komponenten werden wo sinnvoll über
Projektgrenzen wiederverwendet
 die Strukturen (z.B. Schichten, fachliche Zerlegung) sind
nachvollziehbar an den Anforderungen ausgerichtet
 in Diagrammen / Modellen und konsistent dazu im
Quelltext
Übergreifende Konzepte
Wie wird mit übergreifenden Aspekten und
Fragestellungen umgegangen?
 Tendenziell gibt es keine. Die Lösung ist inkonsistent.
 Es gibt einzelne Konzepte, die durchgängig eingehalten
werden.
 Die Konzepte sind an den Qualitätszielen und
architekturrelevanten Anforderungen ausgerichtet.
 Die Auswahl der Themen für einheitlichen Konzepte ist
nachvollziehbar (inkl. bewusstes Weglassen)
 Lösungen für einheitliche Konzepte werden, wo sinnvoll,
über Projektgrenzen geteilt.
Stufen der Softwarearchitektur
0 (zufällig)
Softwarearchitektur ist implizit, Erfolg Zufall.
1 (explizit)
Architekturansätze sind explizit vorhanden und benennbar
(Beispiele: Verwendung von Mustern, Entscheidungen für Frameworks)
2 (nachvollziehbar)
Die Lösung ist an Zielen und Anforderungen nachvollziehbar
ausgerichtet. Umsetzung und Architektur entsprechen sich.
3 (wirkungsvoll)
Die Lösung und das Vorgehen der Architekturarbeit sind reflektiert und
angemessen. Die Architektur wirkt über Projektgrenzen hinaus.
„The Accidental Architecture“
Grady Booch:
„The Accidental Architecture“
IEEE Software 2006
„Accidental architectures are not evil things; indeed, they
are inevitable in the growth of systems. It’s only when
we begin to turn these accidental architectures into
intentional ones that we advance our understanding of
software architecture. “

1 Einstieg
2 (Gute) Softwarearchitektur
3 Qualitätsmerkmale meistern
4 Entscheidungen treffen und festhalten
5 Die Realität im Auge behalten
6 Ein Selbsttest
7 Fazit und Weitere Informationen
7
Äpfel mit Birnen vergleichen?
vs.
Äpfel mit Birnen vergleichen?
Toll Collect Super Mario Bros.
8D 2C
vs.
Fazit
zufällig0
explizit1
nachvollziehbar2
wirkungsvoll3
Ich kann auch hier unten gute Lösungen
produzieren.
Ich kann auch hier unten gute Lösungen
produzieren. Zufällig.
Die Vorstellung erfolgreiche Lösungen nur
dem Zufall zu überlassen, macht mir Angst.
Ich investiere lieber in Architekturarbeit, …Ich investiere lieber in Architekturarbeit,
zumindest wenn Scheitern keine Option ist.
Drei Dinge
Qualitätsmerkmale meistern
Entscheidungen treffen
und festhalten
Die Realität im Auge behalten
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: 978-3-446-42924-6
www.swadok.de
27
Blog-Serie bei Hanser Update
 update.hanser-fachbuch.de/tag/arc42-starschnitt/
stefan.zoerner@embarc.de
xing.to/szr
@StefanZoerner
Vielen Dank.
Ich freue mich auf Eure Fragen!
DOWNLOAD FOLIEN:
http://www.embarc.de/blog/

Weitere ähnliche Inhalte

Ähnlich wie Verunfallte Softwarearchitektur. Erfolgreiche Lösungen höchstens per Zufall?

ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...Aberla
 
German UPA Konferenz - Der IxD Baukasten
German UPA Konferenz - Der IxD BaukastenGerman UPA Konferenz - Der IxD Baukasten
German UPA Konferenz - Der IxD BaukastenUSECON
 
Einführung in die Software-Qualitätssicherung
Einführung in die Software-QualitätssicherungEinführung in die Software-Qualitätssicherung
Einführung in die Software-QualitätssicherungChristian Baranowski
 
JavaScript und trotzdem Softwerker
JavaScript und trotzdem SoftwerkerJavaScript und trotzdem Softwerker
JavaScript und trotzdem SoftwerkerDennis Wilson
 
Softwarequalität mit Visual Studio 2010
Softwarequalität mit Visual Studio 2010Softwarequalität mit Visual Studio 2010
Softwarequalität mit Visual Studio 2010mspgermany
 
TAG2015: ArchiteKultur – wie bekommen wir Architekturarbeit in den Alltag rei...
TAG2015: ArchiteKultur – wie bekommen wir Architekturarbeit in den Alltag rei...TAG2015: ArchiteKultur – wie bekommen wir Architekturarbeit in den Alltag rei...
TAG2015: ArchiteKultur – wie bekommen wir Architekturarbeit in den Alltag rei...Matthias Bohlen
 
Der Technical Debt Manager
Der Technical Debt ManagerDer Technical Debt Manager
Der Technical Debt ManagerJens Nerche
 
Mastering architecture, design- and code-quality
Mastering architecture, design- and code-qualityMastering architecture, design- and code-quality
Mastering architecture, design- and code-qualitySebastian Dietrich
 
Softwarequalität - Architektur
Softwarequalität - ArchitekturSoftwarequalität - Architektur
Softwarequalität - ArchitekturGerrit Beine
 
Der Status Quo des Chaos Engineerings
Der Status Quo des Chaos EngineeringsDer Status Quo des Chaos Engineerings
Der Status Quo des Chaos EngineeringsQAware GmbH
 
Sdv 0405 design-pattern_thc_jps_skript
Sdv 0405 design-pattern_thc_jps_skriptSdv 0405 design-pattern_thc_jps_skript
Sdv 0405 design-pattern_thc_jps_skriptTomasz Waszczyk
 
Sdv 0405 design-pattern_thc_jps_skript
Sdv 0405 design-pattern_thc_jps_skriptSdv 0405 design-pattern_thc_jps_skript
Sdv 0405 design-pattern_thc_jps_skriptTomasz Waszczyk
 
Architektur = Kommunikation
Architektur = KommunikationArchitektur = Kommunikation
Architektur = KommunikationMatthias Bohlen
 
30. Treffen der .NET User Group Rhein-Neckar mit Constantin Klein - „Bekommen...
30. Treffen der .NET User Group Rhein-Neckar mit Constantin Klein - „Bekommen...30. Treffen der .NET User Group Rhein-Neckar mit Constantin Klein - „Bekommen...
30. Treffen der .NET User Group Rhein-Neckar mit Constantin Klein - „Bekommen....NET User Group Rhein-Neckar
 
WJAX 2014: Pah, ArchitekturDoku, darauf habe ich keine Lust!
WJAX 2014: Pah, ArchitekturDoku, darauf habe ich keine Lust!WJAX 2014: Pah, ArchitekturDoku, darauf habe ich keine Lust!
WJAX 2014: Pah, ArchitekturDoku, darauf habe ich keine Lust!Matthias Bohlen
 
Einführung Vorgehensmodelle und Agile Software Entwicklung
Einführung Vorgehensmodelle und Agile Software EntwicklungEinführung Vorgehensmodelle und Agile Software Entwicklung
Einführung Vorgehensmodelle und Agile Software EntwicklungChristian Baranowski
 
Auf dem Weg zu Unwartbarkeit - Die besten Strategien für den sicheren Erfolg!
Auf dem Weg zu Unwartbarkeit - Die besten Strategien für den sicheren Erfolg!Auf dem Weg zu Unwartbarkeit - Die besten Strategien für den sicheren Erfolg!
Auf dem Weg zu Unwartbarkeit - Die besten Strategien für den sicheren Erfolg!Benjamin Schmid
 

Ähnlich wie Verunfallte Softwarearchitektur. Erfolgreiche Lösungen höchstens per Zufall? (20)

objectiF extrem
objectiF extremobjectiF extrem
objectiF extrem
 
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
 
Mehr Softwarequalität: Team Clean Coding
Mehr Softwarequalität: Team Clean CodingMehr Softwarequalität: Team Clean Coding
Mehr Softwarequalität: Team Clean Coding
 
German UPA Konferenz - Der IxD Baukasten
German UPA Konferenz - Der IxD BaukastenGerman UPA Konferenz - Der IxD Baukasten
German UPA Konferenz - Der IxD Baukasten
 
Einführung in die Software-Qualitätssicherung
Einführung in die Software-QualitätssicherungEinführung in die Software-Qualitätssicherung
Einführung in die Software-Qualitätssicherung
 
JavaScript und trotzdem Softwerker
JavaScript und trotzdem SoftwerkerJavaScript und trotzdem Softwerker
JavaScript und trotzdem Softwerker
 
Softwarequalität mit Visual Studio 2010
Softwarequalität mit Visual Studio 2010Softwarequalität mit Visual Studio 2010
Softwarequalität mit Visual Studio 2010
 
TAG2015: ArchiteKultur – wie bekommen wir Architekturarbeit in den Alltag rei...
TAG2015: ArchiteKultur – wie bekommen wir Architekturarbeit in den Alltag rei...TAG2015: ArchiteKultur – wie bekommen wir Architekturarbeit in den Alltag rei...
TAG2015: ArchiteKultur – wie bekommen wir Architekturarbeit in den Alltag rei...
 
Der Technical Debt Manager
Der Technical Debt ManagerDer Technical Debt Manager
Der Technical Debt Manager
 
Mehr Softwarequalität: Team-Cleancoding
Mehr Softwarequalität: Team-CleancodingMehr Softwarequalität: Team-Cleancoding
Mehr Softwarequalität: Team-Cleancoding
 
Mastering architecture, design- and code-quality
Mastering architecture, design- and code-qualityMastering architecture, design- and code-quality
Mastering architecture, design- and code-quality
 
Softwarequalität - Architektur
Softwarequalität - ArchitekturSoftwarequalität - Architektur
Softwarequalität - Architektur
 
Der Status Quo des Chaos Engineerings
Der Status Quo des Chaos EngineeringsDer Status Quo des Chaos Engineerings
Der Status Quo des Chaos Engineerings
 
Sdv 0405 design-pattern_thc_jps_skript
Sdv 0405 design-pattern_thc_jps_skriptSdv 0405 design-pattern_thc_jps_skript
Sdv 0405 design-pattern_thc_jps_skript
 
Sdv 0405 design-pattern_thc_jps_skript
Sdv 0405 design-pattern_thc_jps_skriptSdv 0405 design-pattern_thc_jps_skript
Sdv 0405 design-pattern_thc_jps_skript
 
Architektur = Kommunikation
Architektur = KommunikationArchitektur = Kommunikation
Architektur = Kommunikation
 
30. Treffen der .NET User Group Rhein-Neckar mit Constantin Klein - „Bekommen...
30. Treffen der .NET User Group Rhein-Neckar mit Constantin Klein - „Bekommen...30. Treffen der .NET User Group Rhein-Neckar mit Constantin Klein - „Bekommen...
30. Treffen der .NET User Group Rhein-Neckar mit Constantin Klein - „Bekommen...
 
WJAX 2014: Pah, ArchitekturDoku, darauf habe ich keine Lust!
WJAX 2014: Pah, ArchitekturDoku, darauf habe ich keine Lust!WJAX 2014: Pah, ArchitekturDoku, darauf habe ich keine Lust!
WJAX 2014: Pah, ArchitekturDoku, darauf habe ich keine Lust!
 
Einführung Vorgehensmodelle und Agile Software Entwicklung
Einführung Vorgehensmodelle und Agile Software EntwicklungEinführung Vorgehensmodelle und Agile Software Entwicklung
Einführung Vorgehensmodelle und Agile Software Entwicklung
 
Auf dem Weg zu Unwartbarkeit - Die besten Strategien für den sicheren Erfolg!
Auf dem Weg zu Unwartbarkeit - Die besten Strategien für den sicheren Erfolg!Auf dem Weg zu Unwartbarkeit - Die besten Strategien für den sicheren Erfolg!
Auf dem Weg zu Unwartbarkeit - Die besten Strategien für den sicheren Erfolg!
 

Verunfallte Softwarearchitektur. Erfolgreiche Lösungen höchstens per Zufall?

  • 1. Stefan Zörner | embarc GmbH Verunfallte Softwarearchitektur Erfolgreiche Lösungen höchstens per Zufall?
  • 2. sz@embarc.de @StefanZoerner xing.to/szr Über mich (Stefan Zörner)  Softwareentwickler, -architekt, Coach bei embarc in Hamburg  Vorher oose, IBM, Mummert + Partner, Bayer AG, … Schwerpunkte:  Softwarearchitektur (Entwurf, Bewertung, Dokumentation)  Java-Technologien
  • 3. 1 Einstieg 2 (Gute) Softwarearchitektur 3 Qualitätsmerkmale meistern 4 Entscheidungen treffen und festhalten 5 Die Realität im Auge behalten 6 Ein Selbsttest 7 Fazit und Weitere Informationen1
  • 4. ??? Aufgabe (Teil 1) Erstellt eine Karte für ein Architektur-Quartett!  Wählt ein System aus, dass Ihr gut kennt, z.B. Eurer aktuelles Projekt!  Füllt für dieses System die Vorlage aus!  Wenn Ihr Bezeichnungen und Stärken erfasst habt: Visualisiert das System:  Architekturüberblick oder  Avatar  Zeit: 5 Minuten
  • 5. Aufgabe (Teil 2) Tauscht Euch mit Eurem Nachbarn / Rückbarn aus!  Lasst die Karten gegeneinander „antreten“  Welches System hat gewonnen?  Tauscht Euch über die Architektur Eurer Systeme aus!  Zeit: 5 Minuten
  • 6. Äpfel mit Birnen vergleichen? vs.
  • 7.  1 Einstieg 2 (Gute) Softwarearchitektur 3 Qualitätsmerkmale meistern 4 Entscheidungen treffen und festhalten 5 Die Realität im Auge behalten 6 Ein Selbsttest 7 Fazit und Weitere Informationen2
  • 9. Expertenmeinungen “Softwarearchitecture is about the important stuff, whatever that is.” (Martin Fowler) “… not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.” (Grady Booch) “Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled.” (Eoin Woods)
  • 10. Auf den Punkt gebracht … Softwarearchitektur := wichtige Entscheidungen wichtige Entscheidungen :=  fundamental  im weiteren Verlauf nur schwer zu ändern
  • 11. „Verunfallte“ Softwarearchitektur? aus Grady Booch: „The Accidental Architecture“ IEEE Software 2006 „Every interesting software-intensive system has an architecture. While some of these architectures are intentional, most appear to be accidental.“ „Every interesting software-intensive system has an architecture. While some of these architectures are intentional, most appear to be accidental.“
  • 12. Was ist gute Softwarearchitektur? Gute Softwarearchitektur == Entscheidungen wurden explizit getroffen. Nein. Zufällige Architektur muss nicht schlecht sein. Aber: - Sie lässt sich schwer vermitteln. - Sie lässt sich schwer bewerten. ? ?
  • 13. Was ist Architekturbewertung? Architektur / Entwurf (Modelle, Entscheidungen) Architekturrelevante Anforderungen Umsetzungsüberprüfung Architekturbewertung Umsetzung (Lauffähiger Code)
  • 14. Architektur / Entwurf (Modelle, Entscheidungen) Architekturrelevante Anforderungen Umsetzungsüberprüfung Architekturbewertung Umsetzung (Lauffähiger Code) Was ist Architekturbewertung?
  • 15.  1 Einstieg 2 (Gute) Softwarearchitektur 3 Qualitätsmerkmale meistern 4 Entscheidungen treffen und festhalten 5 Die Realität im Auge behalten 6 Ein Selbsttest 7 Fazit und Weitere Informationen3
  • 16. Beispiel: Ein Schach-Programm Zentrale Features  Vollständige Umsetzung der offiziellen FIDE-Schachregeln  Quelltext lädt zum Experimentieren und zum Erweitern ein  Spiel gegen menschliche und Computergegner  Beherrscht taktische Elemente wie Gabel und Spieß  Anbindung von Eröffnungsbibliotheken
  • 17. Konkrete Fragestellung Wie stellt man die Spielsituation als Datenstruktur dar?  Figuren auf dem Brett  Spieler am Zug …
  • 21. Expertenmeinung “Bei Shredder ist die Effizienz klar im Vordergrund, die Wartbarkeit des Quelltextes muss da leider manchmal hinten anstehen.” Stefan Meyer-Kahlen (Autor von Shredder)
  • 22.
  • 23. 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.
  • 24. Beispiel: Qualitätsziele DokChess Qualitätsmerkmal Ziel Analysierbarkeit Da DokChess in erster Linie als Anschauungsmaterial für Architekten und Entwickler dient, erschließen sich Entwurf und Implementierung schnell. Änderbarkeit Alternative Algorithmen und Strategien, etwa zur Bewertung einer Schachstellung, können leicht implementiert und in die Lösung integriert werden. Interoperabilität Die Engine kann mit angemessenem Aufwand in bestehende grafische Schach-Frontends eingebunden werden. Attraktivität Die Engine spielt stark genug, um schwache Gegner sicher zu schlagen und Gelegenheitsspieler zumindest zu fordern. Effizienz Da die Engine in Seminaren und Vorträgen live demonstriert wird, erfolgt die Berechnung der Spielzüge rasch.
  • 25. Konkretisierung durch Szenarien Ein Szenario ist ein Beispiel für die Verwendung des Systems, bei dem ein Qualitätsmerkmal die Hauptrolle spielt.
  • 26. Konkretisierung durch Szenarien Antwort-Maß Quelle Typische Bestandteile eines Qualitätsszenarios:
  • 27. Bezug zu Architekturbewertung Qualitätsziele geben einen Hinweis, welche Kriterien auf Euren Quartettkarten wichtig sind. ATAM Architecture tradeoff analysis method  verbreitetste Methode zur Bewertung von Softwarearchitektur  früh anwendbar  szenarienbasiert Szenarien konkretisieren die Ziele und helfen dabei zu bewerten, wie gut sie erreicht werden (bzw. wurden).
  • 28.  1 Einstieg 2 (Gute) Softwarearchitektur 3 Qualitätsmerkmale meistern 4 Entscheidungen treffen und festhalten 5 Die Realität im Auge behalten 6 Ein Selbsttest 7 Fazit und Weitere Informationen4
  • 29. Beispiel: Ein Schach-Programm Zentrale Features  Vollständige Umsetzung der offiziellen FIDE-Schachregeln  Quelltext lädt zum Experimentieren und zum Erweitern ein  Spiel gegen menschliche und Computergegner  Beherrscht taktische Elemente wie Gabel und Spieß  Anbindung von Eröffnungsbibliotheken
  • 31. Protokolle für Schachprogramme  2 Lösungen etabliert/dokumentiert  beide ASCII-basiert, beide via stdin/stdout Universal Chess Interface (UCI) http://wbec-ridderkerk.nl/html/UCIProtocol.html Chess Engine Communication Protocol („Xboard/WinBoard“) http://home.hccnet.nl/h.g.muller/engine-intf.html stdin stdout Engine Frontend
  • 32. Wann eine Entscheidung treffen? Ich habe eine Fragestellung, und 2 Optionen Unterschiedlich, z.B. unterschiedliche Implementierungsdauer Lösung muss implementiert sein LRM Lernfenster Frage identifiziert t
  • 33. Lese-Tipp Vorgehensmuster für Softwarearchitektur. Kombinierbare Praktiken in Zeiten von Agile und Lean von Stefan Toth Verlag: Hanser Fachbuch 2013 Sprache: Deutsch (240 Seiten) ISBN-13: 978-3446436152  http://www.swamuster.de „Wann sollte eine architekturelle Fragestellung idealerweise entschieden werden, um (1) das Risiko einer Fehlentscheidung zu minimieren und (2) eine optimale Entscheidung für das Projekt zu treffen?“ Vorgehensmuster „Der letzte vernünftige Moment“
  • 35.  1 Einstieg 2 (Gute) Softwarearchitektur 3 Qualitätsmerkmale meistern 4 Entscheidungen treffen und festhalten 5 Die Realität im Auge behalten 6 Ein Selbsttest 7 Fazit und Weitere Informationen 5
  • 36. Was ist Architekturbewertung? Architektur / Entwurf (Modelle, Entscheidungen) Architekturrelevante Anforderungen Umsetzungsüberprüfung Architekturbewertung Umsetzung (Lauffähiger Code)
  • 37. Architektur / Entwurf (Modelle, Entscheidungen) Architekturrelevante Anforderungen Umsetzungsüberprüfung Architekturbewertung Umsetzung (Lauffähiger Code) Umsetzungsüberprüfung
  • 38. Beispiel: Ein Schach-Programm Zentrale Features  Vollständige Umsetzung der offiziellen FIDE-Schachregeln  Quelltext lädt zum Experimentieren und zum Erweitern ein  Spiel gegen menschliche und Computergegner  Beherrscht taktische Elemente wie Gabel und Spieß  Anbindung von Eröffnungsbibliotheken
  • 39. Beispiel Zerlegung von DokChess nach Verantwortlichkeiten:
  • 40. Spannende Fragen … Finde ich die Struktur so im Quelltext wieder? Sind die Verantwortlichkeiten so wie gedacht? Sind die Abhängigkeiten so, wie dargestellt? ?
  • 44. Expertenmeinungen Je stärker die Wirklichkeit von unseren Wünschen abweicht, desto identischer ist sie mit sich. (Michael Rumpf) Architekturkonzepte sind edle Wünsche, solange sie nicht in harter Arbeit implementiert, getestet und verändert wurden. (Stefan Toth)
  • 45.  1 Einstieg 2 (Gute) Softwarearchitektur 3 Qualitätsmerkmale meistern 4 Entscheidungen treffen und festhalten 5 Die Realität im Auge behalten 6 Ein Selbsttest 7 Fazit und Weitere Informationen 6
  • 47. Kommunikation Wie werden Fragen nach Architekturentscheidungen, -ansätzen, -konzepten beantwortet?  „Historisch gewachsen …“  Es findet ein Austausch über die Architektur über Projekt-/Teamgrenzen hinweg statt.  Architekturansätze sind im Team bekannt und können neuen Mitarbeitern nachvollziehbar erklärt werden.  „Da musst Du Rene fragen …“
  • 48. Struktur Wo finde ich die Struktur der Lösung?  nur im Quelltext  Teile/Komponenten werden wo sinnvoll über Projektgrenzen wiederverwendet  die Strukturen (z.B. Schichten, fachliche Zerlegung) sind nachvollziehbar an den Anforderungen ausgerichtet  in Diagrammen / Modellen und konsistent dazu im Quelltext
  • 49. Übergreifende Konzepte Wie wird mit übergreifenden Aspekten und Fragestellungen umgegangen?  Tendenziell gibt es keine. Die Lösung ist inkonsistent.  Es gibt einzelne Konzepte, die durchgängig eingehalten werden.  Die Konzepte sind an den Qualitätszielen und architekturrelevanten Anforderungen ausgerichtet.  Die Auswahl der Themen für einheitlichen Konzepte ist nachvollziehbar (inkl. bewusstes Weglassen)  Lösungen für einheitliche Konzepte werden, wo sinnvoll, über Projektgrenzen geteilt.
  • 50. Stufen der Softwarearchitektur 0 (zufällig) Softwarearchitektur ist implizit, Erfolg Zufall. 1 (explizit) Architekturansätze sind explizit vorhanden und benennbar (Beispiele: Verwendung von Mustern, Entscheidungen für Frameworks) 2 (nachvollziehbar) Die Lösung ist an Zielen und Anforderungen nachvollziehbar ausgerichtet. Umsetzung und Architektur entsprechen sich. 3 (wirkungsvoll) Die Lösung und das Vorgehen der Architekturarbeit sind reflektiert und angemessen. Die Architektur wirkt über Projektgrenzen hinaus.
  • 51. „The Accidental Architecture“ Grady Booch: „The Accidental Architecture“ IEEE Software 2006 „Accidental architectures are not evil things; indeed, they are inevitable in the growth of systems. It’s only when we begin to turn these accidental architectures into intentional ones that we advance our understanding of software architecture. “
  • 52.  1 Einstieg 2 (Gute) Softwarearchitektur 3 Qualitätsmerkmale meistern 4 Entscheidungen treffen und festhalten 5 Die Realität im Auge behalten 6 Ein Selbsttest 7 Fazit und Weitere Informationen 7
  • 53. Äpfel mit Birnen vergleichen? vs.
  • 54. Äpfel mit Birnen vergleichen? Toll Collect Super Mario Bros. 8D 2C vs.
  • 55. Fazit zufällig0 explizit1 nachvollziehbar2 wirkungsvoll3 Ich kann auch hier unten gute Lösungen produzieren. Ich kann auch hier unten gute Lösungen produzieren. Zufällig. Die Vorstellung erfolgreiche Lösungen nur dem Zufall zu überlassen, macht mir Angst. Ich investiere lieber in Architekturarbeit, …Ich investiere lieber in Architekturarbeit, zumindest wenn Scheitern keine Option ist.
  • 56. Drei Dinge Qualitätsmerkmale meistern Entscheidungen treffen und festhalten Die Realität im Auge behalten
  • 57. 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: 978-3-446-42924-6 www.swadok.de 27
  • 58.
  • 59. Blog-Serie bei Hanser Update  update.hanser-fachbuch.de/tag/arc42-starschnitt/
  • 60. stefan.zoerner@embarc.de xing.to/szr @StefanZoerner Vielen Dank. Ich freue mich auf Eure Fragen! DOWNLOAD FOLIEN: http://www.embarc.de/blog/

Hinweis der Redaktion

  1. Macht es Sinn Äpfel, mit Birnen zu vergleichen? Wir könnten jetzt ja zum Beispiel versuchen, die beste Karte im Raum zu ermitteln? Ist das eine gute Lösung? Hat dieses System eine gute Architektur?