Horw Präsentation Themenarbeit SWE Wyder Aaron Studiengang Informatik SS Semester Juni 2008 Ist Design tot? Evolutionäre Softwarearchitektur in der Praxis

Folie2, 24. Juni 2008 Inhalt 1)Einleitung Ziele der Themenarbeit 2)Design Strategien Geplantes Design Evolutionäres Design 3)Design / Architektur in XP Allgemein Enabling Practices / Exploitation Practices Test und fortlaufende Integration Refactoring Simplicity als Prinzip 4)Geplantes vs. Evolutionäres Design 5)Fazit 6)Quellen 7)Fragen

Folie3, 24. Juni ) Einleitung -Untersuchung von evolutionärem Software Design Kann sowas funktionieren? Wie erreicht man sowas? Ist evolutionäres Design des Teufels? Vor- und Nachteile Eigene Meinung -Evolutionäres Design anhand von XP -Warum sind Verfechter klassischen und evolutionären Designs keine Freunde? -Gegenüberstellung von evolutionärem und geplantem Design

Folie4, 24. Juni ) Design Strategien -2 Design Strategien nach Martin Fowler -Geplantes Design Big Design Up Front (BDUF) Hohe Abstraktionsebene beim Design Erst Planung, dann Implementation Extensives Requirementsengineering Ziel: Ad-hoc Entscheidungen vermeiden -Evolutionäres Design Design evolviert mit der Implementation Nicht alle Design Entscheidungen zu Projektbeginn  Einfachheit Starke Priorisierung der Funktionalität bzw. Anforderungen “Änderungen willkommen” Enabling und Exploitation Practices Keine übermässigen Kosten zu Projektbeginn

Folie5, 24. Juni ) Design / Architektur in XP (Allgemein) -Design / Architektur findet an anderer Stelle statt -Metapher modelliert System -Detailliertes Design zum Implementationszeitpunkt -Eigenverantwortung der Programmierer -Einsatz von Design Patterns -Test First Prinzip -Nach Fowler: Möglichkeit des Programmierens ohne Design Daraus resultiert ein Fehlschlag Code Komplexität als Metrik Enabling und Exploitation Practices Grobarchitektur zu Projektbeginn

Folie6, 24. Juni ) Design / Architektur in XP (Enabling/Exploitation) -Unterscheidung von Enabling und Exploitation Practices -Ohne Enabling Practices keine Exploitation Practices -Fehlschlag -Enabling Practices erlauben eine Abflachung der Kostenkurve

Folie7, 24. Juni ) Design / Architektur in XP (Testing/Integration) -Test, Fortlaufende Integration, Refactoring als wichtigste Enabling Practices -Automatisiertes Testing (JUnit) -Vor Implementation Testfälle schreiben -Testfälle sollten möglichst viele Szenarien beinhalten die unter Umständen schief gehen könnten -Nachdem Code lauffähig  Integration (min. 1 x tägl.) -Korrekturen bis alle Tests erfolgreich -Ansonsten entfernen der Änderungen -Evtl. Code ganz neu schreiben

Folie8, 24. Juni ) Design / Architektur in XP (Refactoring) -“Refaktorisieren ist der Prozess, ein Software System so zu verändern, dass das externe Verhalten nicht geändert wird, der Code aber eine bessere interne Struktur erhält” (Martin Fowler) -Effizientes und kontrolliertes Aufräumen -Designänderung nach Implementation -Unterstützung durch IDE -Wahrscheinlichkeit neue Fehler einzuschleppen minimieren -“Bad Smells” zum Erkennen wann ein Refactoring angebracht ist

Folie9, 24. Juni ) Design / Architektur in XP (Simplicity) -Implementation so einfach wie möglich Verständlichkeit des Codes Simples System ist einfacher zu analysieren / ändern Zeitdruck -YAGNI (You Aren’t Going To Need It) -Keine Implementation falscher Anforderungen -Kein Planungsaufwand für nicht Benötigtes -Änderungen durch Refactoring Ermöglicht durch Abgeflachte Kostenkurve Funktioniert nur unter Verwendung der Enabling Practices

Folie 4) Geplantes vs. Evolutionäres Design Geplant -Grosse Kosten zu Beginn -Vorausplanung -Anforderungen -Flexibilität bei Änderung -Software Architekten Evolutionär -Code and Fix -Dokumentation -Kunde als Teammitglied -Kleinste geschäftlich sinnvolle Lösung -Metapher -Irreversibility

Folie11, 24. Juni ) Fazit -Design ist nicht tot (auch nicht bei XP) -Geschieht an anderer Stelle -Design als Teil der Implementation -Beachtung und Einsatz der Enabling und Exploitation Practices -Design wächst beinahe immer (gewollt oder ungewollt) evolutionär -XP bietet Rahmen um Evolution kontrolliert zu ermöglichen -Keine Ideallösung -> Kompromiss aus beiden Strategien je nach individuellen Projektanforderungen

Folie12, 24. Juni ) Quellen -[Beck01]; Beck, Kent; Extreme Programming – Das Manifest; 2003; Addison-Wesley -[Fowler01]; Fowler, Martin; Refactoring; 2005; Addison- Wesley -[Fowler02]; Fowler, Martin; Is Design dead?; 2004;

Folie13, 24. Juni ) Fragen -Da fragt man sich…