1 / 13

Ist Design tot? Evolutionäre Softwarearchitektur in der Praxis

Ist Design tot? Evolutionäre Softwarearchitektur in der Praxis. Inhalt. Einleitung Ziele der Themenarbeit Design Strategien Geplantes Design Evolutionäres Design Design / Architektur in XP Allgemein Enabling Practices / Exploitation Practices Test und fortlaufende Integration

eros
Download Presentation

Ist Design tot? Evolutionäre Softwarearchitektur in der Praxis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Ist Design tot?Evolutionäre Softwarearchitektur in der Praxis

  2. Inhalt • Einleitung • Ziele der Themenarbeit • Design Strategien • Geplantes Design • Evolutionäres Design • Design / Architektur in XP • Allgemein • Enabling Practices / Exploitation Practices • Test und fortlaufende Integration • Refactoring • Simplicity als Prinzip • Geplantes vs. Evolutionäres Design • Fazit • Quellen • Fragen

  3. 1) 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

  4. 2) 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

  5. 3) 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

  6. 3) 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

  7. 3) 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

  8. 3) 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

  9. 3) 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

  10. 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 4) Geplantes vs. Evolutionäres Design

  11. 5) 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

  12. 6) 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; http://martinfowler.com/articles/designDead.html

  13. 7) Fragen • Da fragt man sich…

More Related