Software Designund Design PatternsFIO SYSTEMS AG®
Gliederung•Gutes Design•Typische Designprobleme•Software-Wartung•Schichtenarchitektur•Architektur-Patterns•Übergreifende P...
Was ist gutes Design?•Einfach•Modular•Gekapselt•Erweiterbar•Stabil•Zweckmäßig
Typische Probleme•Frontend == Anwendung•Prozeduraler Code•Code Duplication•Architektur, die nicht zum Problem passt•Patter...
Typische Probleme●Untestbar / keine Unit-Tests●Spaghetti-CodeFolge:●hohe Wartungs- und Pflegekosten●ineffektive Erweiterun...
Praxisbeispiel Wartung(stark vereinfacht)•FIOPORT Vermarktung•Grobkonzept 2003, 35 Seiten•Entwicklungszeit: 1 Jahr, 5 Entw...
Erstellung vs. Wartung / PflegeErstellungWartung / Pflege2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 201301234567891...
Praxisbeispiel Wartung 2(stark vereinfacht)•FIOPORT Account•Grobkonzept 2003•Entwicklungszeit: 4 Monate, 1 Entwicklerin•Wa...
Erstellung vs. Wartung / PflegeErstellungWartung / PflegePraxisbeispiel Wartung 22003 2004 2005 2006 2007 2008 2009 2010 2...
Schichtenarchitektur
Schichtenarchitektur
Schichtenarchitektur
Dependency Inversion•Abhängigkeit Frontend → … → Backend erscheintnatürlich•Dadurch haben Änderungen in niederen Schichten...
Dependency Inversion PrincipleFormuliert von Robert C. Martin, 1996:A. High-level modules should not depend on low-levelmo...
Architektur-Patterns•Frontend Patterns●MVC●Front Controller●Page Controller●MVP•BLL-Patterns●Service Layer●Domain Model•DA...
Frontend-Patterns - MVC
Frontend-Patterns - FC
Frontend-Patterns - FCCode
Frontend-Patterns - PC
Frontend-Patterns - MVP
Frontend-Patterns - MVPCode
BLL-Patterns – Service Layer
BLL-Patterns – Service Layer 2
BLL-Patterns – Domain Model
DAL-Patterns – Repository
DAL-Patterns – Data Mapper
DAL-Patterns – Active Record@products = Product.all@product = Product.find(params[:id])@product = Product.new
Übergreifende Patterns•Value Object•Data Transfer Object•Factory•Singleton•Observer•Facade•Proxy
Value Object
Data Transfer Object
Factory
Singleton
Observer
Facade
Proxy
Zusammenfassung•einfaches Design, bereit für geplante Anforderungen•Dependencies planen – Interfaces verwenden•Unit-Tests ...
Aufgabe•Erstellen einer Web-Anwendung für das fiktiveMaklerbüro “Alt & Schimmel GmbH” unter Verwendungvon mind. 3 Patterns...
Quellen, Lesetipps•Wikipedia (de, en)•Martin Fowler “Patterns of Enterprise ApplicationArchitecture”•Eric Evans “Domain Dr...
Fragen?(Spätere Fragen einfach per E-Mail an die Adresse auf der Veranstaltungswebsite schicken!)
Vielen Dank!
www.fio.de
Nächste SlideShare
Wird geladen in …5
×

Ringvorlesung: FIO Systems AG stellt Projektziel zum Thema Software Design Patterns vor

812 Aufrufe

Veröffentlicht am

Ringvorlesung: FIO Systems AG stellt Projektziel zum Thema Software Design Patterns vor

