Präsentation herunterladen
Die Präsentation wird geladen. Bitte warten
Veröffentlicht von:Adelind Eglin Geändert vor über 9 Jahren
1
Horw Präsentation Themenarbeit SWE Wyder Aaron Studiengang Informatik SS Semester 06 aaron.wyder@stud.hslu.ch 23. Juni 2008 Ist Design tot? Evolutionäre Softwarearchitektur in der Praxis
2
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
3
Folie3, 24. Juni 2008 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
Folie4, 24. Juni 2008 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
Folie5, 24. Juni 2008 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
Folie6, 24. Juni 2008 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
Folie7, 24. Juni 2008 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
Folie8, 24. Juni 2008 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
Folie9, 24. Juni 2008 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
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
11
Folie11, 24. Juni 2008 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
Folie12, 24. Juni 2008 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
Folie13, 24. Juni 2008 7) Fragen -Da fragt man sich…
Ähnliche Präsentationen
© 2024 SlidePlayer.org Inc.
All rights reserved.