0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
812
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
35
Aktionen
Geteilt
0
Downloads
11
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Ringvorlesung: FIO Systems AG stellt Projektziel zum Thema Software Design Patterns vor

  1. 1. Software Designund Design PatternsFIO SYSTEMS AG®
  2. 2. Gliederung•Gutes Design•Typische Designprobleme•Software-Wartung•Schichtenarchitektur•Architektur-Patterns•Übergreifende Patterns•Aufgabenstellung
  3. 3. Was ist gutes Design?•Einfach•Modular•Gekapselt•Erweiterbar•Stabil•Zweckmäßig
  4. 4. Typische Probleme•Frontend == Anwendung•Prozeduraler Code•Code Duplication•Architektur, die nicht zum Problem passt•Pattern madness•Design for the unpredictable
  5. 5. Typische Probleme●Untestbar / keine Unit-Tests●Spaghetti-CodeFolge:●hohe Wartungs- und Pflegekosten●ineffektive Erweiterungen●hohe Fehlerquote●Demotivation●Enge Kopplung
  6. 6. Praxisbeispiel Wartung(stark vereinfacht)•FIOPORT Vermarktung•Grobkonzept 2003, 35 Seiten•Entwicklungszeit: 1 Jahr, 5 Entwickler•Wartungszeit: 9 Jahre, Wartung und Erweiterung durchmittlerweile 10 Entwickler
  7. 7. Erstellung vs. Wartung / PflegeErstellungWartung / Pflege2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013012345678910EntwicklerPraxisbeispiel Wartung
  8. 8. Praxisbeispiel Wartung 2(stark vereinfacht)•FIOPORT Account•Grobkonzept 2003•Entwicklungszeit: 4 Monate, 1 Entwicklerin•Wartungszeit: 9 Jahre, Wartung und Erweiterung durchmittlerweile 8 Entwickler
  9. 9. Erstellung vs. Wartung / PflegeErstellungWartung / PflegePraxisbeispiel Wartung 22003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013012345678Entwickler
  10. 10. Schichtenarchitektur
  11. 11. Schichtenarchitektur
  12. 12. Schichtenarchitektur
  13. 13. Dependency Inversion•Abhängigkeit Frontend → … → Backend erscheintnatürlich•Dadurch haben Änderungen in niederen Schichtenjedoch Auswirkungen auf alles darüber•Außerdem erschwert eine solche Architektur dieWiederverwendung
  14. 14. Dependency Inversion PrincipleFormuliert von Robert C. Martin, 1996:A. High-level modules should not depend on low-levelmodules. Both should depend on abstractions.B. Abstractions should not depend upon details. Details shoulddepend upon abstractions.
  15. 15. Architektur-Patterns•Frontend Patterns●MVC●Front Controller●Page Controller●MVP•BLL-Patterns●Service Layer●Domain Model•DAL-Patterns●Repository●Data Mapper●Active Record
  16. 16. Frontend-Patterns - MVC
  17. 17. Frontend-Patterns - FC
  18. 18. Frontend-Patterns - FCCode
  19. 19. Frontend-Patterns - PC
  20. 20. Frontend-Patterns - MVP
  21. 21. Frontend-Patterns - MVPCode
  22. 22. BLL-Patterns – Service Layer
  23. 23. BLL-Patterns – Service Layer 2
  24. 24. BLL-Patterns – Domain Model
  25. 25. DAL-Patterns – Repository
  26. 26. DAL-Patterns – Data Mapper
  27. 27. DAL-Patterns – Active Record@products = Product.all@product = Product.find(params[:id])@product = Product.new
  28. 28. Übergreifende Patterns•Value Object•Data Transfer Object•Factory•Singleton•Observer•Facade•Proxy
  29. 29. Value Object
  30. 30. Data Transfer Object
  31. 31. Factory
  32. 32. Singleton
  33. 33. Observer
  34. 34. Facade
  35. 35. Proxy
  36. 36. Zusammenfassung•einfaches Design, bereit für geplante Anforderungen•Dependencies planen – Interfaces verwenden•Unit-Tests als Absicherung für Umbauten•Wartungskosten minimieren durch Investition in guteArchitektur-Planung am Projektanfang•Bei bestehendem Code – schrittweise umstellenDenn: Änderungen werden kommen!
  37. 37. Aufgabe•Erstellen einer Web-Anwendung für das fiktiveMaklerbüro “Alt & Schimmel GmbH” unter Verwendungvon mind. 3 Patterns•Seite für Kunden mit aktuellen Angeboten•Seiten für Händler zur Pflege der Angebote•Architekturdiagramm•Beliebige Programmiersprache•Vorstellung der Patterns mit Begründung
  38. 38. Quellen, Lesetipps•Wikipedia (de, en)•Martin Fowler “Patterns of Enterprise ApplicationArchitecture”•Eric Evans “Domain Driven Design”•http://www.oodesign.com•"Design Patterns. Elements of Reusable Object-OrientedSoftware" Erich Gamma, Richard Helm, Ralph Johnsonund John Vlissides
  39. 39. Fragen?(Spätere Fragen einfach per E-Mail an die Adresse auf der Veranstaltungswebsite schicken!)
  40. 40. Vielen Dank!
  41. 41. www.fio.de

×